Exploring SDL: Successes, Learnings and Failures – Part 2
In the first post in our “Exploring SDL” series, we gave you a look into our approach to security and how we arrived at the idea for the Security Development Lifecycle. Hopefully you were already familiar with SDL, or took a look at the reference material we collected for you in the last post. You did have a look at those, right? 🙂
I would definitely recommend watching the YouTube video about what utilities are available to help you when introducing SDL in your company. This would have helped our initial SDL approaches, which took some tests and course corrections.
SDL Optimization Model
What is the most naïve approach to starting a SDL with? Checking the Optimization Model and following exactly what it tells you. Now there are some items on this list which made very little sense for our web applications, like compiler defenses and file fuzzing. So, are we more secure because of our web applications? Hardly so, but it seemed like that was the case when first reading the Optimization documents.
Certainly there were items on the list which we picked up very quickly. We introduced a security bug into our developer’s ticketing, implemented threat modeling for our selected modules, contracted external penetration testers for our products, and searched for tools that were good with web application scanning. So you may be wondering, where was this epic fail I mentioned? Security bugs were not actually used, threat modeling results were not adopted by developers (although they definitely fixed several severe issues before hackers would find them), external penetration test results were not comprehensible, and web application scanning was not automatable. In other words, our biggest mistake was identifying a tremendous number of items for our developers to work on, without having a security engineer for each individual available to explain what those items meant – or better yet, who could do it for them.
Obviously part of the problem was to starting with too many product teams at once; but the Optimization Model instructed working with all high risk modules, and everything is high risk, isn’t it? On the other hand, you can hardly move beyond basic security procedures if you, as a security engineer, do not push developers. How hard? Sit next to them, hard; participate in their Scrum planning, hard; with their Product Owner and higher level managers, hard. The Standardized level does not come for free.
Moving forward with SDL
In order to really move forward with SDL, we decided to select one specific development team, with which we could try out all the different levels of SDL.
So what do you do with your pilot team? Everything you missed during the first trial.
First, pass your development team the work items gradually, one by one. With each step, be sure to listen to what they have to say. Do they understand the need? Do they feel it is relevant? Can they introduce it into their workflows? Are they aware of the possible tools? If the answer to any of these questions is “no”, you as a security engineer have to be present and help out, explain, do research. Also, be prepared to remove items from your Optimization Model checklist and add new ones based on the collected feedback.
Checklists are great and help you stay focused but they should only be expected to be what they were designed for – keeping track of everything you need to put in place. In the initial phase we tried to create a checklist (see image below) that the product teams could follow. It would provide them with action items, add additional explanation and have a clearly defined checkbox. We hoped that giving the teams this checklist would help them begin to work on the task at hand in the appropriate order, starting from the first item down to the last.
Traditionally, this is not how developers in the agile era work. They have one backlog and that’s it. No external documents, no requirements database, no waterfall-like checklists. If you want developers to adopt something, you must adopt to them, too.
Working with a pilot team can help you get a much better feel of how the processes in your company work. Instead of having a security team external to your developers, you quickly realize that you can be much more effective with this kind of involvement. With the pilot team you will uncover a number of new practices and tools that you can translate to other teams. This is when your company’s specific security engineering practices will take shape and where your SDL will take shape.
You have to understand that all the literature out there from Microsoft, everything we suggested you to read in the last post, is the SDL of Microsoft. It is not your SDL. This might sound as if the available material is worthless. That is not true. That material is not the guide to SDL, but rather a knowledge base to SDL. It is a set of practices you can adopt and a proven track record of how Microsoft did it. But it is not necessarily the process that is going to work best in your company. There are probably many characteristics where your company differs from Microsoft, right? This is how you should consider your SDL as well.
Where do you go from here? Reread the materials, but with this new mindset. Prioritize what you deem important. Determine what parts your pilot team deemed important. Then work out your SDL!
We can show you how we did it, but you’ll have to wait for our next post!
Coming up next: