Hello, everyone. My name is Peter Simple own, and this is the network security course.
This is going to be module five. Lesson to
prerequisites for this course are modules one through four and the first lesson from module five.
In this lesson, we will learn
policies, guidelines and baselines and how they enforce security practices,
change management and patch management, which maintained the integrity of the network and restrict any unauthorized changes to the network. And also take a quick look at the network development lifecycle on how networks are truly a living being thing.
Security practices are upheld through the creation, implementation and maintaining of policy standards, procedures, guidelines and baselines.
Let's take a look them a little more detail. So policy is simply a high level document that outlines senior management security directives. This is the document that people fall when they want to implement a certain change, restriction or a certain way of doing things.
Standards are compulsory rules that support the security policies. Thes rules are kind of like the industry. Best ideas are best practices for performing a specific task, So the NIT NIST has a bunch of standards for cyber security
procedures are simply a step by step instructions for performing a certain task on guidelines. These air suggestions and best practices guidelines kind of help people make decisions about organizations and networks. Now, obviously, every network is going to be different.
But with even we using guidelines, you can still kind of generally make it safe and secure.
And finally, baselines, a type of standard that specifies the minimum set off security controls. Baselines are good for
maintaining the integrity of the network. So when you have a network you want to get a baseline, you want to check the performance, you want to check the security, and you know that's like That's your first baseline and then every other network check up. After that, you can compare it to the baseline
and see if anything has changed. If anything needs to change
policy formats are laid out like this. We start out with the objective, which is simply a statement saying what the policies job is. Then we have the policy statement. This is kind of a statement made by upper management detailing what they expect from this policy.
You have applicability, which states who the policy is for who should follow the policy and who should not follow the policy. The next section is enforcement. The enforcement section determines how the policy is going to be enforced. And what are the penalties for non enforcement
roles and responsibilities? These are document who will be in charge of what in the policy suffers a specific task in the policy that needs to be done. The person who was supposed to be doing that will be listed here. Then there is the review section.
This section states when the policy will be reviewed again in case it needs to be updated
or changed, or anything like that.
There is a procedure for the procedure and the procedure. Further procedure Looks like this. See, remember, a procedure is simply a step by step instruction off a certain task. So the first is the purpose. Why? Why are we creating a procedure for this?
The second step is the applicability who this procedure applies to, and finally you have a combination of steps, figures and decision points. Procedures should be laid out in such a way that a nontechnical person can follow the procedure by themselves
and still be able to complete the task.
So you do this by labeling everything step by step, having pictures, figures, diagrams, spelling everything out and breaking it down into very understandable, readable, simple concepts. And you can also have flow charts and certain decision points if an option or a decision needs to be made.
Change management change management is the process involved in making changes to the network using this process, insurers that there are no unnecessary side effects to the changes made. There is no lack of communication when changes are being made,
and this also restricts the number of changes and the amount of changes that can be made
to a network. So the first step and change management is to request submission. So this is where you make a request for change.
And this is kind of where you make a suggestion like, Hey, we should make this change here right from there, it goes to a recording step. The entire change that needs to be made needs to be documented for future and tracking purposes. And then, from there you go down to impact assessment.
You document what kind of impact this change will have on the network, so you can use statistics from the networks such as performance. Who's giving attitude in that working you certain statistics to determine what kind of positive or negative impact this will have.
And then finally you have the decision making. This is where it becomes a simple yes or no whether or not the change will be implemented.
And assuming that the change is implemented and gets approval,
he gets to approval to the upper management, and then the change is implemented. From there, you have the status tracking. From there, you can use your statistics from the network, and you can monitor the network to see if the change you've made has theatrical desired outcome or not.
And you can also compare the change
to your baseline of your network to see if anything has been different.
Patch Management is also processed to maintaining the integrity off the system, and it's important to make sure you have a proper plan in place when patching or updating your systems, because there are plenty of things that could go wrong. The first step is the acquisition.
This is where you get the patch or the update that you need to apply to your system or to your network,
you can Usually, if it's for a system you can usually get the update, line or light come and just might be delivered in a special way. But either way, you have to get the patch first and then you have to test the patch. You test it in like a testing environment, so you test it out on
maybe like a testing network or system
to make sure that it has the defect you're looking for. And then from there
you wait to see if the patch gets approved. If the patch gets approved, then you can go ahead and prepare that patch to be deployed to all of the target and production systems,
and then you go to deployment. This is where you actually apply the patch to your production systems. But also, this is where you want your users know that. Hey, this website might be down for a while or there might be some changes happening just so they are aware in case something happens
when they can't log on. Afterwards you go to the verification stage and this is where you ensure that the patch that you applied has the effect. You're welcome for
the network development. Lifecycle networks are, in essence, a truly living, breathing thing. They're constantly being updated, changed. Things were moving around, and it's very important to maintain the in health and integrity of your network. So to do this,
you know, sometimes you have to have a life cycle when it comes to
implementing changes and monitoring those changes and making existing changes to a network. So the first step is the analysis that this is where you check out your performance and your management statistics, and then, from there, you can kind of figure out what are not. A change needs to be made to the network.
If it does, you can design the change
from there. You want to prototype this change just to make sure that the change that you made will not have any unnecessary consequences to your network
from there. If everything is well, you can implement
that change in your network, and then you can do the maintenance, and you can maintain it by collecting mawr of the network performance and monitoring statistics. From there, you can analyze them again, and the cycle continues
In today's video, we discussed aspects of documentation
change and patch management and the network development Life Cycle.
A suggestions and best practices?
Be compulsory rules that support the security policies.
See step by step instructions for performing a task or D high level document that outlines senior management security directives.
If you said be composer rules that support the security policies, then you are correct. I hope you guys learned a lot in this lesson, and I'll see next time.