Adventures in Code
As a cyber-professional we are tasked with being protectors of software and infrastructure on the Internet. We protect ourselves from unknown adversaries. We place devices and services to monitor and filter our experience and to protect us.
Our continued effort has strengthened the armor of our networks but we need to also observe our software. We need insight into the level of security practices that we observe in our software development lifecycles – right where the software is made. A root-cause security issue can often start with the code.
Code is telling our machines what to do. It runs our social, our public, our business, and our private lives. We display our social lives through Facebook, Twitter, and Instagram. Life in general produces so many public documents that they are just a click-away and our private and business life are absorbed into activities on the Web, Mobile, and Cloud.
Our software runs in hostile environments. The introduction of Mobile and Cloud architectural changes over the last few years has reinforced the need for software to be protected at its source. Countless studies have shown that its a strong strategic move to address the security gaps found at this point of the software lifecycle.
So, we always Move Left.
So the rule is: “We need to protect our software at its source and move left”.
Move Left is a movement to protect software holistically along the lifecycle by addressing security practices and managing risk. All area are reviewed and Domains and Security Practices are matured. Even down to where the code is composed by Moving left. The long-term strategy is to mature practices by tactically refreshing SDLC security practices along the lifecycle.
A non-standard SDLC may not be bad. But will need to be reviewed on its merits for its security practices.
Education, Architecture, Code, Data-flow and rest, and testing all have structure and can be understood.
There is some practical knowledge that should be observed at this point that a well-rounded software security program helps protect the software.
Metrics create a compare and contrast ability to measure your efforts against yourself, against other organizations, and against Industry and Sector(ISV, Retail,..). This provides insight into the gaps in your software security initiative.
Security minimums
Security minimums (training, architectural analysis, code review, penetration testing, and privacy) are the standard starting point for any effort: [T1.1] [AA1.1] [CR1.4] [PT1.1] [CP1.2]
Review: http://bsimm.com/download/BSIMM-V.pdf
There is an unsettling reality that there are a lot of attacks that are done out of ‘matter of convenience’. Absent Security practices make for holes in software. Convenience attacks are simple attacks that allow entry into the privacy, data, and systems of others.
There is a set of common key areas that are practiced throughout the industry. Not all SDLCs and programs will look exactly alike. But, a good security program is baked though-out the SDLC into a Move-Left mindset by maturing the security practices iteratively.
Simply, good security is baked into the environment. Solid software security practices are being observed that are incorporated into the level and skill of the team. Adopted security practices will mature the team and their lifecycle by reducing a root-cause issue, the code.
Industry Common Areas:
[SM1.4] – What SDLC is being used and what gates are enforced?
[AM1.2] – Create a data classification scheme and inventory. Prioritize applications by data consumed and data manipulated.
[AA1.1] – Perform a security feature review and get started with Architectural Analysis.
[PT1.1] – Use Penetration Testers to find problems
[CP1.2] – Identify PII obligations and promote privacy
[SFD1.1] – Build and track a common library of security features for re-use.
[CR1.4] -Use manual code analysis review along-side automation. Use automated tools to drive efficiency and consistency .
[SE1.2] – Host and network security basics are in place.
[T1.1] – Provide security awareness training. Promote culture of security throughout the organization.
[SR1.1] – Create security standards
[ST1.3] – Drive tests with security requirements and security features
[CMVM1.2] – Use Operations data to change development behavior
Review: http://bsimm.com/download/BSIMM-V.pdf