Part one of a three-part blog on building secure solutions using Online’s Secure Solution Delivery Life Cycle (SSDLC).
As attacks move up the stack from the operating system to applications themselves, a shift in the solution delivery life cycle philosophy is emerging, recognizing that security activities need to move earlier in the life cycle, to truly build security effectively. As organizations are pressured by the rapid promotion cycles of DevOps, the focus is often on secure coding, static code analysis tools, and earlier security testing. But this is too late to be effective; in order to build inherently secure applications, our security activities need to span the entire life cycle.
The Case for Secure Design
Most common development methodologies treat security as a list of features, use cases, or user stories. For example, we might need a login screen, the ability to keep an audit trail of updates to account data and to obtain a digital signature for an approved document. But security is not as simple as a particular feature or two – it is an ongoing concern that spans all project activities and cuts across all features. It needs to influence everything we do – from requirements to analysis, to design, implementation and deployment.
But there is a natural tension here. Implementing security gets in the way of “real” tasks that produce “working code.” Users want functionality and you can always go back later to add the missing security… right?
So your organization focuses on implementing features in your hip, new MVP (minimum viable product) release of the application… which leads to one of three possible outcomes:
- You do not perform dynamic application software testing (DAST) or penetration testing after the app is complete, and it is unknowingly insecure. Therefore, you cannot fix it, or mitigate risk by adding compensating controls. You get hacked.
- You do test your application and find a number of security bugs that can be rectified. The good news is that you can implement compensating controls until the app is remediated. While the compensating controls may compromise functionality or usability while security is retrofitted (which can take a number of months due to the risk involved) you are somewhat secure.
- You do test your application and the security defects you find are not so simple to remedy. The solution requires a fundamental redesign of your user interface, but the business has a hard deadline and is forced to find a third-party solution and your app is scrapped and never goes live.
If you are very good at pumping out code, but your code is not secure, then you are rapidly increasing the attack surface and accruing a liability for your company, oftentimes at an exponential rate. As the saying goes “tools amplify sound, but they also amplify noise.”
Numerous life cycle cost estimates say that there is a cost multiplier of 100 times if a defect must be remedied in an app after deployment versus if it had been caught at the requirements stage. Very complex or widely distributed solutions might exceed 1000 times. And on top of the higher cost to repair, you also have the added exposure or cost of compensating controls while you do it. There is clearly a business case for designing security into your app from the beginning.
What is Design?
Design is any activity where you transform “what the system must do” into “how it does it.” This includes making decisions about components, their scope and behaviour, and the relationships between them. If you are partitioning functionality at any level, allocating features or data to logical or physical components (sites, servers, systems, subsystems, processes, executables, compilation units, procedures, classes, methods, etc.) then you are doing design.
How do we design secure solutions? What makes one design more secure than another? In Part Two of this blog, we will look at a set of fundamental design principles and examples of how Online’s SSDLC can help you apply them. In Part Three we will teach you techniques you can use to apply them across the life cycle.
About Larry Skelly
Larry is a TOGAF and ITIL-certified Enterprise Architect in our Risk, Security and Privacy practice, with more than ten years of experience writing and teaching design methodologies and thirty years of experience with architecture and hands-on development. Larry understands the need to infuse security into everything that we do. He was also a primary contributor to Online’s Security Integration Framework (SIF) and Secure Solution Delivery Life Cycle (SSDLC), an approach for implementing secure IT solutions. To continue the conversation, feel free to leave a comment below. To learn more about Online's Risk, Security and Privacy practice, click here.
Submit a Comment