Do you have experience with bringing security into SDLC? Looking for insights from people who did it, what were the challenges, learnings from the process.
Please share your experiences, or resources you found useful. Thank you!
From the perspective of what I can call - a more amateur project of embedding security into an SDLC that I have experience with - I can summarize the following:
- From architectural perspective - you need to implement an information security risk management process into each SDLC phase and based on the risk analysis and risks treatment - to craft the corresponding security controls implementation procedures for each phase of the SDLC which also need to be periodically evaluated and assessed against common IS threats
- Challenge throughout the process is to be able to prepare the appropriate SMEs that could help the IS team conduct an adequate risk assessment and management and to identify the appropriate risks while providing the treatment options relevant to the company's risk appetite.
I would recommend - focus on acquiring a strong contingent of experts both in the SDLC and in Security and help them work together for the sake of that Risk Mgmt process - in my opinion - this is the key for a successful implementation of Security in the SDLC.
I have indeed done this with several organizations I have worked with.
The key, for me, is that security professionals should stop seeing developers as incompetent or as adversaries. Developers do not come into work every day with a desire to write insecure code. From that premise, you should develop your relationship with the development teams you are working with.
Development teams should own the security responsibility for the products they are working on. Your responsibility as a security professional is more in an advisory capacity. I personally have found that training your developers on threat modelling and providing them with information (often in the form of checklists) on what best practices are (e.g. what to take into consideration when handling personal data or what to pay attention to when using cryptographic functions) is the most effective.
From there I usually rely on the abundant documentation around security in the SDLC as published by Microsoft to add more structure to the process.
Surprisingly, a successful secure SDLC relies heavily on the security professional's interpersonal skills and their ability to build good relationships.
Microsoft secure SDLC information here : https://www.microsoft.com/en-us/sdl
Example from Riot Games : https://www.youtube.com/watch?v=-_GLHlfSLZw
Adam Shostack's talk on Threat Modelling : https://www.youtube.com/watch?v=KLpgaoD8ySM
In addition to what others have said, I'd add not forgetting about QA/testers when it comes to software security, as security flaws are really just a subset of bugs more generally. QA should be adding checks for, say, OWASP Top 10 issues into exploratory testing phases during new feature and regression testing. Also, tracking compliance/regulatory requirements related to security as a feature as well. This is especially true if you're making products you expect to submit for FIPS/Common Criteria/CSfC certification. Protection Profiles, as opposed to EALs, serve as a good starting threat model for the product category. Testers should be reading requirements and adding test cases to make sure that a) you're hitting the requirements and b) there are no surprises when you go to deal with your testing lab during actual certification. Having been on both the product engineering side, as well as the lab side, I can say that approaching it like that really helps streamline the process but also bolster the product quality and security as well.