The Three Ways of DevOps
Applying least privilege to cloud instances without adding bulk and delays to your pipeline.
In this article we will explore applying the security concept of least privilege to your cloud instances, within a DevOps environment, without adding bulk and delays to your pipeline.
DevOps is not a tool that you buy, or the act of using pipeline software to release your code, it is so much more. Let's define DevOps, then the three ways, then let’s apply least privilege.
Although there are many different definitions of exactly what DevOps is, the most popular definition is from the Phoenix project and the DevOps Handbook. We will follow this definition in this article.
DevOps is a way of developing software, as well as a culture within a software development shop, and a mixture of processes and tooling that helps you get there.
In Order to do DevOps, You Must Follow the Three Ways of DevOps
The first way of DevOps is to emphasize the speed and efficiency of the entire system, instead of just your part. Sometimes this means that you have to help another team do their work, rather than your own, because that will make the entire system so much better. Sometimes this means, asking for help from other teams. Often, automation helps with this, which is why we use a DevOps pipeline software, in order to release and deploy our code quickly and efficiently. Automation generally results in fewer errors, and it almost always results in much faster results. This is the first way of DevOps.
The second way of DevOps is fast feedback. This means getting feedback to the correct person or people, in a timely manner. It also means the feedback needs to be accurate, because feedback that is inaccurate is not only unhelpful, it is potentially harmful. We add security testing, and all sorts of other quality tests, to our pipeline software in order to ensure the code that we are creating is high quality, and so that we get very fast feedback. That said, a pipeline is not the only way that you can get feedback, we will talk about this when we apply least privilege.
The third way of DevOps is continuous learning. This means setting time aside on a regular basis to improve your daily work. Sometimes this means training. Sometimes this means tuning your tools or doing a proof of concept of several new tools that you are considering ensuring that the one you choose is the absolute best for your specific business needs. Sometimes this means introducing artificial intelligence and machine learning into your systems or tooling, to ensure that it is continuously learning. The point being that you want to be in a constant state of striving for improvement.
Quite often when people think of DevOps, they assume that every single tool or test must go into the pipeline. This is not true. We need to abide by the three ways of DevOps, and that definitely means using pipeline software and putting security tests inside of it, but our work is not done with just that. We cannot possibly complete all of our security requirements within a pipeline.
Least Privilege and the Three Ways
Now we could attempt to put some tests for least privilege in our DevOps pipeline, however, what would we test for? If a permission is included in the pipeline, it's likely because the software developer assumed that they would need it. What test could we put in a pipeline that would clarify whether or not a permission was actually required? To see if it is in use, or not? This means, it is unlikely we can test for this in our pipeline.
Instead of putting a test in the pipeline, we could set up monitoring in our systems of new processes, to watch which permissions are actually being used and which are not. Whichever permissions are not being used, could be removed, in order to implement least privilege. Now, let's look at how we can apply this to the three ways of DevOps.
The first of the three ways, to repeat, is speed and efficiency of the entire system. By not putting a tool like this in the pipeline, this would not slow the pipeline down, and that would increase the speed of the system. Instead, we could create automation outside the pipeline, to ensure that this work was done quickly and efficiently, that would obey the first rule for instance, if we had a monitoring tool that did this for us. Let’s take this imaginary monitoring system with us to the next way.
The second way is fast, accurate and timely feedback. Let’s say our automated monitoring system that is watching all of our processes to see which permissions are being used, it gives feedback quickly and to the right people [the security team], that would be a very handy tool. If it could automate removing unused permissions, tell us if someone tries to use a removed permission, and shows us reports of both, that would certainly fit well into the second way. Having it also automate sending alerts and creating tickets would be a cherry on top of all of this; feedback going directly to who needs it.
The third way involves continuous learning. If our automated monitoring system, itself, can learn continuously from the traffic, access, and behavior of our cloud activity and users, then that respects the third way. A system that can train itself, learn when to remove permissions, when to replace permissions, and when to block access, not only respects the third way, it makes for a fantastic least privilege security tool. With enough learning (monitoring), a tool can even start to recommend which access policies would be the best option, given specific situations and previous decisions.
Although many people seem to think that DevOps tools need to go in a pipeline, this article makes it clear that you can still respect the three ways of DevOps and work within DevOps processes, without having your tool in the pipeline. And gain fantastic security results to boot!
About the Guest Author
Tanya Janca, also known as SheHacksPurple, is the author of ‘Alice and Bob Learn Application Security’. She is also the founder of We Hack Purple, an online learning academy, community and weekly podcast that revolves around teaching everyone to create secure software. Tanya has been coding and working in IT for over twenty years, won numerous awards, and has been everywhere from startups to public service to tech giants (Microsoft, Adobe, & Nokia). She has worn many hats; startup founder, pentester, CISO, AppSec Engineer, and software developer. She is an award-winning public speaker, active blogger & streamer and has delivered hundreds of talks and trainings on 6 continents. She values diversity, inclusion and kindness, which shines through in her countless initiatives.
Founder: We Hack Purple (Academy, Community and Podcast), WoSEC International (Women of Security), OWASP DevSlop, OWASP Victoria, #CyberMentoringMonday
