Since presentation at RSA last year, I've been a fan of Fortify's "Building Security in Maturity Model" (BSIMM). As you might recall the model was based on security development practices observed at leading companies. Categories and maturity rankings were assigned so BSIMM is especially interesting as a benchmark for SDL practices.
An update was presented at RSA this year. The BSIMM empirical data set now includes over a 100 companies. Analysis with Fortify has lead to a simplified security development lifecycle document (17 pages) recently released by Microsoft. Below are my perspectives on the ‘optimized' process.
To cut to the chase, the simplified SDL is useful but comes up short. Much of the simplification appears to come from favoring practices at the front end of the process. Addressing security early and often is important and arguably the most efficient approach. However, security in manufacturing sectors is dominated by operational aspects and extended support lifecycles.
It was of little surprise the first few sections are ‘disclaimer-ish'. The introduction suggests the simplified process as a minimum core set of practices. Furthermore, the simplified approach aims lower; targeting a progression from basic to standardized to advanced stages. The full SDL is needed to target a more dynamic security level characterized by actively minimizing risk for customers. Dynamic security certainly aligns with building resiliency into highly serviceable PI Systems. We like to think of the potential for managed PI to deliver state of the art incident response and prevention service level objectives.
Ok, so not all SDL initiatives are created equal and there is the significant issue of bootstrapping the process. Consider this quote from the simplified SDL: "Integration of secure development concepts into an existing development process can be intimidating and costly if done improperly." Based on my experience with the BSIMM benchmark criteria, the simplified process is indeed optimized to help get started and can be useful to accelerate existing SDL initiatives. For instance it's easy to spot voids in the 5 process phases then consult the full SDL or examples from the BSIMM report for details on the missing activities. Microsoft offers many useful SDL resources.
To get started I suggest using the sample implementation flow chart (attached) in an honest self assessment. How many short-cuts are you taking? Is pen testing a security crutch for your products? How do you go about security training and establishing security experts?
Perhaps true for developers everywhere, attack surface reduction is an especially challenging security practice at OSIsoft. For instance, when to move a project to a more secure compiler that means dropping support for a legacy platform? What platform features should we leverage and which ones should we disable? How should we react to externalities like the recent announcement about Windows Help? What about PI itself... should we really start all services? If not, which ones should be disabled by default? How easy is it to use the system without super user privileges?
Essentially if we get the surface area wrong, users will not get the expected value from the PI system. We must build-in security with maturity to protect your data and critical infrastructure but not get in the way of a rewarding experience for at least 80% of users. Indeed the 80/20 rule is part of the SDL, but try to measure that one!
In summary, a simplified security development lifecycle is not the whole SDL story. Over the long haul, I believe a dynamic level of security can only be achieved with close collaboration on operational aspects. OSIsoft vCampus provides a unique community forum to see many sides of our shared challenges including security. At a minimum your ideas help shape surface area decisions and guide us toward getting security done right! Thank you in advance for using the SDL process.