The secure SDLC sits on top of the regular Software Development Lifecycle. A popular one is Microsoft’s SDL (Security Development Lifecycle). According to M$, “The Security Development Lifecycle (SDL) consists of a set of practices that support security assurance and compliance requirements. The SDL helps developers build more secure software by reducing the number and severity of vulnerabilities in software, while reducing development cost.”
I actually really like Microsoft’s SDL, it is the one I started using at the beginning of my AppSec program. I changed it a bit due to a variety of reasons, one being the size of my team who couldn’t keep up with all the work that this would make for us.
People will tell you that it looks something like this:
https://social.technet.microsoft.com/wiki/contents/articles/7100.the-security-development-lifecycle.aspx (this is their older picture but you get the picture)
But in reality, the development process looks a lot more like this:
It is pretty much a mess and everyone does it differently if they really do it at all (most will just tell you that they have processes but don’t actually follow them).
Mine looks more like this:
I cut it down to four sections instead of the seven sections that are in the Microsoft SDL. But let’s be real, when it comes down to actually doing work, four is greater than seven. I don’t have time for seventeen things in the original seven sections, my AppSec team is only two people. Not like twelve is better, but let me explain why it really isn’t twelve items of work for my team.
Design The design section has three items (we are currently rolling out threat modeling and that will be for another blog post, so let’s skip that for now. Here is Aaron's post on Threat Modeling tho).
Security Design Review is a consultation phase where the development team reaches out to the AppSec team if they need/want to. We also have special cases where they have to, such as building auth services, etc. We will review user stories (for weird business logic), data flow diagrams, sequence diagrams, and basically whatever documentation they might have. The AppSec team will ask questions to figure out what they are actually doing then give our recommendations. If possible, we create best practice guides so we don’t need to reproduce work when similar work comes to us in the future.
NOTE: Start talking to them about what kind of security events they should log (this will be important in future sections).
Data Classification is generally pretty easy. Hopefully your company has some kind of data classifying/rating system. The teams should know what kind of data they are storing, so they should just be able to look at the guide and figure out where they fall, so AppSec’s input probably isn’t needed. Basically, do you have sensitive data (PII/PHI/PCI) or not? This will inform what questions might get asked during the Security Design Review. We generally care less about brochureware sites. We should care equally about all sites. But who has time for that?
Hopefully all this happens before they start writing code, but usually that is not the case. It is fine, just getting eyes on it is better than not knowing.
Code The code section is where the developers actually write code. This may or may not come before the design phase depending on the maturity of your software development program. This is where you should be setting up all of your code scanning tools, maybe even your DAST tools because we all do agile, right?
SAST and SCA are going to be your code scanning tools. Hopefully you have these built into whatever build pipeline your developers are using and they aren’t using languages that have no support in the security tools. If your dev practices are mature enough they might be using things linters, and if you are lucky you might even get to add some security checks to the dev’s linters.
Security code reviews are interesting because my AppSec team generally doesn’t do them. We do on very special cases but we have too many developers and too many services and we do not want to be a bottleneck for development. Self-service FTW! But we do provide training to our developers and a checklist of the five most important things we want them to check for. I am not going to provide my checklist because it is going to be different for each company. Figure out what your company cares about, what kind of vulnerabilities you are seeing, and make a small checklist from there. Don’t let it get too big because no one is gonna go through fifty items. Let the dev teams decide how to do these code reviews, every PR vs every release. It doesn’t really matter as long as they are doing them.
Test This is generally where you are gonna setup your DAST scans. By this time in the process, the application should have some kind of features to actually test. When setting up your DAST scans, take a look at the APIs or website and start a conversation with the developers about attack surface (if you see any weird APIs or sections of the website). Let’s get rid of the stuff that is not actually needed or shouldn’t be public.
If you are lucky or unlucky enough to get to do your own pentesting (depending on how you look at it), this is when you get to pentest or hire someone else to do it for you. This usually happens when the application is feature complete. I don’t have much to say about pentesting except things should probably get a pentest. It is a good time for you to actually use the product and figure out what it does. Remember to look at the threat model, design documents, and source code while you are doing this.
There might be some things you want to actually write security unit/integration tests for. Things like access controls, indirect object reference, checking your JWT validation, etc. You don’t want to do this for everything, but there are a few things that may make sense for you to ensure your security controls are actually working.
Production The final section is done before going live, usually with a net new application. You should be setting up your WAF and/or whatever other security tools you might be using. Make sure your security events are being logged in the right place for your blue team (these are the guys that look at logs all day) so they can set up alerting. OWASP has a pretty good list of things you might want to log. But as an AppSec person, I don’t do much else with logging.
This is generally the longest phase of the software development lifecycle, things rarely get sunsetted. And that brings me to maintenance, keep up your SAST, SCA, and DAST scans. Have metrics on when your WAF, logs that show you are getting attacked, and make sure devs know about this stuff. This entire phase is basically telling developers to fix and update their shit.
Missing Sections So if you were wondering what happened to the missing sections, they are still being done, just not in the S-SDLC.
Requirements are generally written into your standards and rarely ever changed. I use the OWASP ASVS to generate my requirements, these apply to applications and services we create. They are all non-functional requirements so they get treated like all other non-functional requirements and ignored.
As for the IR section, we have a blanket incident response plan that is basically the same for all applications. I will reach out to the IR team to notify them if there is something they should be more concerned about and they can work with the development teams if something more is needed. Generally, this is something I don’t really care about.
Finally training, you should be doing some sort of training for your developers. Hopefully your security champions get a little bit more training. For most companies this is probably just a thirty minute video on why PCI is important and the OWASP top 10. But developers don’t need to be security experts (that would be nice tho), I mean, that is why you have a job.
Conclusion (in no particular order) Things AppSec should be doing:
Help set up tools (SAST, SCA, DAST, WAF)
Pentest something
Security Design Review
Help with Threat model (if needed)
Things devs should be doing:
Secure Code Reviews
Threat modeling
Data Classification
Security Unit/Integration Tests
Maintenance
Things other security people should be doing:
Monitoring
Incident Response stuff
So that is four things AppSec needs to do. Most everything else should be self-service for developers or pawned off on other security people. Though you may need to help out with their stuff, make sure you put the burden of the work on the team that actually owns it.
NOTE: Notice how I didn’t tell anyone to push left or mention ‘DevSecOps‘.
References: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html https://www.microsoft.com/en-us/securityengineering/devsecops https://social.technet.microsoft.com/wiki/contents/articles/7100.the-security-development-lifecycle.aspx https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
About the Author
Ray is a Life Coach and Conspiracy Theorist. He does AppSec in his non-spare time for money. Twitter