Automation

Having a proper change control process can really help make our jobs a lot easier. It reduces the amount of risk to the company, can streamline our processes, and really roll things out in a very smooth way. But we can take it to the next level when it comes to automation.

Automating the Change Control Process

When we automate our process, it really streamlines this change control process. All we do is take the input, which is the change request, and from there the plan has already been created with the automation that we create. The evaluation needs to be a lot less because it's already incorporated into this automation process. Implementation goes much faster, and then we can monitor things right after it, we can build that into the automation. So really this whole process can be streamlined through automation.

Not only does it streamline this change control process, but it has all the advantages of documentation. We can create consistency with it, we can improve things over time, it's very efficient, and we can improve the quality of it.

What Automation Is

Automation is just taking what our processes are and, rather than manually doing it, we have some machine do it for us. In our line of work, usually this machine is in the form of software. We have software carry out different functions for us, so all we need to do is set up the software to carry out our different functions, to make control changes, to make configuration changes to our environment.

Let's take a look at an example here. Let's say we're hiring some new people and we're hiring 10 people all at once, and they're already on a spreadsheet. We've got the spreadsheet with these 10 names and all of the information that we need. All we need to do is feed this spreadsheet into our automated software, and it creates the accounts for us and sets them all up and provisions them for us. So this is an example of how we can streamline a process through just a program creating all of those.

Orchestration

There is also a term called orchestration. It's very similar to automation. If we're rolling out a server, maybe we automate the rollout of this server, and so we set it up so that way we push a button and it sets up the new server, maybe in a virtual environment. It does the installs on top of here, joins it to the domain, it does everything for setting up the server.

Well, orchestration is this idea where we could set up whole environments. So maybe not only does it set up this machine right here, but it sets up a database on the back end, it sets up the networking, it sets up all of the maybe routing protocols and everything for this network. It sets up everything of this network and gets it functioning. So think of orchestration as an automation, but it's of the whole environment, or of many multiple pieces that are all being orchestrated or turned up together, rather than just automating one section of it.

If we have code that's automated that rolls all of this out, then you can see how it will be very consistent as we roll this out, and very efficient in how we roll it out. And we can look at the code and say what needs to be improved upon it, because it's going to follow that code exactly the same every time, so we get quality out of it.

Benefits

There's lots of benefits. There's efficiency, time savings — we also call that a workforce multiplier, so that means that we can have one person doing multiple jobs if we're automating a lot of our processes. And then also it could create employee retention, because instead of having people doing these monotonous tasks, they get to do something a little more exciting, like work on the automation and improve the automation. That improves employee retention.

It also enforces baseline configs. There's built-in documentation when you have automation. It automatically documents everything, to include the baseline config, so the configurations will automatically be documented. There's a standardization and a consistency that happens with all of this.

There's a scaling that can happen, because now whether it's 10 people that we're bringing on board or a 100 people on board, it really doesn't take us any more time to do so. We can really scale easily.

It reduces the reaction time. So now when we're hiring a hundred people all at once, we could just run the script and have it really run automatically. So now HR just needs to load up the list and then it will get ran and then it will successfully roll out. So the reaction time can be much faster; between the time that the request is initiated to the time it happens can be much shorter. And then, like I said, there's built-in documentation with all of this, because as part of the programming it documents what's happening.

Use Cases and Tools

There's several good use cases for this, whether we're provisioning users, rolling out new user accounts, maybe we're provisioning resources for those users, maybe we're setting them up with security groups, maybe we're creating certain tickets in our ticketing system, maybe we're using it as part of security incident escalation, maybe we're enabling services and disabling services and access to different resources on servers. Maybe we have it so when it rolls out it also does some testing or QA of it as it rolls out, or maybe that's what the automation is designed to do. Maybe we're using it as infrastructure as code, or doing integration between multiple systems.

Some things that we use to set up automation are things like APIs, which I'll get into here in a second. We can use scripts, which is kind of like lines of code. We can use code as well, but scripts are like a basic form of code that we can use to roll things out. There's also deployment services that we can use. There's software out there that we could use for this deployment, whether it's to build the code, or take the code and build it for testing the code or testing the services, and for deploying the services. So there's a lot of deployment services that help us roll things out in an organized way.

SOAR

One thing that does automation is a SOAR system. SOAR stands for security orchestration, automation and response. Essentially what this is, it's software that helps automate our responses to incidents. So if there is an incident that we need to respond to, it can help organize and take an automated approach to fixing the issue, so it can help us implement security controls in a very quick manner.

APIs

One thing that helps us with automation is something called APIs, or application programming interfaces. APIs allow us to communicate between different systems, systems that might not be very related to each other, but still allows us to communicate between these systems.

Let's give a couple examples here. Let's say we have a server right here and it needs to communicate with a database. What it can do is it can make API calls to the database. It's a certain format of how it's going to be requested, so it's going to make the request in a certain format, and then this database then will respond with information, respond to that request.

We can do it not only between a server and databases but also between servers. So maybe this is running service A, let's say, and we have service B over here. What will happen is that service B will create an API call that will call service A, and it's a certain format, and the reason why service A can read it is because it's in that format. And service A then responds to service B and says, all right, here's the information you requested, because of the API, because of the request that you made.

So APIs help us incorporate different systems. Where we might see this is maybe we're provisioning accounts, and this is the server that provisions the account, and maybe it's making API calls into a directory services where there's a bunch of user accounts. And so it will then start setting up the user accounts inside this directory service by making these API calls.

CI/CD

There's this term CI/CD, or continuous improvement, continuous delivery. These both mean separate terms here, but together they kind of mean a methodology or an approach that we use to rolling out automation, rolling out software, rolling out code changes.

This is a common symbol that you'll see for CI/CD. Where I'm at, I'm at this blackduck.com, where it talks about what CI/CD is, and it talks about how you go through the planning, you develop code, you build the code, you do continuous testing on it, you release it, deploy it, operate and monitor, and then this is an endless loop here that continually goes. The idea is that we're continuously improving it, we're developing code and building it, and we do continuous delivery, that it gets released right away.

There is a bunch of software that's associated with this. The other tab I have here, I'll open it up, shows you the CI/CD software that's associated with deploying. In a lot of these cases it's deploying code, but we can use it to deploy infrastructure, and we'll talk about infrastructure as code here in a second. But we can automate things and deploy with things like Jenkins, and we can be able to utilize this software for these deployment purposes.

The term continuous improvement, or CI, by itself just means we're constantly improving things. So here we're identifying issues, or we're identifying what we need to change, we plan the change, we implement it, and then we monitor, and we just do a continuous improvement. This never stops, and we keep getting better and better and more proficient and faster and faster, and delivering higher and higher quality. So we're continually improving.

The term continuous delivery, or CD, just means that we continuously deliver the product that we're creating. Think of it as a truck versus email. With a truck, what are we going to do? We're going to load up the truck before it leaves the station so it can go and make its delivery. We're going to load it up with everything that it needs to make that delivery, to make it efficient. We're not going to drive that truck out somewhere where it just has a package in it, or probably not going to anyways. We want to fill that truck up before it leaves the station. But email, we send it as soon as we get it, and that is a continuous delivery model.

So in the example of software, if we're developing software, a deployment model that is not continuous delivery means that we have a bunch of different software, or different changes, different code that we're going to deploy. We kind of save it all up and then we have one night that maybe we just roll it all out all at one time, and we make all of these changes all at one time. Versus continuous deployment means that as soon as somebody's done developing the code, they hit a button, it deploys. There's pros and cons actually to both of these methods; there are advantages and disadvantages of each of these. But this is a common delivery method that we see with software nowadays.

Infrastructure as Code

We also have infrastructure as code. The idea behind infrastructure as code is that we're going to deploy our servers and our databases and all of our infrastructure, our networking — we're going to deploy it using code.

Typically what this has been in the past, it's all been a manual process. We get a new server, we install it on the rack, we turn it up, we install the software on it, we install all the services on it, and then we do the configuration on it. But with the virtual world we don't need to do all the physical aspect, and we can use automation tasks to make that happen. So we can have templates, we can have scripts, we can have dat, that all goes into this process, this automation process, and deploys the whole infrastructure. So that's infrastructure as code.

The Downsides

It's not all advantages though. There is a cost to developing the code initially. There's a lot of setup to get it worked from being just a manual process to actually being an automated process. There's a complexity in it as well. There's somebody that can set up a server manually, but they might not necessarily know the code to set up that same server. They need to have extra knowledge about how to set up that code just to make this all happen, so there's a complexity to it as well. There could be a single point of failure here, depending on how we set it up.

There's something called technical debt. Let me give you a good example. We set up a continuous deployment, we did infrastructure as code where we could push a button and it sets it all up. Well, things changed over time and the people that created that left the company, and other people were there and so they were stuck managing that system. And we also were transitioning to new systems, and so we were kind of stuck in between all of this. Well, the technical debt is that old system that we were trying to get off of. That's called technical debt. That is stuff that we're still stuck managing until we get everything moved over to the new system, and it can very much bog us down. And then there's just, like I have alluded to, the ongoing supportability of this code can be frustrating at times.

Getting Started

There is a great way of getting started. If you have a document that lists out all of the steps to do a procedure, you don't necessarily need to have all of the steps automated at once. You just go through the procedure and look for the low hanging fruit, the stuff that you can automate, and you automate that step. So you do all the steps prior, then you press a button and that happens, and then you do all the steps after. And then you slowly convert this over to everything being automated. At some point in time you can press the button and the whole process gets executed. So this is how I would get started when rolling out infrastructure as code.