hi and welcome to module to lessen 4.3.
In this lesson, we're gonna talk about configuration management.
We're gonna cover standard images, software repositories C. I s scanning and change management.
We'll start with standard images.
The standard image is just a baseline image of a piece of software, specifically an operating system. So let's say you have Windows 10 on 3000 workstations in your environment. Standard images going to just give you the ability. Teoh. Install Windows 10 on a single system.
Put all of the applications on Windows 10 that your organization needs.
Run vulnerability scans against it, install all of the necessary patches and create a fully hardened, fully vetted system. Once you've done that, you can capture an image of it in the virtual world. It could just be a snapshot in the hardware world. Use their software you can use to capture an image of that and save it centrally.
And you can create baseline images for not just for operating systems, but even within your organization. Maybe the marketing department has a different set of applications running on their operating system than the engineering department does. You could have a marketing baseline image or standard image and in engineering, standard image,
another name for standard images. Sometimes we call it the Golden Image.
But essentially what a standard image does. It's just gonna give you the ability to have a one known good image that you can use to deploy toe assets in your environment. Instead of rebuilding, say, windows, every time you you get a new employee having to go through the whole process of installing windows every time from scratch,
a good practice with standard images. Once you've got this image, once you've gone through all the trouble of putting together this really nice, hardened, vetted image, minimize the number of copies that you use. It's sometimes it's easy to distribute copies on flash drives to technicians who are gonna be actually doing installations throughout the environment.
But every time you put a copy of that on a flash drive and handed out,
that's another copy that's out there. That may not get updated whenever you update the golden image for for the workstation andan. Now what you've got is you've got this. I've seen it just exponentially propagate where you've got these. These
standard images on these USB drives all over the place, and they're all different versions, and some of them haven't been patched and forever,
Um, so it's going to minimize the copies as much as possible.
You can do that by using network deployment for standard images. You can use things like pixie boot, for example, to if you create a standard image, you can save it in a centralized location. And then when systems boot up, you can. You can hit some function keys and have them boot from network, and then you can point
to the network location where your golden image is,
and they could pull down the image and install from there. So instead of having these images on USB sticks all over the place now, you've got one centralized image that you can control, and anything in the environment, as long as it's connected to the network, can go out and grab it and install it, and you know it's always going to get the latest and greatest image. You're not gonna have
stale images out there scattered all over the place,
just like with the patches. When we talk about patch management in the last lesson, there's no different here. So you want a patch that standard image regularly, Just like you patch everything else in the environment.
Ah, good rule of thumb is every time you go through, If you're gonna patch monthly in your environment, all of the systems in your environment just include the standard image in that system.
In that patching have that standard image loaded on a system. Run all the patches against it and then save it again and then replace your standard image with this new standard image. In that way, you've always got an up to date, fully patched standard image or golden image.
Now, something very closely related to a standard images, a software repository and all that software repository is is a centralized location where you keep software that you use in your environment. Let's say you use Adobe Flash and you use Microsoft Word and you use auto cad. Whatever those software packages are that you use in your environment,
a software repository is a mechanism for just
grabbing all of those software images from wherever from all of different vendors and keeping in one centralized location. Theo idea, behind a software repository, is even if you allow your in users, for example, to go out and install their own or update their own software. Install their own, say auto cad because they have a license for it.
Instead of letting them point directly to the auto CAD site,
you should have them point to an internal software repository. So as an I T administrator, you go out and you get the piece of software and you keep it in a centralized location. And then your users or your technicians can install software from that location. And that ensures that the in users or technicians aren't just going out to
any website that confined where they can download a copy of that software
and installing that there's a lot of Mao out there masquerading around as legitimate software
to suffer depository to keep it in a central location, you want to put access controls around it. If if you don't allow people to install self were on their own, then you should lock it down and, you know, have read only access only from your technicians are I'm sorry, read. Write access only from your technicians.
If you do have your in users that you want to allow them to install their own software.
You can still maintain that software. Make sure it's up to date in the repository. Give them read access to it. But Onley leave right access to those handful of individuals who you want to actually update those software images. So only a trusted few are allowed to actually replace that centralized trusted, that trusted piece of software that
that gets rolled out to the rest of the company.
If you use an agent on the endpoint to deploy software like a McAfee e p. O, you know, has been used for a while or whatever that agent is. If using an agent on the endpoint to deploy software, you can point that agent to the software repository instead of having it go out and grab stuff off the Internet directly.
And just like the regular the golden image. You're gonna want to patch this, not patch, but you wanna update this regularly. You don't wanna have a piece of software. The software repository that's eight revisions behind because it's naturally going to be full of vulnerabilities. You wanna have the latest and greatest, or at least something close to the latest and greatest software
in that software repository. So as it gets deployed, it's It's the latest and greatest
gonna switch gears a little bit to C. I s benchmarks and CS stands for the Internet for Center for Internet Security.
Essentially, C I s We talked about this a little bit in the beginning on less and want our model one when we talked about vulnerabilities with a vulnerability scanner, you can have a scanner scan the environment for vulnerabilities, but it can also scan for configuration vulnerabilities.
C. I s is an organization that puts together a list of best practices these air different for different pieces of software. So for Windows here, the things you should do for best practices this forest configuration of the software itself for Apache, for UNIX, for all of the different packages they have these benchmarks that serve as best practices
your most vulnerability. Scanners can scan not only for vulnerabilities, but they can scan for these configuration vulnerabilities as well. These Miss configurations, you can scan for that and you get a report that looks similar to this. That shows you all of the different things that are configured on that system that could be configured differently. Toe lower the vulnerability and lower the risk to the organization.
So as you're doing your vulnerability scanning as part of your vulnerability and patch management program, you should include CS benchmarks and see a scanning to make sure that your applications that your your software on your endpoints is configured properly.
The last topic here in this section is gonna be changed. Management now change. Management is simply just We talked a little bit about how changes to the software repository or changes to the golden image in this section. We're talking specifically about changes to the production environment or changes changes to the systems in your environment.
It's very important to have a good change management process in place of a good program in place.
And the reason it relates to security is because in in in the security world, a lot of detecting malicious things in the environment relies on being able to identify normal.
So if we create good change process and we know what normal changes look like in an environment, we can anticipate changes in predict changes.
We know what changes were happening and happening in the environment.
If we say something outside of that window or outside of that baseline. We can flag it a suspicious, and that would start pulling on the thread and the security world. There's a lot of noise, so any time we can reduce the noise, we always want to do that. Change management process gives us an opportunity to do that because
we we can. If we If we understand what those changes look like, we can look for anything outside of it as suspicious.
But some concepts in the change management world A lot of organizations have different environments. Some organizations have a development. You 80 in a production environment. You A T stands for user access, user access, testing,
development, development environment would be where people can just tinker. Engineers can tinker. They want to try something. They're not quite sure what effect. It's gonna have one impact it's gonna have. But the best way to figure it out is to just try it. There's this environment that they can play with, and a lot of times there's no change. Management control in that environment is just a place to tinker.
Then there's you 80 which is user access testing or sometimes called pre prod, and that's an environment that mimics production. It looks like you're a production environment, and once you're finished tinkering in the development environment, when you think it's ready for production in the first place you go is you 80 or pre prod
and putting your changes into that environment. We'll tell you if there's any issues
with that change in an environment that has the same configuration is production. Maybe there was something you didn't see Endeavour that you're going to see him in pre prod and you can catch it before it comes a problem in production. And then once you've worked out all the bugs in that environment, then you would install it into the production environment.
So a lot of organizations split it up this way just to to limit the number of outages that occur in the environment. And they go through this this process of changes.
But lately that's all being collapsed into one what they call Dev ops environment. And that's basically where just the development and the operations is kind of. The lines are being blurred. The idea is to be able to develop and release faster and faster. Some organizations have maybe a software product that they need to
release new new versions all the time to stay competitive,
and it's important that you can. You can do it quickly. And if you have these three different environments, you have to go through all three of these. It takes a little bit longer so that this process of DEV ops has been created
where it's blurring the lines between that. But you can still have changed management processes in a dev ops environment. You can still have process that regulates what changes can be made during the development phase and how things get pushed into production and how they how they actually get committed or code gets committed and things of that nature.
It's important for any change management program to have a dedicated change management team. So a group of people who are made up of diverse backgrounds or, in other words, they're they're from different parts of the organization, and they all understand, as as a collective, how a change in this order in this part of the organization's gonna impact something over here.
A Z engineers. A lot of times we get, you know, down into the weeds, and we're working on our one little piece of the pie,
and we may have a perfect solution. But But what we don't see is that when we make this change, there's a chain of events that happens that impacts this other business function over here. So as the change management process as you're creating the process, it's important to have a team of people with representation from different areas of in the organization
so that we can understand the full impact of a change. And this team of people could be in responsible for approving
and finally the change. You should have a good change management process itself. You know, that could be there's a lot of different things that could be you could have peer review process is in place. So if it's a code shop, you can say you have to have at least one peer reviewer that looks at that code or even a network engineering shop. One
one peer of you're that another network engineer that looks at that change you're gonna make to that router to make sure it doesn't cause an impact
so you can have those types of things you can even have things around time Windows and how you handle the change itself. You know, change Management and Change management team should be responsible for scheduling the changes to make sure that there aren't two or three changes going on
at the same time in the environment where one of them is in a big deal. Maybe there's a change on the production system, but if there's a change on the backup system at the same time, well, now you have an outage because you're working on both systems. So the change management team should be responsible for scheduling. Knows to make sure that the overlap doesn't cause issues.
Ah, and then maybe there's some sort of time frame as well you want to put in place. If there's a change window,
you're supposed to get a change done in an hour. Let's say and you're 45 minutes into the window and you've run into issues and you're struggling to get it. There should be some period there where there's a that's it. That's if you hit this number and you're not done. You have to back the change out and you have to start it over again. because you're gonna you run the risk of running into a
another change where you could impact something else.
So there was a lot of different things you can do with process the ideas toe, have some process, and to make sure everyone understands what that process is, especially in the security world, so that the security analyst can understand what types of changes to expect as normal in the environment.
Okay, that's it for our this session that next up, we're gonna talk about going to switch gears. We're gonna move away from the endpoint layer, and we're going to start talking about the application layer and lesson to 0.5.