I've talked many times about the productivity benefits from automation. In this episode, I talk about the security benefits we get from automation - something you could describe as a side-effect. I discuss:
Or listen at:
Published: Wed, 15 Jun 2022 15:23:11 GMT
Links
- Episode 14 - Software Testing
- Episode 19 - Continuous Integration
- Episode 20 - Continuous Delivery
- Episode 21 - Continuous Deployment
- Episode 119 - Shifting Left
- Episode 135 - Infrastructure-as-Code
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
In this episode I want to talk about some of the side-effects we get with automation, specifically around security.
Now normally when I'm talking about automation, I'm talking in terms of productivity, convenience, reliability. That productivity of letting the computer take the strain. That convenience of being able to run any time. And that reliability of avoiding manual mistakes.
Take, for example, if we're automating our testing, we're letting the computer do that testing repeatedly, avoiding manual effort. The convenience of the computer being able to run it repeatedly at all hours, much easier than at getting somebody to manually do it. And of course, the reliability of the computer doing the same thing over and over again, rather than potentially as having mistakes and false positives or false negatives from manual effort.
So while automation is definitely good for productivity, convenience and reliability, one thing I've probably haven't spent enough time on is talking about the benefits we get for security - and I'd argue many of these are side-effects. I'll talk through the side-effects during this episode - and in some cases I actually begin to wonder if they actually may become a real justification for automation in their own right.
During the course of this episode, I'll reference a number of practises that I've talked about previously. Let's take a moment to quickly recap them.
Automated testing.
Testing of our software is critical. If we don't test it as part of our development process, then it will be our users, our customers that will be testing it for us. But testing can be a time consuming activity. By investing time in automating that testing, we make it practical to run often, potentially even continuously. It provides us a safety net to move quickly and will tell us rapidly if we have inadvertently broken something. I talk more about testing in Episode 14.
Continuous Integration, Delivery and Deployment.
We need to build our software for it to be useful. Historically, we may have done that on a local developer machine, often resulting in the "it worked on my machine" response.
Continuous Integration provides us with dedicated servers to build that software. It provides a consistent clean result and isn't subject to the vagaries of individual developers setups. And it's also a great place for us to run our automated tests.
Continuous Deployment takes that built software and allows us to deploy it to our service at the push of a button. We automate the manual actions needed to download, install and configure our software, avoiding many of the mistakes that come from the manual approach and allows us, again, to do it quicker - changing something that may once have been an overnight or even a weekend event to being a trivial activity, something that can realistically be done multiple times per day. It also provides us a place to run further automated tests against our production releases, quickly highlighting any issues and allowing for rapid rollback.
Continuous Delivery then takes that one step further and removes the need for us to manually press the button by automating all of the approval activities - all of the things that led up to us being allowed to press the button under Continuous Deployment - we entrust the system to ensure everything has been done. Again, we are avoiding the manual mistakes or missteps, or maybe not even knowing how to progress if we were doing it manually. We make it repeatable. We provide time savings and again allows us to cut down on the time it takes to get that investment we've made in our developers working into production where we can see the benefits.
I talk about Continuous Integration, Deployment and Delivery in episodes 19 to 21.
Infrastructure-as-Code.
This allows us to document our infrastructure as software code. It allows us to build our servers, our networks, our storage, etc - all of the things that we need to be able to put our software on - as instructions that can be automated. Traditionally, building out our infrastructure would be a time consuming, laborious specialist and quite often error prone activity. And prior to the cloud, it could also be expensive and could have considerable lead times. With Infrastructure-as-Code, and the cloud, we can now produce our infrastructure to run our software quicker, cheaper, and with much less errors. I talked about Infrastructure-as-Code in the last episode 135.
And finally, Shift Left.
Shift Left is about moving parts of our development process earlier in our work. If we consider our software development process as a conveyor belt, it's easy to see each action as a station moving from left to right - business analysis, design, development test, etc.. - by Shifting Left, we bring some of those later activities in earlier. We Shift them Left in our conveyor belt analogy. So for example, for testing, rather than being left to the end of the process, the right hand of the conveyor belt, we move parts of it left doing it earlier, which allows us to act on the results as we build the software. It allows us to make many small course corrections to keep the work on track rather than traditionally us waiting to the end of maybe a 24 month project, only to find that our testing identifies ruinous problems. I talk more about shifting left in Episode 119.
I'll include links in the show notes to each of those episodes.
So I'm looking to talk about seven Side-Effects that we get from automation:.
- the ability to reduce access to our production systems
- the ability to reduce manual interpretation (and basically removing mistakes)
- the ability to get logs of everything that's done
- the ability to make controllable environments.
- the ability to run automated security tools often and during the entirety of our development process.
- and the ability to sign our software.
But let's take each one of these in turn.
So let's start with the reduced access by us automating many of these processes. We no longer need to give as much manual access to our systems. We don't need our developers, and in some cases even our operations staff, to be able to log on and do stuff on the servers.
And this greatly helps us to increase our security profile by reducing the number of people that should be on those servers. It becomes obvious when someone goes on there that shouldn't be going on that.
Think about a security vault in a bank - that isn't public access. You shouldn't have people wandering in and out of that vault on a constant basis. Thus, if somebody does go into the vault, it's an obvious event. People can be watching it and can see what happens. And by using automation techniques such as Infrastructure-as-Code, Continuous Integration, Deployment, Delivery, we should need less manual access to those servers.
Thus it does become much more obvious that if somebody accesses it:
- Is that right?
- Is that correct?
- Is it right that that developer is accessing that system at that time?
It becomes much easier to get a better noise to signal ratio. It becomes much easier to see the wood for the trees.
And of course, by virtue of less people having access to those production servers, there's less chance of that being exploited. There's less chance of people losing the credentials. There's less chance of attackers being able to gain access to our systems because somebody has accidentally left their credentials lying around.
Let's move on to making it less open to manual interpretation.
If, as a human, I go on and have to do a series of tasks, I may have those tasks, written down or may maybe doing them from memory - either way, there's a very good chance, if it's a complex long series of tasks, I could miss one or get it wrong, or misunderstand the intent of the task in the first place.
And there's nothing to say that the entire team will interpret those instructions in exactly the same way. Each person may look at those instructions and interpret them slightly differently - leading to different outcomes, potentially leading to security holes - because we're not following the instructions correctly.
Whereas if we automate, the computer will follow the instructions in the same way time and time again. Now those instructions could be wrong, and that could be good, because rather than where as a human we will try to guess, we will try to fix the problem, we will try to fix what's missing - the computer will stop. The computer will go "No, this doesn't work".
And by knowing that something doesn't work, we have the opportunity to fix it. We have the opportunity to iterate on the instructions we are giving the computer to carry out. Thus, we can be much more confident that it's doing the same thing over and over again.
We remove that well-meaning human tendency to try to fix problems, to solve ad hoc problems, which more often than not will simply never go back into the documentation and nobody will be able to repeat it going forward. By the computer diligently following the instructions we give it, it will repeat it, exactly.
And as I say, there's actually value even when those instructions are wrong - by virtue of the machine not being able to complete an action or missing a step, it becomes obvious because it hasn't tried to fix the whole. And by having that ability to review and iterate over the instructions that we give the computer, we gain a level of security control.
By delegating that control to the system, it makes it much more secure than the manual steps - because of course, they can be reviewed and iterated. And again, we would find this when we're doing our Infrastructure-as-Code or Continuous Integration, Continuous Deployment and Continuous Delivery.
Let's move on to logging.
Automated systems can produce a lot of logs - and it's just done automatically - it's done by the tool that performs the automation.
Whereas if you think about some of these steps, if we were doing them manually, can we really expect someone to be making a note of all the steps they've taken?
More often than not, they will just say they've followed whatever checklist they've been given. Now, again, I go back to that point I made earlier, every member of the team may interpret a set of instructions slightly differently. They might know in some cases, based on historical experience, to do this then or may need to change this to that.
The computer doesn't. The computer does exactly as it's told. And thus we have those logs of exactly what was carried out by the service and by having that logging. We have an audit trail of everything that has been done. We know which version of the software is installed, where and when - we know what initiated that install.
For example, for one client I was able to use their logs from their Continuous Integration and Continuous Deployment to understand which versions of software were installed six years ago. It gave me an ability to see what happened in the past, something I wouldn't have been able to do if that software had been installed by hand.
Let's talk about controllable environments.
Here, I'm talking about having a clean machine to do that software testing, that software build, that software deployment - versus using the developer's machine.
Certainly historically it was common that we would build and deploy software directly from the developers machines. But we found this was bad practise. At the end of the day, the developer is using the machine for many things. They'd be browsing the Internet. They'd be reading emails. They would be doing various activities. All of these activities are exposing their computer to potential security risks. Say, for example, if that developer's machine received a virus via email, then that could influence what software we build and release into our production environment.
Whereas if we're using dedicated machines that are built specifically for the tasks of Continuous Integration, Continuous Deployment, Continuous Delivery, then they're not being used for other activities - and as such, their cleaner - we can have confidence that those machines are much less likely to have any security problems than developed ones.
And again, because they are a controlled environment similar to the manual access to the production servers, they're like that bank vault. It's much more obvious, much more easy to tell if someone has been onto those machines and thus questions can be raised.
Okay, let's move on to automated security checks.
Now, this could be argued that automation here is an enabler rather than necessarily security checks being a side-effect. But by having the automation, it provides us opportunities to do much more security checks than we would have done previously.
Now I've talked about the dangers of things like supply chain attacks back in Episode 110. We can find that the open-source libraries that we use, or even 3rd party products, or even operating systems that we use, can all become vulnerable to attack. And by virtue of our software relying on them and building them into our products, we potentially could actually take a vulnerability from an upstream dependent source.
And this is becoming more and more common as our modern software development relies so much on open-source software. If a vulnerability is introduced into that open-source software, and we're not aware of it, then we can then effectively inherit that vulnerability into our systems.
And of course, as this threat grows, a growing ecosystem of open-source and paid products are available to help us are available there to do automatic checks for vulnerabilities - whether that's checking at the development time to see whether or not we've included invalid libraries, checking during our Integration, Delivery and Deployment processes, or even post delivery where we can run automated vulnerability tests.
There are many products out there that can help us in doing this. And this all falls into the shift left mentality I talked about in episode 119 - it moves that security checks early into the process. Rather than us building a software product for 24 months and then only checking the security of it at the end, by being able to do these checks during the development changes, during the Continuous Integration, Delivery, Deployment and even post deployment during our testing phases, we're able to be testing earlier.
We've shifted the function left. We've moved the security checks earlier in the conveyor belt, and by doing so, we're picking them up earlier. We're making sure they can be addressed. We are making sure that they're being picked up and handled by our software development team - as opposed to at the end of that 24 months, any problems we're finding are either having to be accepted by the business as a risk or potentially causing so much work to the software that it becomes financially infeasible to resolve them.
Combined with Automated Testing, Continuous Integration, Delivery and Deployment, using these products help us to firstly identify issues quickly, and then fix them and release them quickly with confidence. Ultimately the automation makes these security tests as we develop practical.
And finally, let's talk about using automation to sign our software.
Again, this might be an example of where automation is an enabler rather than necessarily signing be a side effect of it. So firstly, what am I talking about when I say signing our software?
Think about it as any contract, you would sign a contract to prove that you've agreed to it. You're using your written signature as a way of proving that it was you that reviewed and accepted that contract. Anyone that comes along later can review that signature to say, yes, it was you that signed it - and thus we can have confidence that it was checked and accepted correctly.
Within software development, we have a very similar thing. Using modern cryptography, we can effectively sign software. By doing so, we can do two things - we prove its authenticity by having signed it, we can be confident that it came from a specific source, and we can tell if the software has changed since it was originally built.
Now signing software can be done by hand. It can be done by the developer. But think about this in terms of how many people do you really want to have that authorised signature available to them? If all of your developers can sign software, are we then starting to think of it more like headed notepaper rather than that an authorised signature?
During the automated build of the software during Continuous Integration, this is a perfect opportunity to sign that software. If we are configuring that Continuous Integration server to have the ability to sign the software, we reduce the number of people that have the ability to sign the software - again, making it much more of an authorised signature than just headed notepaper.
And of course, I've talked already about having a more controllable environment, if we're using things like Continuous Integration, because we've got specific machines that are kept away from the normal day to day - that are there for a specific purpose, that can can be controlled, can be checked, can be audited separately from any developer activities.
By having our Continuous Integration process automatically sign our software as it builds it, we can use that signature as a proof - a proof that it came out of our systems and it hasn't been altered. This can give us, and indeed any third party that relies on that software, confidence of where it came from. It helps us to provide confidence that the software we have in hand is the software we were expecting.
In this episode, I've discussed the security side-effects of automation.
I've talked about the ability to reduce access to our production servers - making it much less likely that people need to access them, making it much more obvious if someone does, then there's probably a question to ask.
I've talked about removing some of that manual interpretation - that manual fixing of steps which just don't seem right. Thus making sure that we've got a repeatable process that's available to us at all times.
I've talked about the logs that get created by these systems that provide us an audit trail of what happened and when.
I've talked about controllable environments - those servers that we're using for our Continuous Integration, Continuous Deployment, Continuous Delivery. By them being separate servers, we have confidence that they are less likely to be compromised and of course we can protect them better than we can our own developers.
I've talked about how automation can be an enabler for running security tools. The growing ecosystem of open-source and 3rd party products that help us to shift those security checks left, to do them earlier in our process. To make it practical that we can actually do them while we're developing, as opposed to leaving it to the end of the project and potentially nullifying any work that has been done before.
And finally, I talked about how automation could enable us to be able to sign our software. By signing our software, we have that confidence that it hasn't been changed and it comes from a known source.
And along the way I've talked about the various opportunities under which we can do some of this, whether it be our Continuous Integration, our Continuous Delivery, our Continuous Deployment, our automated testing, or Infrastructure-as-Code.
I certainly believe that automation gives us some wonderful side-effects when it comes to security. But I'd also say that many of those benefits on their own are justifications for automation.
Hopefully this episode has given you some to think about in terms of both how you use automation now and how you might be able to use it better going forward for security.
Thank you for taking the time to listen to this podcast episode and I look forward to speaking to you again next week.