So our last three topics for documentation are going to be our asset management, our baselines and our change management.
Now our asset management refers to the physical accountability and the physical recording of where certain devices are. If we have an environment, especially an enterprise level environment, the larger our environment gets, the more we
have the need for some sort of asset management officer or asset management program to be put in place.
If we're just a small shot, maybe a an office of 10 or 10 or 15 people with our devices and our laptops and everyone knows who each laptop was assigned to, and everyone knows who has what then it's not as much of a concern. We still wanna have some sort of record and database for when, for who takes out what.
But it may just be a
spreadsheet that someone that one person keeps track of. Then that person is accountable for making sure that things are distributed properly. But for a large enterprise environment, we may need things like device serial numbers, and we may need people to actually sign four devices when they receive them. We may need a larger database to track devices and track where devices go.
We need to keep it some sort of secure database
for the log in information for certain devices, such as our switches on our routers and local log in information for computers,
we need to make sure that our devices say they physically secure and locked down, as well as making sure they stay up to date. And we need to track our warranties on the devices and track our service, our service agreements on devices to make sure that if something breaks that will be able to get it fixed under warranty.
So these are all aspects of our asset management and making sure that
appropriate person is responsible for a device and the appropriate person is held accountable if the device goes missing. So
we need to make sure that people can't just walk in and say, Hey, I need to borrow a computer cause I forgot mine at home today. Take that computer and take it home and give it to someone as a Christmas present. So we need to make sure that people are held responsible and that we track who has those devices because
things like a computer here and a computer there, especially in an enterprise level environment. Add up to several thousands, if not hundreds of thousands or millions of dollars, very quickly if they're not kept track of. And we don't manage who's held responsible for these devices and where they are.
Eso again device serial numbers, adding serial numbers and scan barcodes to devices and in putting those devices into databases is one of the components of that and making sure that we keep account of those devices. We keep a count of making sure those devices are secure and up to date, because we want to make sure that if those devices are
or if they were not kept secure, maybe the antivirus is not up to date. Maybe the device doesn't have the reason most wreak its recent security updates. Then we want to prevent those devices from being connected to are connected to our network and potentially harming our network.
Next we have our baselines. We've talked about baselines a couple of times being our reference point for things like our network data. Now our baselines are essentially a reference point of what's happening when our network,
or when certain computers or certain servers are functioning normally.
So we have our baselines and they act as our reference point that we keep track of if we need to compare abnormal traffic or abnormal performance to those bass lines. So it's very important that we do periodic baselines because if we did a baseline back in 2001 and then we
have some abnormal traffic in 2014 chances are there's been a lot of changes as to what is normal traffic from 2001 to 2014. So we need to make sure that we have. We have
documented and standardized cycles for when we run our baselines. Maybe maybe we run a network baseline once a month. Maybe maybe we run a network baseline where we capture all of our network traffic for two hours, and we do that once a month and then maybe once a year we run our network baseline for entire workday,
and then we run a network baseline for an entire non work day,
and we do that once a year so that we can compare abnormal traffic over an entire day to those bass lines if we need to, we need to have some sort of management cycle. We need to have some sort of documentation, letting us know when we run those baselines and letting us know where we keep those bass lines if we need to refer to them.
So we want to again check things such as run baselines over things such as our network through, Put our network traffic, what type of data we're sending, how much data we've sent and received. And we can create these baselines with network captures such as our wire shark. Or we can use
our performance monitor in order to capture
certain certain rules and capture certain data sets.
We talked. We talked a little bit about performance. Modern monitor Back in back In our different video, Siri's ate a plus. The +802 module and performance monitor monitor is essentially a very, very strong Ah, very robust Windows Mon Windows monitoring tool
that allows us to capture a lot of different data, sets in a lot of different type of data on our network
on our computers on our servers, and to make monitor that data and be ableto save captures of that data. We can then use that data later as a baseline and then compared against to it. It's our performance Monitor captures more than just network traffic. It can capture things such a server, performance, CPU performance, ram performance,
disc reads and writes
and thousands of other things. So it's a very strong tool. It's a very good tool to get good at. But again, it's one of those things that you really just need to practice. You need to you need to study on, and the more you play with it, the better you are because you have more hands on experience with it.
And lastly, we have our change management. Now. Our change management essentially, is how we handle changes in our environment. If we want to implement a new type of networked apology if we want to change out our wiring infrastructure, if we want to do something as simple as upgrading all the keyboards in a certain room,
then we need to have some sort of process in some sort of approval cycle
and some sort of test and implementation cycle on how we do this. We don't want to just say I have a system administrator say,
Yeah, I think I think our networks getting kind of slow. I think we should update all the wiring and update all the update, all the update, all the switches. And then they go to the manager and the manager says he's sure from the green light it and they buy all the equipment and they start putting it in and they say, Oh, this equipment's not gonna work in our network
And we don't have a return policy on our $200,000 worth of equipment that we just bought
we need to make sure that we have some sort of change management cycle of change man management documentation on our approval cycle where we say we have several systems administrators which collectively agree that our network has been slow or if it's a smaller network. We have our systems. Administrators say
Yes, our network has been slow and they performed some analysis and perform some tests and research and say
this and this and this would help to speed up our network. But let's say but we're gonna order these in precedents of this is the most important. This would make the biggest impact. And then this and then this and then this. And we're gonna and we're gonna write down how much each of these would cost, but also the pros and cons of implementing this and how long I think it would take.
They then take that to their manager, who reviews it and then approves it or denies it
or request certain changes. And then it moves on to budget approval on budget budget analysis. So there needs to be several steps. There need to be several people who review the documentation and review on the review, the research and then either give it a yes or no or yes on this know on this type thing, and then
eventually after goes through those different cycles.
Then it's approved, and the larger the change is going to be, the Maur impact is going to have, and the bigger the organization is where we're going to impact the changes, the more approval that needs to go through. Yes, it makes their makes it a lot of red tape, but it also makes sure that
there's not. The hammer doesn't just come down on this on one single person or We don't just have this. Mistakes can happen, but it's less likely to happen if we have more people reviewing and approving this document. This change management documentation
on and then we also have our test implementation cycle. Or maybe we don't buy all $200,000 worth of equipment. Maybe we approve
$1000 worth of test equipment and to implement that in a small section of our network and see if it works. And if it doesn't, we roll it back and we may try something else. Better to spend $5000 on test implementation and then have to spend $205,000 total
rather than spend $200,000 straightaway
and then find out that none of it's gonna work at all. So we need to make sure that we have that test implementation, and they were very sure about what we're doing, especially the more money we spend more sure we need to be before we implement something
and then we have documentation and accountability are changed. Management goes beyond simply making sure that we have an approval process for implementing changes in our network. We also need to make sure that we have changed management and approval process is for doing things, even a simple as updating computers. If we
I have several different Windows updates or several different application updates
which need to be which need to be implemented on computers, we need to make sure that even those go through a test cycle before their implements it on our network. If we have a an update from Microsoft, which fixes a bug in a certain a certain script on Microsoft Word. But then that fix
our users can no longer access their network shares. Then we may want to just go with Small Bug and Microsoft Word versus making shirt over people not being able to access their network shares. So we need to make sure that there is reviewable and there's, ah test process for
something as simple as updates to applications and updates to our computer software and our computer operating systems
that we have test cycles where we go through and we test these operating system updates and we test these application updates before they're pushed out to the enterprise environment and especially if we have a large enterprise in large enterprise company with several different network aspects in several different components and
hundreds, if not thousands, of computers.
We may even have a dedicated team that just performs change management and just monitors these updates and watches for all of these updates on their updates cycle and test them before we decide to release or to not release them to our computers. So
keeping track of our change management helps with accountability. But it also helps from our network going down from a bad update that we didn't test. So it's very important that we keep track of that change management. We document it, and we know who's responsible for what.
So we talked about our asset management with our actual physical devices, making sure that we keep track of them and we keep. We keep accountability for who has what we talked about setting up our base lines and having a reference point for normal computer and network activity that we can compare other captures to to check for abnormalities.
And we talked about our change management on how we're gonna handle changes in our environment
either large scale or even something just a simple is someone wanting a new computer.
So just, um or documentation. We want to keep in mind more things that we want to make sure that we have people responsible for writing down and keeping track of.
So thank you for joining us here today on cyber ery today we talked about a lot of the different types of documentation that we may have for our network and why they're important and what what we do with each of those documentations and what we keep track of. We talked about everything from our wiring schemes and are networked apology or physical and logical layout
to our change management in our asset management, even
what essentially, what we keep track of and how we keep track of our physical objects and how we keep track of getting people new things or implementing new changes into our environment. So make sure that even though it's one of the less desirable aspects of network management, it is
probably one of the more important aspects of a network management because the better that we have our network documents of, the better that we have, our changes documented and how everything is laid out, the easier it is for us to manage our network and to do troubleshooting and tow long into our switches. So make sure you keep your network documentation updated. Make sure that you keep
your network documentation
detailed and available, so that anyone who made anyone who needs to know it can reference it and can easily understand it. And most of all, come back here next time so that we can see here and you can watch our next video here on cyber.