The original Software Development Lifecycle (SDL) was built with waterfall-style development in mind. As we continue the transition into heavier reuse of components and less pure development, all with shorter release cycles, the SDL needs modernization in parallel to help ensure secure software. The operational security aspects have changed along with cloud deployments; different processes and a revised mindset is needed to handle some of the fundamental differences. Spending a small amount of time to update processes and toolsets to include security in the beginning will actually increase your ability to stay on schedule and minimize unplanned work. Now more than ever, security needs to be part of the default behaviors and process for software development and deployment; bolting it on is not an option.
Timing – Can you stay in step?
There is a time and place for all things. Today, more than in years past, security tasks need to be an integral part of software development and deployment. The traditional view of doing all the prep work because of long development cycles doesn't hold true for many scenarios now. While there is still some long cycled development, many organizations are moving to define, build, and deploy in much shorter cycles.
Like it or not, IT maturity plays a critical role in how security is integrated (or not) into software. If there are good, mature development processes, there is a much greater opportunity for augmenting the process for security. If it's the "Wild West" for development, seriously consider using security to help bring order to the chaos. While security can be a critical piece of development, it is only a piece. Don't create all new processes when the core process exists. For example, if there is a design review process, augment that process to include critical security elements/principles. Don't force them through a separate "secure design review" process.
Tooling – Automation for what computers do well
Developers desperately need better security tooling at writing and building time. But it needs to be smart. There are tasks that computers are very good at performing which are largely a waste of human time: finding banned/insecure functions, outdated crypto/hash algorithms, etc. Conversely, there are tasks that computers just do not do well (largely due to an inability to understand context) that humans can accomplish: business logic errors, authorization mistakes, etc.
Developers have only so much short term memory. They need to use it to try and figure out what a particular business requirement/user story actually means. They can't fill it with a pile of security-related gotchas like, "Am I using the safe function or method here?" or "Where is my input validation?" These things can (and should) be handled by tooling within the development and build environments. At the end of the day developers get paid (and keep their jobs) if they can deliver on the business functionality for which they are responsible. If security-related tasks are standing in their way, guess which one wins. Security needs to be an integral part of development, but in a supportive, scalable way.
Threats – Cloud alters the formula
Threat modeling for cloud-based software needs to take into consideration many things that we had previously assumed to be fairly static. In the older, traditional formula, the data, infrastructure, people, etc. were fairly static. In the newer cloud formula, system admins, location of data, applications, and shared infrastructure all contribute to a more dynamic threat landscape. Many tasks that were previously manual are now automated and face different types of threats. In addition, consolidation of data and services of many different organizations may attract different and more persistent attackers.
At the same time, "Cloud" has the potential to address many threats. Large providers are able to offer intrusion detection, DDOS prevention, anti-malware, and other defenses. They can provide solid authentication and authorization models. Many cloud providers support solid encryption solutions for data at rest and in transit. Since they are protecting more than just your data, and likely businesses with more to lose, they are typically good at what they do, and better at it than many non-cloud organizations.
Testimony – Telling your Security Story
Remember those teachers in school who were sticklers about students showing their work? There was a good reason for that; the progression of work is where it all comes together. Closed loop feedback is very beneficial but needs input. Each process or tool should be put in place with the intent to integrate the output into the story. Intentionally show how the output of each step can be an input into the next step. Doing so will enable many capabilities like ease of compliance documentation, measurable understanding of security-related risk, knowing what you are getting right and where developers need the most help, and transparency as a competitive advantage for customers. Want credit for doing it right? Proof is powerful.
The SDL security process for software development and deployment is crucial, especially as cloud adoptions grows and development cycles shorten.
Brian Glas has worked in Information/Application Security for the last 10 years. He started as a Java Developer, then transitioned to helping build an Application Security program as both tech lead and manager. He later played the role of Enterprise Architect and spent a number of years as an AppSec consultant helping clients build AppSec Programs, create/update SDLs, and other related initiatives. He is currently working on the Trustworthy Computing team at Microsoft. Brian's talk "Modernizing SDL for Cloud" will be featured on June 14th at Cloud Security World in Boston.