CompTIA CYSA+ CS0-002 – Automation Concepts and Technologies part 1

1. CI/CD (OBJ 3.4)

CICD. In this lesson, we’re going to talk about three concepts. This is known as continuous integration, continuous delivery, and continuous deployment. Before we do that though, we really have to take a look back to the way the code is made and deployed in most of our environments. Now, in the old days, the way we would do things is very linearly. We would start out with development and we would start taking the code and putting it together and figure out what it’s going to do. Then we would move into testing and integration, where we would put it into some kind of a test environment and make sure it didn’t break anything. After that, we would start the integration process, which means we might be buying new servers and we might start installing all the software to see how it’s going to operate in that full environment.

After that, we’d move into staging. Now, staging is where we’d actually put things into a set of servers that look like our production environment, getting ready to move from testing into staging and then from staging into production. Which brings us to our final step, which is production. This is when that piece of software is actually deployed onto those servers that are being used by your end users. Now, this was a very slow process, especially if you did it one step after another. And the challenging thing is that these steps were all run by different people. So when you had developers, that was your programmers. They had one role and then they would send it over to another team who did testing, and then they would send it to another team that did integration and staging. And finally you had the operations folks who took it from staging into production.

And so there’s a lot of handovers and a lot of problems here because things were moving from one step to another and there would be a lot of internal conflict within your organization. Now, the concepts involved with CICD tries to eliminate a lot of that. It tries to speed this process up. For instance, I worked at one organization where when we wanted to add a new feature, it could take nine to twelve months to go from development all the way through to production. So instead, with continuous integration workflows, you can actually speed this process up a lot. When you’re dealing with continuous integration workflows, you have a common source repository. Everyone ends up checking in their code to this common source. Now this can be your managers, your developers, whoever’s working on it.

Then, when you’re ready to get this thing running, you can take it from that common source and pull it into the continuous integration server. At that point, it gets built. That means it compiles the code, it tests the code, and then it tells you whether or not it succeeded or it failed. And then based on that, it can go back to the developers for the next step, which might be moving into testing, moving into integration, moving into staging, moving into production. But by doing this you can automate a lot of this function. So when we talk about continuous integration, this is this first piece of this. Continuous integration is a software development method where code updates are tested and committed to a development or build server code repository rapidly.

So this allows us to create something, test it, and then once we know it’s good, we can say this is ready to be implemented in the environment. Now, by itself, continuous integration doesn’t do that much for us in terms of speeding things up. Yes, we are shifting left a little bit here and we’re letting our developers do some more of the testing, which is always a good thing. But continuous integration can do more than that. By using continuous integration you can actually test and commit updates multiple times per day. So going from that feature taking nine to twelve months, we can now have systems where we’re doing continuous integration 510, 20 times a day if needed. Now how do we get that fast though? Well, that’s where we have to bring in continuous delivery and continuous deployment.

Now, when I talk about continuous integration, it’s really focused on detecting and resolving development conflicts early and often. So remember I said here in the workflow we have all of our developers who are using the same sources. Well, if I’m doing something where I take a big feature and it takes 100 developers to work on it, that’s 100 different people making changes to code. If they’re all working on it and they’re working on these things and they’re checking out for maybe a week at a time, or two weeks at a time, that causes divergences from what we started with a week ago to where we are a week later. Because as you’re working on something and I’m working on something for a whole week, that means we have a lot of differences.

So instead with continuous integration, we’re constantly taking our code, we’re doing these integrations, we’re testing it and then putting it back to the master. So we’re all working from the same sheet of music. This way we’re making sure we don’t have these big changes and these big conflicts. Now, if we want to take this a step further, we can actually start speeding up the delivery of things. And this is known as continuous delivery. Now, if you’re going to do continuous delivery, you have to do continuous integration. But just because you’re doing continuous integration doesn’t mean you’re doing continuous delivery. These things are not a equals B, and B equals A. It’s more like if you have A, you can do B, but if you have B, you must be doing A.

Now, when I talk about continuous delivery, this is a software development method where the application and platform requirements are frequently tested and validated for immediate availability. So I go out and I code some new feature. I test it through continuous integration. Now that I’ve tested it, I can go through continuous delivery, which means it’s going to go through all the tests, all the compliance, and all the validations. So it’s now ready to be installed on that staging server or into production. Now, I’m not actually going to go forward and install it on staging or install it on the production server. That’s not continuous delivery. That is continuous deployment. Now, with continuous deployment, we take the concept of continuous integration and continuous delivery, and we take it even one step further.

Now we have a software development model where application and platform updates are committed to production rapidly. Essentially, I’m going to create some new piece of code, maybe a security fix. It’s going to go through the integration testing. Once that’s been approved, it goes back to the code repository. At that point, we can go through and do continuous deployment where it gets tested and ready to go into staging. But instead of just sitting there waiting for somebody to actually install it in staging, with continuous deployment, we can take that code and actually deploy it to staging, and then at regular intervals, move things from staging into production.

This allows us to do things much quicker in terms of deployment and release cycles. Now, when we talk about continuous delivery, I want you to remember that continuous delivery is focused on automated testing of code in order to get it ready for release. Not released, just ready for release. Now, when I talk about continuous deployment, I’m taking it a step further. I’m focusing on automated testing and the release of code in order to get it into the production environment much more quickly. Now, what are the real big benefits here? Well, think about it like this. If you’re dealing with something like coding a security fix, do you want it to take three weeks or three months or three years to get it out there? No, you want it out there right now.

And so by doing continuous integration, continuous delivery and continuous deployment, you can shorten that cycle and get things out today or even within a couple of hours. Now, for the exam, these concepts are just a few quick topics that we need to cover based on your textbook, but you’re really unlikely to get many questions on these during the exam. This is really much more focused on software development, lifecycle and things of that nature. If you get into It service management and you start working in devseek ops, you’ll probably become very familiar with these terms. But for now, I just want you to be introduced to them and to cover over them, because I want to give you a full coverage of your textbook.

2. DevSecOps (OBJ 2.2)

Dev SecOps. In this lesson we’re going to talk about DevSec ops. But before we do that, we really have to take a step back and talk about DevOps. Now, DevOps was created to speed up the development and get things into production faster. As I mentioned, DevOps really relies on the concepts of continuous integration so that we all can be working together on the same thing and make sure we don’t have big divergent changes. Now, when we talk about DevOps ops, this is an organizational culture shift that’s going to combine the software development and the systems operations people into one team. This is basically the practice of integrating these two disciplines within a company. So often, especially if you were ten or 15 years ago, you would see this type of a paradigm where you have development all in one area and they all work together.

And then you have all the operations folks who have to operate and maintain these systems and they’d be off in another area. And so development would code something and then throw it over the wall and then operations has to live with it and support it. Now this is a problem because this led to developers not doing their best work. And what I mean by that is there was a lot of security bugs, there was a lot of feature bugs, and a lot of things just didn’t work right. And so somebody had the great idea about ten or 15 or 20 years ago to create DevOps, which was, let’s take some of these operations folks and put them in with developers and some of these developer folks and put them in with operations.  And so we make these smaller teams where they work together.

This way when a developer creates something, the operations team can support it. By putting operations and developers together, you can build, test and release software faster and more reliably because the people who are building it are also the people who are supporting it right? Now, one of the problems with this though, was a lot of things were getting very quick into operations and then security came along and said, oh, this isn’t secure, there’s problems here. We need to fix all these vulnerabilities. And you didn’t do this within compliance for HIPAA or Goba or Sarbanes Oxy or whatever. And so this was another problem.So they said, well, if putting dev and ops was good together, giving us DevOps, well, why don’t we just add security in there too? And that’s essentially what they did.

And they call it DevSec ops. Now, this is development security and operations, and it’s a combination of software development, security, operations and systems operations by integrating with all those disciplines together in one team. Now, this is a great way of doing things because when you’re using DevSec ops, this is going to utilize a shift left mindset. Now, what do I mean by shift left mindset? Now? We haven’t really talked about what shift left is in this course because it’s really not a concept that’s focused on security. When we talk about shift left, it actually comes from the information technology service management world. When we talk about shift left, think about it like this. You have a series of steps that needs to be done.

And for instance, if I talked about the software development lifecycle, we could use that as our example. You’re going to have some kind of a plan. You’re going to design something, you’re then going to build it, you’re going to integrate it, you’re going to put it into staging, put it into production that goes through all these different series of steps. Well, if you notice that eight step methodology in the waterfall method around step four, five or six is we can actually start testing things and then you start thinking about security towards the end. Well, with shift left, we’re trying to shift it left or earlier in the lifecycle.

So the idea with dev SEC ops is take security, which used to be the last thing that happened, and put it all the way back in the beginning with the developers so we can think about it from the beginning. That’s the idea of shifting left. It’s moving things earlier in the life cycle and to earlier people in the chain. And in this case, by doing dev SEC ops and integrating a security person with the development and operations people, you can build more secure systems and get them fielded faster. Now, what are some big benefits of doing DevSec ops? Well, for one, you’re going to integrate security from the beginning. This is always going to be a good thing because it’s cheaper and easier to put security in from the beginning than to add it on later.

Another thing you’re going to do is you’re going to test during and after development. So we’re not going to wait till step five or six to do our testing? No, we’re going to write a block of code and we’re going to test it, and then we’re going to integrate it back using continuous integration to the master code base. And this way we can have 50 or 100 programmers working on something at once and not have a bunch of code conflicts because we’re all getting things back in early.If we waited a week and then I had 50 changes to put in and you had 50 changes to put in, that can create a lot of conflicts, especially if we both change the same line. But if we commit our changes very frequently, every couple of hours or even every day, that’s going to have a lot less conflicts.

And then the third area is we’re going to automate our compliance checks. Now, this is another great thing about DevSec ops because we have developers and they can build things with code, right? And so if they go through and code something like automate compliance checks, we can have all these things that are scripted. So when you create a piece of code and you happen to work in a hospital, well, guess what? We’re going to run it against the HIPAA compliance checks and make sure everything is within compliance. This way we could figure that out very early before we go into production. And that way we can fix those issues faster and save us a lot of time and effort.

3. IAC (OBJ 1.6)

Infrastructure as Code or IAC. Now, when we talk about infrastructure as code, this is a provisioning architecture in which the deployment of resources is performed by scripted automation and orchestration. Now, we mentioned the fact that we use scripted automation and orchestration in cloud computing all the time. And when we do that, we’re really doing infrastructure as code. Now, this is key to the Dev SEK Ops culture because it gives our team teams the ability to rapidly deploy things within the time frame of what they’re working on. And because they have operations personnel already there and security personnel already there as part of that team, it’s not any less secure by doing infrastructure as code. In fact, you’ll find it’s actually more secure.

Now, why is it more secure? Well, because it allows for the use of scripted approaches to provisioning infrastructure in the cloud. And the great things about scripts is they don’t make mistakes. Once you have a script and you know it’s working and secure, it’s going to run that way every single time. So this is going to allow you to get a lot of those configurations done and the provisioning done in a much more secure manner. Now, when we talk about infrastructure as code, it really comes down to three key areas. Part of this is going to be those scripts I just talked about, part of it is going to be security templates and part of it is going to be policies. And by applying these three against your infrastructure using this approach, you’re going to have much more secure infrastructure. Now, when we talk about this, we are going to have to think about our orchestration.

And if you have robust orchestration where you’ve tested it and you know it works well, then you can lower your overall, it costs, speed up your deployments, and you can increase security. So this is really a win win. It’s all goodness here. Now, one of the things you have to be careful of though, when you’re doing this infrastructure as code, because we’re using templates and standardization for everything, is people who want to have their special snowflakes. Now, when I talk about special snowflakes, you have people who think they just have the best idea and therefore they have to be able to go and create their own infrastructure the way they want to do it and they don’t care about your standardization and your scripting and all the efficiencies you’ve gained.

And so they create something that is a one off system. Now, when you’re a big advocate for using orchestration and using scripts and using standardization, sometimes you’re going to face some friction at work because somebody thinks they have a better idea and they have this special snowflake system that they just have to have and they can’t use your standard templates. Now when that happens, you end up with a special snowflake system. And these snowflake systems are any system that is different from the configuration that’s compared to the standard template within the infrastructure’s code architecture. Now the problem with this is it adds to security problems, it adds to configuration problems and supportability problems.

This lack of consistency is going to lead to a lot of issues for you, especially in terms of security and inefficiencies in supporting it. This is because once you have a one off system it’s unique and it doesn’t apply to everything else. Think about if you’re in a large environment that’s operating in the cloud and you have thousands of virtual machines and out of those thousands of virtual machines, one is different. When somebody calls up and says something isn’t working, you have to figure out is it that one exception or is it the thousands of others that are all working? And that becomes more of a support issue for you and it leads to a lot of security headaches. Now the last thing we need to talk about in terms of infrastructure as code is inimpotence.

Now this is a property of infrastructure as code that automation or orchestration action is always going to produce the same result regardless of the component’s previous state. Essentially every time you give this input, you should expect this output. Anytime you call up this script, it should be doing these functions and it should do it every single time. That’s why we want to eliminate those special snowflakes because we want everything to be consistent. Now by doing this and using carefully developed and tested scripts, we can end up doing orchestration really consistently. We create these run books that are going to do all the steps for us.

That’s what we call a script inside of orchestration and it’s going to generate these very consistent builds that have a good security posture and they’re within compliance for us. So really what I’m trying to say here is eliminate the special snowflakes. Don’t allow them to happen. If somebody wants to have a special snowflake system, there should be a really, really good reason for it and it should go really high up in your organization for approval. The default answer should be no special snowflakes. We’re all going to use the same templates, the same security and the same orchestration because we know it works and it’s easier for us to support and it gives us much better security.