After years of trying, Infosec has made some headway inserting some basic security disciplines into enterprise SDLC. Sometimes its checklists, or threat models, and often its more toooling than process. When I work on Security in SDLC, I like to start by analyzing how does the SDLC actually work. Not how the managers think/say it works, but follow the code from ideation to development to deployment. These initial processes before coding end up being interesting from a security architecture standpoint because its too late to re-do your identity and access management strategy once the project is underway.
The SDLC as it actually runs is different from what managers say the SDLC is. Of course, the SDLC that security people experience is at yet one more remove from this, so a big initial challenege is finding where and how security can play an effective role in the real SDLC.
The real SDLC these days means quite a bit of outsroucing which introduces another curveball (or maybe seven curveballs). One of the big problems with the outsourced model is when the outsourced dev group agrees with your security requirements. I repeat - one of the big problems with the outsourced model is when the outsourced dev group agrees with your security requirements.
Most security functions amount to medium or large impacts on the overall codebase in terms of complexity and cost (also these are the two main drivers the outsourcer cares about). Many outsourcer business analysts hold meetings to gather requirements, but what they actually gather is feature lists that are not synthesized into what is practically achievable. So in the initial phase the outsourcer says "yes we can do that" to everything. But then, often too late in the process, the response comes back with - "do we really need to do this?", "this is hard", and so on. This is a situation to avoid. First off, regular check ins and involvement in daily scrums are necessary and what security people should be listening for is not - yes we can, but no this is too hard or how do we actually do this.
The marker of initial success in security in the SDLC is not getting a security function on a laundry list of features but rather getting to the friction and pushback earlier in the process. The earlier the tradeoff process starts the better the tradeoffs will be. So the goal is to get past the yes and get to the No as fast as possible. If you can achieve this then you still have time to turn some of the Nos into Maybes or even Yes, turning the initial friction into something positive.
Comments