Modern Security Methods: Lean Principles
Information security is hard. Providing good security is even harder. Agile development methodology and the practice of Lean principles has allowed industry leaders to produce and deploy software faster and more frequently than in decades before. Naturally, our diligence to protect this software, and our ways of doing so, must evolve too.
Security has always followed the innovation of technology, and rightly so — seeing that without the technology, there would be nothing to protect. It is pretty obvious from simply observing current events that protecting customer data and fortifying code against attacks is something that needs to be at the forefront of modern software development.
Unfortunately, in the security profession, there always seems to be a delay between the change in software development and the change in securing that software. Problems creep in when trying to improve development workflow, and providing visible value to both the consumer of the software as well as the development organisation.
Old-school security certainly adds value to old-school operations, but frequent, iterative software releases cannot be protected by systems and methods designed to guard the monolith.
Security needs to evolve!
Old School: Out of the Loop
First, let’s address the chokeholds that antiquated methods put on flow. There are stereotypes that you’ll hear in the IT and DevOps world, which include but are not limited to: painful change advisory board (CAB) meetings, and comically bureaucratic hierarchies of approval for technological change.
Although these processes were initially birthed from a genuine concern for security, they have in many ways lived up to their stereotypes. They have made quick patching, frequent vulnerability analysis, and integrated security ironically difficult, and in the long run, they can negatively affect the security posture of your organisation.
These limitations not only exist in infrastructure, but also in the software development lifecycle. In old-school information security, developers may work on a piece of software for months before a release. Often, security is the last stop on the tracks. When security then finds a problem with the code, the software may have to go through an extensive rewrite. In these instances, security is uninvolved, detached and not as effective as it has the potential to be.
Lean Adds Value
Value is another Lean idea that is negated from the traditional, colossal security. A better way to say that might be the ‘perceived value’. Successful security is hard to quantify, because its correct implementation should have little to show for it (breaches, incidents, etc).
What’s even worse is that really bad security practices seemingly have the same quantifiable results, due to a lack of insight into the threat landscape. This leaves the security engineers, application security specialists and hackers in a difficult position in which they must find a way to express the risk that has been mitigated by the systems they have put in place.
New School: Continuous Deployment as a Security Feature
Successful and innovative companies like Etsy, claim that continuous deployment is their number one security feature. This should be considered across all organisations
First, frequent iterations in both software deployments and infrastructure changes allow for more thorough security and vulnerability analysis. If the change being pushed is small enough, it allows the security analysis to be extremely focused. More possible avenues of exploitation can be examined when the light is shining on only a few changes, and it’s all happening within the existing flow of the SDLC.
Second, continuous deployment forces security into a more intimate relationship with development. When that occurs, security has the opportunity to implement code-level security insight. These metrics can then be taken, and a real threat landscape can start to be revealed. This allows the value of security to be presented in a quantifiable manner. Instead of a “dysfunctional family” dynamic, development and security can start down the road of a more symbiotic relationship.
But How Do We Get There From Here?
Lean practices lend themselves well to progressive information security, but where does one start on this path? Is there developer training that needs to take place? Do policies need to formed and instigated before change can occur?
I don’t have answers to these specifically because the solutions differ between organisations. But I can say that it helps to have resources available to developers and IT operations team members. Technology employees, for the most part, are used to learning and absorbing new concepts but spend the majority of their focus elsewhere. If a simple catalogue of resources can be made available for consumption, it can highly contribute to a cultural shift.
No organisation can be perfect, however integrating high-quality, pragmatic security resources is essential to maximise your risk mitigation. Even if there is a lack of security awareness within a company, a pool of appropriately skilled resources can can have a huge impact once you convince people that security adds value.
There is awesome potential for improving the value that security offer even if you maintain your current workflow. However improving engagement combined with a modernised workflow will transform your your entire security posture. All of this is not to say that there aren’t problems with modern methods — but Agile teams that value Lean principles at least have the framework to evolve quickly to fix those problems.
Where Does That Leave Us?
It is the process of doing security that matters more than the solutions that are in place. Security is the ability to react and adapt in order to maintain the integrity of the data and resources that it is protecting. Security, for better or worse, is dependent upon people. And it is the people that need to create the change.