Hello, my name is Tyler Welton. I am a Security Engineer at Planview AgilePlace and I love it. I spend a large portion of my time fulfilling both defensive and offensive security duties for our web application, infrastructure and security culture.
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. I think it is probably 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 organization.
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 catch up.
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 an organization.
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.
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
I heard a conference talk by Zane Lackey, formerly of Etsy, who made the claim that continuous deployment was their number one security feature. This has been true at Planview AgilePlace as well, in a number of ways.
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.
Getting Started with Lean
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 organizations. 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.
We are not perfect here at Planview AgilePlace, but I have been blessed to work with some very security-minded people. But even if there is a lack of security awareness within a company, a pool of relevant resources can go a long way. We are a team, after all.
There is awesome potential for improving the value that security offers, while maintaining and even improving modern workflow. 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.
Final Thoughts
Bruce Schneier said, “If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” 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.
![A Global Collaborative Work Management Blueprint [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
