If you add up the biggest data breaches from 2018, they affected about a third of the world’s population. One can easily become cynical about the idea that data security no longer matters — all our information is already on the dark web. Just deal with it.
And that’s with us spending over $100 billion per year on information security. Gartner estimates it will reach $124 billion in 2019, to be precise, yet we are not winning this battle.
The Soft Underbelly
For those of us who are not ready to just resort to security theater and do SBCTB (security by checking the box), we need a rethink. According to research conducted by the Ponemon Institute for IBM, 32% of the risk of security breaches comes from the application layer, yet Gartner forecasts that application security spending will only make up about 2.4% of all security spending in 2019.
What’s worse, the current app sec focus is to get developers to write secure code, while there’s very little focus on ensuring that software is intrinsically designed to be secure. And we’re going the wrong way. Current mob wisdom is generally that DevSecOps is panacea — this means an even higher reliance on developers doing the right thing while they are building new features. This is called “shifting left” — upstream in the development cycle.
Bringing security issues in front of developers while they are coding will help, but this assumes they have the will to focus on security and the training to understand how hackers can penetrate. That’s a lot of emphasis on developer education to try to get the right outcomes. This approach is valuable but can take a long time and is certainly not foolproof.
Design is the source of many of the security weaknesses I see and has been for a long time. If you build a structure, of course it makes sense to design security and reliability into that structure. Modern apartment buildings don’t have bolted-on fire escapes; they have fireproofed internal stairs. The same is true for software systems, and security experts know this well.
Mind The Gaps
While it would clearly be more effective to design our software with security in mind, there are three big gaps that keep many organizations from doing this. These include gaps of process, know-how and software intelligence, all of which conspire to keep security from becoming a design consideration.
Many developers don’t understand the full transaction flow and architecture of the systems they are building. Architects don’t always have access to the real, as-is architecture of their systems. In fact, as applications become more componentized, the architecture of a given transaction becomes harder to know.
Even if they do understand the product architecture, software architects don’t typically focus on security. They are more focused on implementing functionality in software, figuring out how to structure the system in a way that enables developers to move as quickly as possible, and how to containerize the application for maximum flexibility. Their goal is generally to enable things to happen in the software, not prevent them from happening.
There is little space or time for architects, security pros and developers to think through secure software design alone — security architects don’t operate at the detailed software architecture level, and left to themselves, many software architects may not think about security.
Lefter Than left
Our thinking can be extended to shift “lefter” into design by adjusting the process, skills and level of software intelligence that we bring to the problem.
Process: The software development life cycle needs space to think through software design – this is not a given in many agile environments, where the focus is on release velocity and delivering features as quickly as possible. Design should emerge as a function of continuous development and deployment.
Secure architecture must be a part of the design step. The design stage should involve collaboration between the software architect and the security architect, who should set some architectural guidelines to protect key sensitive data and force all access to such data through specific constructs. Your team should define and then “enforce” architecture — or at least adhere to it — during development at each sprint. I believe data protection can only be done through design.
Skills: Organizations need to narrow the knowledge gap. Software architects need to learn about secure design patterns from the security team or external sources. Security architects need to get a design-level view into software architecture of specific critical systems and data. This may require recruiting and training a larger staff of security architects or specific “secure software” architects.
Security architects then need to learn how to track progress toward secure design once the design principles are established to ensure they’re complying with them and that old constructs are eventually rebuilt to conform to the secure architecture. Software architects need to learn how to look for potential exploits by thinking more like security architects.
Intelligence: Architects and developers need design-level software intelligence in order to get this job done. This means finding insights into the structure of existing systems to inform security by design, the capability to define the target design and the ability to track progress toward and conformance to the target design. (Full disclosure: My company offers software intelligence solutions.)
IT and business executives should establish compliance goals for secure architecture compliance, as well as targets for overall security health for applications that handle sensitive data. In an automated development pipeline, you can auto-generate this intelligence consistently for all stakeholders – from developers to executive management.
Carpe Diem
There is massive software re-engineering going on right now as businesses are transforming their IT setups for digital business — perhaps the biggest re-engineering since Y2K. Of course, what we build now will likely evolve more quickly than what we did 20 years ago, but we still cannot underestimate the persevering tenacity of legacy software. As we build new applications, take advantage of new design patterns such as microservices or APIs, move these to cloud and orchestrate APIs for faster business results, software design issues will only become more complex. But this also presents an opportunity to design security.
[“source=forbes”]
