You can build security into your waterfall software development life cycle (SDLC) when you have days or weeks to dot your i’s and cross your t’s. Don’t have time for that? Well then, Agile is the expeditious methodology when adding security considerations into your SDLC.
What do you do when you’re engineering at high speeds? How do you transform your processes into something that will fit your fancy new agile lifestyle? The following sections offer a glimpse into what security steps should be added to your Agile development process and how to determine the best way to add them.
What stays the same when transitioning to Agile?
The security steps themselves.
An agile approach doesn’t change the touchpoints because changing the speed at which you create software doesn’t change the types of security bugs or flaws that are introduced. Continue using the security fundamentals your business is accustomed to, for example:
- Application security training for everyone involved with application building projects
- Security requirements during the requirements gathering phase
- Architecture risk analysis during the design phase
- Static application security testing or security source code review during development
- Dynamic application security testing or penetration testing before production
If the security fundamentals remain the same, what changes?
The implementation of these security steps.
Agile processes aren’t special snowflakes, they just make process inefficiencies more obvious than their waterfall counterparts. Here are a few examples of how:
- Releasing every 14 days means a security assessment can’t take 5 days each time.
- Stopping or slowing down development for days or weeks may actually be more risk to your business than getting code through without detailed analysis.
- Operating outside of the build cycle isn’t practical, since we are always in the build cycle with Agile development.
Take steps to get your business up and running with a secure SDLC today.
How do I actually make the transition from a slower secure SDLC to a faster one?
Your secure SDLC needs to be as “incremental” as your SDLC. If you are releasing code every year/month/week/day/hour/minute, then your software security risk indicators must fire at the same speed. This does not mean that you need to do security testing each minute, but you need to know whether or not your code has changed enough each minute to merit a security test. Your risk indicators will set the threshold for when the code base has changed enough to require software security activities. Some examples of risk indicators include:
- Type of data being handled (i.e. Personally identifiable information (PII), or other sensitive data)
- Change to security features (i.e. Authentication, Crypto, Authorization)
The best kind of security is the kind of security that best fits your business style. Here are a few ways you can start implementing Agile into your business:
- Create new/updated processes that match the culture and are realistic
- Make incremental changes to the process and revisit additions if they cause issue
- Determine the risk threshold for actually stopping or slowing down. Every minor change may not need a full review, but maybe every major one does.
- Automate and add tools to catch low hanging fruit. This may look like a canned set of security requirements, a well-tuned security tool that may only identify a few findings, but does so with high precision, etc.
- Do things the old-fashioned way periodically to make sure the new and “improved” way is working properly.
- Create a process where compliance is guaranteed by virtue of following the right build process.
- Create passive reviews that will sound alarms for deeper testing without stopping the production line entirely.
- Learn your technology well enough to know what tools will play nicely with what you have in place today.
Things to remember
When adding security steps to your agile process:
- Don’t reinvent the wheel – Your waterfall-secure SDLC has plenty of raw materials. Today, you may be doing things such as code review, penetration testing, threat modeling, etc. You may add the same steps to your agile process, but do them only when needed, based on your risk indicators.
- Think strategically – As you shine a light on your risks, your headlight brightness should outpace the speed of your car. In other words, make sure that when you change a function that handles PII in a one-day release that you are able to be notified of a change to something handling PII that day.
- Build incrementally – Much in the way that Agile is about incremental development, your foray into agile security should also be done in manageable, bite-sized sprints.
As you start to shift the discussion from “what” to “how,” you can think about how to draw from your current security SDLC to add security steps to your people, process and technology for agile development.
Which 2 security steps are you adding to your agile process this week?