An IT professional has to be ready for anything. In this video, you’ll learn about change management, security incidents, disaster recovery plans, system life cycles, and more.
They say that the only constant is change, and that is certainly true in information technology. There will be constant changes occurring in your network. You may need to upgrade software on a workstation, on a firewall, on a switch. You may need to make changes to a firewall configuration. Or you may need to modify or add different configurations to a router or switch.
Of course, the concern we have when making any type of change is that we could be affecting the uptime and availability for that device or other devices that might be on the network. This is a significant concern for information technology, because making a single modification in one place can have a dramatic impact on other components. The need to make these changes is something that occurs all the time in IT, and we want to be sure that our implementation of these changes will not cause any problems elsewhere.
Because of that, organizations tend to have a very formal change management process. This starts with setting policies that will determine how often changes are made, the duration or time frame in which these changes can be made, the process to perform the actual installation or change on the network, and then, of course, some procedures to fall back if those changes don’t happen to work properly.
Organizations that don’t have a formal change control process tend to do things very chaotically, and very often without any type of planning. Trying to implement a change control process where one doesn’t already exist can be challenging, but it will result in a much more stable and much more managed rollout of these changes.
Another set of important plans and procedures you should have in your organization is what to do in the case of a security incident. There can be many different kinds of security incidents. For example, you might have a user clicking an attachment inside of an email– it executes malware and becomes embedded into that person’s workstation. That malware then communicates to other external servers, and information that you had inside of your private network now could be made available to the public.
Another security incident might be a distributed denial of service attack, which could cause outages or downtime for your systems. Or you might be a victim of extortion. There could be confidential information that’s stolen by the hackers, and they want some money or they’re going to make that information public. Or this could be a simple misconfiguration, where a user might install peer-to-peer software, which would allow someone from the outside to access that internal system.
If you’re interested in getting an overview of how to handle these security incidents, you can refer to the National Institute of Standards and Technology document SP800-61 Revision 2. This is the Computer Security Incident Handling Guide. Inside of this handling guide, you can read about the incident response lifecycle, including the preparation for these security incidents, how to detect and analyze these incidents, how to contain, eradicate, and recover, and finally, the post-incident activity. Of course every organization has their own way of handling these security incidents, but this might give you an overview of where you might start.
Another concern we have is the unavailability of our systems because of some type of disaster. It’s very common for organizations to have a disaster recovery plan so that the information technology team will know what to do if a disaster occurs. One of the challenges when putting together a disaster recovery plan is there can be many different types of disasters.
These could be natural disasters, such as a flood or a tornado. It could be a technology or a system failure, and you need to recover that system as quickly as possible. Or this might be a human created disaster, where someone accidentally hits a water line, and now you have to deal with flooding in the data center.
Disaster recovery plans tend to be very comprehensive and very detailed and cover many different types of situations. These will usually include a recovery location, especially if you’re building or facility is no longer available. There may be a data recovery method, especially if you keep data off-site, or in a way that can be easily restored. There may be application restoration concerns. And of course, you need to make sure you have IT staff and employees so that you have some way to recover those systems and applications.
Sometimes when disaster occurs, there’s a delay before the recovery process can begin. In those situations, you need some type of alternative plan so you can keep the business up and running. We refer to this as continuity of operations planning. Or COOP. That’s because even though we commonly rely on our computer systems to be able to provide us with these applications, there may be a non-technical way to be able to perform the same functions.
For example, you may be able to write down manual transactions instead of typing them into a computer. You may be able to provide paper receipts instead of printing something out on a laser printer. Or instead of processing your credit card transactions automatically, you can call each transaction in and process them manually. This is obviously a set of processes and procedures that needs to be documented and tested prior to a disaster occurring. That way, we know, if we happen to have a disaster, we can immediately go to our documentation and know what we can do to keep everything running.
Another important concern with process and procedure is what we do with the equipment that we’re no longer using. This is part of the system lifecycle, so we need to know how to dispose of assets such as desktops, laptops, tablets, mobile devices, and anything else that may contain company data. This might also be a legal issue. In some organizations, certain types of data legally cannot be destroyed. So you need to make sure that you’re destroying data that would no longer be needed, but you’re keeping all of the data that you’ve been mandated to protect.
An important key with this is making sure that all of the data that you have internally is not being made available to others. And it’s very easy for someone to rummage through the trash, find a hard drive, and suddenly have access to data that you had no intention of making available to the public.
As you can see, there are many different concerns across many different parts of the organization when it comes to protecting data. We need to have some way to document and maintain what the standard operating procedures might be for your organization.
Most organizations will maintain either an online or offline version of a standard operating procedure manual so that what to do if a device fails or you have some downtime. The standard operating procedures might also give you information on what to do when a facilities issue occurs so you know exactly who to contact to resolve that issue.
These SOPs might also document your process for change control. So when you’re performing a software upgrade, or you need to perform testing, all of this information will be clearly documented in your standard operating procedures. The common thread is that all of these have been documented and everyone knows where to go to review and understand exactly what these policies might be.
We often find ourselves working with third party organizations to provide services for our company. In those situations, you need some type of agreement so that everyone knows exactly what level of service is expected. One way to provide that agreement is through the use of an SLA, or service level agreement. This is an agreement that documents the minimum terms to provide these services or products. Usually, this may include an uptime requirement, a response time agreement, and it’s commonly used between a customer and a service provider so that everyone knows what the expectation is when that service is provided.
Most service level agreements are formal documents that are signed, but if you need an agreement that doesn’t have quite that level of urgency, you may want to use a memorandum of understanding, or an MOU. Both parties to this agreement would come to terms on what this memorandum of understanding would include, and it usually would also have statements of confidentiality. This is often an informal letter of intent, and it might lead to a service level agreement, but by itself, an MOU is usually not a signed contract.
If you ever had a meeting with a third party that had private information or something that was company-confidential, they may have asked you to sign an NDA. The NDA is a non-disclosure agreement. It’s an agreement between parties that this information will stay confidential, and there will be penalties if that information was provided to a third party. This is commonly used to protect private business activities, trade secrets, or anything else that might be specifically listed in the non-disclosure agreement.
Some of these agreements are unilateral, where only one side needs to maintain the confidentiality, but in many cases, the NDA is bilateral, or in some cases, multilateral, so that everyone involved with the conversation is not able to speak of anything mentioned in the meeting. These are almost always signed contracts that include very specific details as part of the NDA.