Companies need to manage risk, to minimize the dangers posed by internal and external threats. The chapter tackles risk management first. Companies also need policies for expected dangers and procedures for things that will happen eventually. This is contingency planning. Let’s get started.

Test Specific

Risk Management

IT risk management is the process of how organizations deal with the bad things (let’s call them attacks) that take place on their networks. The entire field of IT security is based on the premise that somewhere, at some time, something will attack some part of your network. The attack may take as many forms as your paranoia allows: intentional, unintentional, earthquake, accident, war, meteor impact…whatever.

What do we do about all these attacks? You can’t afford to build up a defense for every possible attack—nor should you need to, for a number of reasons. First, different attacks have different probabilities of taking place. The probability of a meteor taking out your server room is very low. There is, however, a pretty good chance that some clueless user will eventually load malware on their company-issued laptop. Second, different attacks/potential problems have different impacts. If a meteor hits your server room, you’re going to have a big, expensive problem. If a user forgets his password, it’s not a big deal and is easily dealt with.

The CompTIA Network+ certification covers a number of issues that roughly fit under the idea of risk management. Let’s run through each of these individually.

Hardening and Security Policies

A security policy is a written document that defines how an organization will protect its IT infrastructure. There are hundreds of different security policies, but for the scope of the CompTIA Network+ certification exam we need to identify only a few of the most common policies. These policies include internal and external ones that affect just about every organization. This section covers the following policies:

•   Acceptable use policies

•   Network access policies

•   Mobile deployment models

•   Onboarding and offboarding policies

•   Externally imposed policies

Acceptable Use Policies

An acceptable use policy (AUP) defines what is and what is not acceptable to do on an organization’s computing devices. It’s arguably the most famous type of security policy because it is the one document that pretty much everyone who works for any organization is required to read and, in many cases, sign before they can start work. The following are some provisions contained in a typical acceptable use policy:

•   Ownership  Equipment and any proprietary information stored on the organization’s computers are the property of the organization.

•   Network access  Users will access only information they are authorized to access.

•   Privacy/consent to monitoring  Anything users do on the organization’s computers is not private. The organization will monitor what is being done on computers at any time.

•   Illegal use  No one may use an organization’s computers for anything that breaks a law. (This is usually broken down into many subheadings, such as introducing malware, hacking, scanning, spamming, and so forth.)

Network Access Policies

Companies need a policy that defines who can do what on the company’s network. The network access policy defines who may access the network, how they may access the network, and what they can access. Network access policies may be embedded into policies such as VPN policy, password policy, encryption policy, and many others, but they need to be in place.

A common security concept that informs or guides many network access policies is the principle of least privilege, the idea that users should only have access to network resources required to do their job and nothing more. Managing permissions for every user individually is an endless chore, especially in large organizations, so it’s better to do it by role.

Sales representatives need access to the customer database to do their jobs, but they definitely do not need access to the accounting database. Instead of adding access to the customer database for every sales representative’s account, a role-based access approach would establish a sales-representative role, associate each representative’s account with the role, and assign all of the necessary privileges to the role.

Let’s now look at a few network access policies specifically or indirectly covered on the CompTIA Network+ exam objectives.

•   Password policy  Password policies revolve around strength of password and rotation frequency (how often users have to change their passwords, password reuse, and so on.) See “Training” later in this chapter for more information on best practices, but keep in mind that some organizations will go far beyond those recommendations.

•   Data loss prevention policy  Data loss prevention (DLP) can mean a lot of things, from redundant hardware and backups, to access levels to data. A DLP policy takes into consideration many of these factors and helps minimize the risk of loss or theft of essential company data.

•   Remote access policy  A remote access policy (such as a VPN policy) enforces rules on how, when, and from what devices users can access company resources from remote locations. A typical restriction might be to not allow access from an open wireless portal, for example.

Policies reinforce an organization’s IT security. Policies help define what equipment is used, how data is organized, and what actions people take to ensure the security of an organization. Policies tell an organization how to handle almost any situation that might arise (such as disaster recovery, covered later in this chapter).

Mobile Deployment Models

A long, long time ago, organizations had near total control over the devices on their networks by default. The hardware was huge, heavy, stationary, and often all had to come from a single vendor for compatibility—if your job required one, you used whatever the company bought. Organizations like having all of that control, but it doesn’t come easy in a world where mobile and portable devices far outnumber stationary computers.

Organizations want to keep their networks and data secure, but it isn’t as easy as purchasing the same device for everyone anymore. Users have strong opinions about their devices. Some will want to keep their work and personal use on separate devices, and others will refuse to carry two devices everywhere they go. Some will use any device they’re given, and others will be frustrated if they have to learn to use Linux or macOS when they prefer Windows—or an Android device when they’d prefer an iPhone.

Each organization has to find its own way to balance what it wants with what its staff wants—but deployment models give us a shorthand for describing the main ways organizations approach the problem. This section explores four models: BYOD, COBO, COPE, and CYOD.

BYOD  A bring your own device (BYOD) deployment lets employees use their existing portable devices at work. Employees get devices they prefer, which can increase employee happiness and productivity. The organization saves money on hardware, but the extra device variety comes with its own challenges. Many BYOD challenges revolve around security, support, and privacy.

Users might unwittingly bring in devices that are already compromised, putting the security of other devices—not to mention the organization’s data—at risk. Someone could steal important company information if the user takes their device to a shady repair shop. A user might ask the support staff for help accessing a critical application from a brand new device that runs an unfamiliar OS, frustrating everyone involved. Finally, users expect more privacy on their own devices: monitoring software that is acceptable on a device the company owns may violate user privacy if installed on their personal phone.

How does the organization navigate these challenges? Generally, it’ll compile a BYOD policy—a document each user who wants to bring their own device must agree to—that spells out details such as:

•   Which devices are eligible. These may be general types of device, a more specific list of required features, or a very specific list of allowed models.

•   What steps must be taken to prepare and secure a device before it can join the network. For example, it may need to be registered, pass a scan for malware or otherwise banned applications, and have monitoring or security software installed.

•   To what extent the organization will provide technical or financial support for the device or associated data service.

•   Notifying the user of any ongoing obligations they have, such as notifying the organization if the device is lost, stolen, or shows signs of malware.

•   Notifying the user of any legal risks they are accepting or rights they are giving up. For example, that their device may be confiscated as evidence in the event of a lawsuit, or that the organization may wipe the device (including user data) if the device is believed lost or the user leaves the organization.

COBO  In a corporate-owned, business only (COBO) deployment model, the corporation owns all the mobile devices and issues them to employees. The corporation is solely responsible for the maintenance of the devices, the applications, and the data.

COBO is very rigid—nothing but company-approved software is used on the issued mobile devices. This is often a challenge as it requires employees to carry both the corporate device and their own device.

COPE  Corporate-owned, personally enabled (COPE) is almost identical to COBO in that the organization issues mobile devices. With COPE, however, employees are presented with a whitelist of preapproved applications that they may install.

CYOD  An organization offering choose your own device (CYOD) options provides employees free choice within a catalog of mobile devices. The organization retains complete control and ownership over the mobile devices, although the employees can install their own apps on the mobile devices.

Onboarding and Offboarding Policies

Every time someone joins or leaves an organization, there is a lot of important work to do. When they join, they’ll need some combination of a workspace, keys, badges, hardware, accounts, and training. If they’re an employee, they’ll also need a process in place to make sure they get paid!

It doesn’t always happen this way, but it’s best for everyone involved if there’s a smooth onboarding procedure to ensure new members get everything they need to settle in efficiently—and a careful offboarding procedure to reverse these when they leave the organization. The first step to ensuring it works like this is a good onboarding and offboarding policy that lays out what should happen, when it should happen, and who is responsible for doing it.

This process may involve multiple departments, and the people doing the work can differ depending on the size and structure of the organization. If the processes are all manual, a Network+ tech might be closely involved in multiple steps; if it’s highly automated, an administrator may push a button and let the computers do the rest. Let’s take a look at one role that may involve you: enrolling devices with your organization’s mobile device management (MDM) system during onboarding, and removing them during offboarding.

Enrollment practices are also all over the map. The user might visit a URL to enroll their own device (especially in BYOD deployments), or an IT administrator might have to physically connect to a device to enroll it. The method tends to depend on both the device OS and the organization’s MDM—but the result is pretty much the same.

An enrolled device is registered with the MDM (which can configure devices, deploy applications, and enforce security policies) and associated with its user. Unenrolling a device entails scrubbing the organization’s data (and potentially software) from the device and either deactivating it within the MDM to await a new user or removing it from the MDM entirely.

Externally Imposed Policies

Government laws and regulations impose policies on organizations. International export controls, for example, restrict the export of some kinds of hardware and software—along with more obvious things like weapons—to specific countries. Laws such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA) regulate how an organization should store and secure specific types of data, who is allowed to access the data, whether employees can travel to other countries with devices containing the data, and more.

Most organizations devote resources to ensure they are in compliance with externally imposed policies. Just about every research university in the United States, for example, has export control officers who review all actions that risk violating federal laws and regulations. It’s a really huge subject that the CompTIA Network+ only lightly touches.

Adherence to Policies

Given the importance of policies, it’s also imperative for an organization to adhere to its policies strictly. This can often be a challenge. As technologies change, organizations must review and update policies to reflect those changes.

Try This!

Change Management

An IT infrastructure is an ever-changing thing. Applications are updated, operating systems change, server configurations adjust; change is a tricky part of managing an infrastructure. Change needs to happen, but not at the cost of losing security. The process of creating change in your infrastructure in an organized, controlled, safe way is called change management.

Change management usually begins with a change management team. This team, consisting of people from departments across your organization, is tasked with the job of investigating, testing, and authorizing all but the simplest changes to your network.

Changes tend to be initiated at two levels: strategic-level changes, typically initiated by management and major in scope (for example, we’re going to switch all the servers from Windows to Linux); and infrastructure-level changes, typically initiated by a department by making a request to the change management team. The CompTIA Security+ exam explores change management in more detail, so for now I’ll focus on the latter type of change, where you are the person who needs to understand enough about the process to propose a change to the change management team. Let’s go over what to expect when dealing with change management.

Initiating the Change

The first part of many change processes is a request from a part of the organization. Let’s say you’re in charge of IT network support for a massive art department. There are over 150 graphic artists, each manning a powerful macOS workstation. The artists have discovered a new graphics program that they claim will dramatically improve their ability to do what they do. After a quick read of the program’s features on its Web site, you’re also convinced that this a good idea. It’s now your job to make this happen.

To begin, create a change request. Depending on the organization, this can be a highly official document or, for a smaller organization, nothing more than a detailed e-mail message. Whatever the case, you need to document the reason for this change. A good change request will include the following:

•   Type of change  Software and hardware changes are obviously part of this category, but this could also encompass issues like backup methods, work hours, network access, workflow changes, and so forth.

•   Configuration procedures  What is it going to take to make this change happen? Who will help? How long will it take?

•   Rollback process  If this change in some way makes such a negative impact that going back to how things were before the change is needed, what will it take to roll back to the previous configuration?

•   Potential impact  How will this change impact the organization? Will it save time? Save money? Increase efficiency? Will it affect the perception of the organization?

•   Notification  What steps will be taken to notify the organization about this change?

Dealing with the Change Management Team

With your change request in hand, it’s time to get the change approved. In most organizations, change management teams meet at fixed intervals, so there’s usually a deadline for you to be ready at a certain time. From here, most organizations rely heavily on a well-written change request form to get the details. The approval process usually consists of considering the issues listed in the change request, but also management approval and funding.

Making the Change Happen

Once your change is approved, the real work starts. Equipment, software, tools, and so forth, must be purchased. Configuration teams need to be trained. The change committee must provide an adequate maintenance window: the time it will take to implement and thoroughly test the coming changes. As part of that process, the committee must authorize downtime for systems, departments, and so on. Your job is to notify people who will be affected by the change and provide alternative workplaces or equipment if possible.

Documenting the Change

The ongoing and last step of the change is change management documentation. All changes must be clearly documented, including but not limited to the following:

•   Network configurations, such as server settings, router configurations, and so on

•   Additions to the network, such as additional servers, switches, and so on

•   Physical location changes, such as moved workstations, relocated switches, and so on

Updating SOP

Organizations have standard operating procedures (SOP) that detail how to do most tasks within the organization. Any changes to procedures made during the change management process should be reflected in an updated SOP.

Patching and Updates

Best practices with patch and firmware management require both aggressive updates when manufacturers release patches and research to know when patches might cause problems. Patching and updating software and firmware is of critical importance in hardening networks. Bad actors know about system flaws and will attack the network through those unpatched gaps. (You’ll see a lot more about attacking systems in Chapter 19.)

When we talk about patching and updates, we aren’t just talking about the handy tools provided to us by Microsoft Windows or Ubuntu Linux. Almost every piece of software and firmware on almost every type of equipment you own is subject to patching and updating: printers, routers, wireless access points, desktops, programmable logic controllers (PLCs)…everything needs a patch or update now and then.

What Do We Update?

In general, specific types of updates routinely take place. Let’s cover each of these individually, starting with the easiest and most famous, operating system (OS) updates.

OS updates are easily the most common type of update. Individuals install automatic updates on their OSs with impunity, but when you’re updating a large number of systems, especially critical nodes like servers, it’s never a good idea to apply all OS updates without a little bit of due diligence beforehand. Most operating systems provide some method of network server–based patching, giving administrators the opportunity to test first and then distribute patches when they desire.

All systems use device drivers, and they are another part of the system we often need to patch. In general, we apply driver updates to fix an incompatibility, incorporate new features, or repair a bug. Since device drivers are only present in systems with full-blown operating systems, all OS-updating tools include device drivers in their updates. Many patches will include feature changes and updates, as well as security vulnerability patches.

All software of any complexity has flaws. New hardware can expose flaws in the software it interacts with; newer applications create unexpected interactions; security standards change over time. All of these factors mean that responsible companies patch their products after they release them. When a major vulnerability is discovered, vendors tend to respond quickly by creating a fix and distributing an update or patch. Updating devices to protect them against vulnerabilities is a best practice for hardening networks.

Lesser vulnerabilities get patched as part of a regular patch cycle. You may have noticed that on the second Tuesday or Wednesday of each month, Microsoft-based computers reboot. Since October of 2003, Microsoft has sent out patches that have been in development and are ready for deployment on the second Tuesday of the month. This has become known as Patch Tuesday. These patches are released for a wide variety of Microsoft products, including operating systems, productivity applications, utilities, and more.

Firmware updates enable programming upgrades that make network devices more efficient, more secure, and more robust. Manufacturers release patches to firmware that unlock new features and fix or refine current features. Updating firmware regularly is part of network hardening best practices. The process for firmware upgrades varies among the many devices, but often it’s a routine initiated via the browser-based interface or through a central management system.

How to Patch

In a network environment, patching is a routine but critical process. Here are a few important steps that take place in almost every scenario of a network patch environment:

•   Research  As a critical patch is announced, it’s important to do some research to verify that the patch is going to do what you need it to do and that people who have already installed the patch aren’t having problems.

•   Test  It’s always a good idea to test a patch on a test system when possible.

•   Configuration backups  Backing up configurations is critical, especially when backing up firmware. The process of backing up a configuration varies from platform to platform, but almost all PCs can back up their system setups, and switches and routers have well-known “backup-config” style commands.

A single system may have many patches over time. When necessary, you might find yourself having to roll back the update, returning to an earlier version. This is usually pretty easy on PCs because OSs track each update. With firmware, the best way to handle this is to track each upgrade and keep a separate copy of each version to make it easy to revert to a safe version (some devices may do this automatically).

Training

End users are probably the primary source of security problems for any organization. We must provide employee training so they know what to look for and how to act to avoid or reduce attacks. Training users is a critical piece of managing risk. While a formal course is preferred, it’s up to the IT department to do what it can to make sure users have an understanding of the following:

•   Security policies  Users need to read, understand, and, when necessary, sign all pertinent security policies.

•   Passwords  Make sure users understand best practices, especially when it comes to password complexity/length. Best practices according to the U.S. National Institute of Standards (NIST) include a minimum of eight characters for human-generated passwords. New passwords should be rejected if they appear in a database of previously breached passwords. Recent standards also reverse course on a lot of requirements people used to think were a good idea. For example, NIST now discourages expiring passwords and complexity requirements. A lot of online services require regular password changes and a certain password complexity, such as a combination of upper- and lowercase letters, numbers, and nonalphanumeric symbols; complexity can make passwords stronger, but NIST says the requirements only lead to formulaic passwords that are easier to crack.

•   Physical workplace and system security  Make sure users understand how to keep their workstations secure through screen locking and not storing written passwords in plain sight. Some organizations require their users to power down systems and clear documents off their desks at the end of the day. It’s also important to report suspicious behavior or missing keys and equipment, shred paper documents as soon as possible, verify the identity of visitors, and avoid leaving data storage devices sitting around. Users shouldn’t enable unauthorized access to secure areas by letting someone follow them in, leaving doors propped open, or leaving locks unlocked.

•   Social engineering  Users need to recognize typical social-engineering tactics and know how to counter them.

•   Malware  Teach users to recognize malware attacks and train them to deal with them.

Common Agreements

Dealing with third-party vendors is an ongoing part of any organization. When you are dealing with third parties, you must have some form of agreement that defines the relationship between you and the third party. This section explores five common agreements: a service-level agreement, a memorandum of understanding, a multi-source agreement, a statement of work, and a nondisclosure agreement.

Service-Level Agreement

A service-level agreement (SLA) is a document between a customer and a service provider that defines the scope, quality, and terms of the service to be provided. In CompTIA terminology, SLA requirements are a common part of business continuity and disaster recovery (both covered a little later in this chapter).

SLAs are common in IT, given the large number of services provided. Some of the more common SLAs in IT are provided by ISPs to customers. A typical SLA from an ISP defines the following:

•   Service provided  The minimum and/or maximum bandwidth and describes any recompense for degraded services or downtime.

•   Equipment  What equipment, if any, the ISP provides. It also specifies the type of connections to be provided.

•   Technical support  The level of technical support that will be given, such as phone support, Web support, and in-person support. This also defines costs for that support.

Memorandum of Understanding

A memorandum of understanding (MOU) is a document that defines an agreement between two parties in situations where a legal contract wouldn’t be appropriate. An MOU defines the duties the parties commit to perform for each other and a time frame for the MOU. An MOU is common between companies that have only occasional business relations with each other. For example, all of the hospitals in a city might generate an MOU to accept each other’s patients in case of a disaster such as a fire or tornado. This MOU would define costs, contacts, logistics, and so forth.

Multi-source Agreement

Manufacturers of various network hardware agree to a multi-source agreement (MSA), a document that details the interoperability of their components. For example, two companies might agree that their gigabit interface converters (GBICs) will work in Cisco and Juniper switches.

Statement of Work

A statement of work (SOW) is in essence a legal contract between a vendor and a customer. An SOW defines the services and products the vendor agrees to supply and the time frames in which to supply them. A typical SOW might be between an IT security company and a customer. An SOW tends to be a detailed document, clearly explaining what the vendor needs to do. Time frames must also be very detailed, with milestones through the completion of the work.

Nondisclosure Agreement

Any company with substantial intellectual property will require new employees—and occasionally even potential candidates—to sign a nondisclosure agreement (NDA). An NDA is a legal document that prohibits the signer from disclosing any company secrets learned as part of his or her job.

Security Preparedness

Managing risk effectively requires determined preparedness for incidents. If you decide to pursue the next logical CompTIA certification, CompTIA Security+, you’ll find an incredibly detailed discussion of how the IT security industry spends inordinate amounts of time and energy creating a secure IT environment. CompTIA Network+ requires you to understand security risk assessments and business risk assessments.

Security Risk Assessments

CompTIA uses the term security risk assessments to categorize some fundamental aspects of risk assessment, notably threat assessment, vulnerability assessment, penetration testing, and posture assessment. Each of these subcategories pokes around at potentially bad things that can happen to an organization’s assets. Anything of value to an organization is an asset. Organizations analyze potentially bad things to protect against them and to mitigate if or when bad things happen.

Threat Assessment  Threat describes the potential or capability of an event or bad actor to cause damage to company assets. A threat assessment, therefore, is the organization analyzing what’s out there.

Bayland Widgets Corporation (BWC), for example, has a factory for making widgets. The factory and all of its control systems are extremely important assets. The proprietary widgetXplus technology that makes BWC’s widgets the best in the world is also a key corporate asset. What are the threats?

A threat actor—a person, organization, or even a nation state that has both the capability and intent to harm, steal, copy, or otherwise diminish an asset—could infiltrate the BWC network and steal the widgetXplus technology details. That’s a threat. A disgruntled employee could change key programming details in the factory system right before quitting just to derail the production line. That’s a threat too. Security-conscious organizations assess threats and rate them according to both the likelihood they might happen and the amount of pain they would cause if they do. Which leads us to the next section.

Vulnerability Assessment  Every asset has some weakness that makes it potentially susceptible to a threat—a vulnerability. The BWC factory technicians control a lot of the systems remotely, for example, across the Internet. That Internet connection presents a potential weak spot in keeping out threat actors. If security controls aren’t sufficient to stop the latest attack, then that connection is a clear vulnerability. The CompTIA Network+ exam objectives don’t follow up with the next step, but you should know that assigning a monetary or intrinsic value to an asset helps the organization prioritize its security. (You’ll get all this in gory detail in CompTIA Security+.)

Given the huge number of potential vulnerabilities out there, it’s impossible for even the most highly skilled technician to find them by manually inspecting an organization’s infrastructure. The best way to know the infrastructure’s vulnerabilities is to run some form of program—a vulnerability scanner—that will inspect a huge number of potential vulnerabilities and create a report—a vulnerability assessment—for the organization to then act upon.

There is no single vulnerability scanner that works for every aspect of an organization’s infrastructure. Instead, good network techs have a number of utilities that work for their type of network infrastructure. Here are a few of the more popular vulnerability scanners and where they are used.

Network security folks rely on a command-line tool named Nmap (Network Mapper) for network scanning, discovery, and auditing. Nmap can do a ton of things. First, Nmap is a port scanner, a software tool for testing a network for vulnerabilities. Port scanning queries individual nodes, looking for open or vulnerable ports and creating a report. Nmap can enable managing upgrades, monitoring hosts, monitoring uptime, network inventory, and more. Written by Gordon Lyon, Nmap is very popular, free, and well maintained. Figure 18-1 shows sample output from Zenmap, a GUI front-end to the nmap command.

Figure 18-1  Nmap output

When you need to perform more serious vulnerability testing, it’s common to turn to more aggressive and powerful comprehensive testers. There are plenty out there, but two dominate the field: Nessus and OpenVAS. Nessus (Figure 18-2), from Tenable Network Security, is arguably the first truly comprehensive vulnerability testing tool and has been around for almost two decades. Nessus is an excellent, well-known tool. Once free to everyone, Nessus is still free for home users, but commercial users must purchase a subscription.

Figure 18-2  Nessus output

OpenVAS is an open source fork of Nessus that is also extremely popular and, in the opinion of many security types, superior to Nessus.

You need to be careful not to use the term vulnerability scanning to mean “just running some program to find weaknesses.” Vulnerability scanning is a part of a more strategic program called vulnerability management, an ongoing process of identifying vulnerabilities and dealing with them. The tools used for vulnerability scanning are an important part of the overall process of vulnerability management.

Penetration Testing  Once you’ve run your vulnerability tools and hardened your infrastructure, it’s time to see if your network can stand up to an actual attack. The problem with this is that you don’t want real threat actors making these attacks. You want to be attacked by an authorized hacker (also known as a “white hat” hacker), who will find the existing vulnerabilities and exploit them to get access. Instead of hurting your infrastructure or stealing your secrets, this hacker reports findings so that you can further harden your network. This is called penetration testing (pentesting).

Unlike vulnerability testing, a good pentest requires a skilled operator who understands the target and knows potential vulnerabilities. To that end, there are a number of tools that make this job easier. Two examples are Aircrack-ng and Metasploit.

Aircrack-ng is an open source tool for pentesting pretty much every aspect of wireless networks. It’s powerful, relatively easy to use (assuming you understand 802.11 wireless networks in great detail), and completely free.

Metasploit is a unique, open source tool that enables the pentester to use a massive library of attacks as well as tweak those attacks for unique penetrations. Metasploit is the go-to tool for pentesting. You simply won’t find a professional in the pentesting arena who does not use Metasploit. Metasploit isn’t pretty (Figure 18-3), but it gets the job done.

Figure 18-3  Metasploit output

Linux distros come with many network diagnostic and pentesting tools available. Just about every security tech has a Kali Linux bootable USB drive, for example, a distro customized for pentesting.

Posture Assessment  Cybersecurity professionals use the term risk posture to describe the overall risk for an organization. BWC’s risk posture, for example, includes threats from threat actors to vulnerable assets, like the factory systems and intellectual property used to make BWC products. Other risk factors need to be included as well, such as the potential for changes in laws or regulations that could negatively affect the company, natural disasters that could take out physical plants, and personal disasters such as the death or disablement of key corporate personnel. That took a morbid turn, but to make a point.

A posture assessment, to use CompTIA’s term, covers it all—all the various threats and risks to which the company is exposed. And such an assessment includes the cost of negative events in both money and time. A proper risk assessment details how the company is vulnerable and can protect against potential negative events.

Business Risk Assessments

CompTIA uses the term business risk assessments to include a subset of risk assessment focused on operations in the organization, such as process assessment and vendor assessment. A business risk assessment looks at other aspects of overall risks facing an organization.

Process Assessment  A process assessment examines various actions performed by an organization to produce desired results. For BWC, for example, one essential process is producing its patented widgets so that the corporation can grow and provide livelihoods for its employees. Another essential process is the research and development into making new and improved products in the future. A third essential process is the procurement of the materials used to create the final product. Another process is the sales force that interacts with other companies to sell widgets.

Within each of these broad-stroke processes are many subprocesses. An essential subprocess in sales, for example, is recruiting the best salespeople BWC can find. A corollary to that is the subprocess of all the support people and equipment that go into making a sales force effective.

In a risk management scenario, a process assessment codifies and ranks essential processes, then examines the likelihood of weakness in the process. A sales force in BWC’s home state of Texas, for example, would have a much lower likelihood of weakness than a brand new team that just started in the first branch office in Mexico. The same kind of assessment would apply all across the board to all essential processes.

Vendor Assessment  Many organizations rely on third parties to provide important pieces that make up their final product. BWC doesn’t own a titanium factory to create the raw material used in its best widgets. BWC buys the titanium from a vendor. BWC also sources some of the servo motors used in its widgets from a vendor that specializes in servo motors.

Proper risk assessment—or in this case, business risk assessment—takes into consideration any potential problems outside of the control of the organization. A vendor risk assessment examines all aspects of a third party’s security controls, processes, procurement, labor policies, and more to see what risks that vendor poses to the organization.

Contingency Planning

Despite the best efforts of competent techs, bad things happen. Anything that negatively affects an organization, that hurts or compromises its people, systems, or ability to function as an entity, is an incident. Incidents can and will vary in size and scope, from something as simple as an attack that was caught and stopped to something serious such as a data breach that affects confidentiality of customer records or a hurricane that wipes out a data center that seriously adversely affects availability. Whatever the case, organizations should develop a set of contingency plans—documents about how to limit damage and recover quickly—to respond to these incidents.

The CompTIA Network+ exam covers several aspects of contingency planning that we can divide into three groups based on the severity and location of the incident: incident response, disaster recovery, and business continuity. Incidents that take place within the organization that can be stopped, contained, and remediated without outside resources are handled by incident response planning. If an incident can no longer be contained, causing significant damage or danger to the immediate infrastructure, it is covered under disaster recovery. Last, if the disaster requires actions offsite from the primary infrastructure, it is under the jurisdiction of business continuity.

While related but not directly connected to contingency planning, we have forensics. Let’s hit all these, but keep in mind that this is only the lightest touch on these very complex aspects of contingency planning. The goal of the CompTIA Network+ certification is only to introduce you to these concepts so that you progress to the next level (hopefully, CompTIA Security+).

Incident Response

The cornerstone of incident response is the incident response team—usually one or more trained, preassigned first responders with policies in place for what to do. Depending on the type of event, the team may be responsible for things like: deciding whether it qualifies as an incident the team should address, ignore, or escalate; evaluating the scope and cause of the issue; preventing further disruption; resolving the cause; restoring order to affected systems; and identifying ways to prevent a recurrence. Most incidents are handled at this level. Organizations should have detailed incident response policies and a detailed incident response plan that will guide the actions of the team in various incident scenarios. However, if an incident is so vast that the incident response team cannot stop, contain, or remediate it, disaster recovery comes into play.

Disaster Recovery

Disaster recovery is a critical part of contingency planning that deals directly with recovering your primary infrastructure from a disaster. A disaster is an event such as a hurricane or flood that disables or destroys substantial amounts of infrastructure.

Disaster recovery starts before a disaster occurs, with an organization developing a disaster recovery plan. An organization considers likely disasters and creates plans for how to deal with them. The actual plans vary by the type of disaster. In many cases an organization has a disaster recovery team, whose goal is to get the IT infrastructure up and running at the primary business location(s). One of the big jobs here is figuring out what kind of system and data backups—copies of essential information that can be restored—your organization will need to get up and running, how often backups should be made, and making sure those backups are available quickly in the face of any negative event.

Network Device Backup/Restore

Network devices can have both configuration data and state data that should be backed up in case of a catastrophe. Configuration data includes all the customized settings for a router, switch, load balancer, intrusion detection/prevention system (IDS/IPS), firewall, or other network device. Having a solid backup of what is essentially a text file enables network professionals to replace and restore settings to a failed device quickly. State data is a different animal. Replacing a router and updating its configuration to match its predecessor is great, but the router still needs to interact with other routers to get into convergence—its state. Another form of “state” involves things like Active Directory. Replacing an AD server and giving it the same configuration as the previous system won’t do much good without restoring the actual Active Directory database that holds user accounts and critical policy data. Adding the latter can restore the AD server’s state.

Backup Plan Assessments

A proper assessment of a backup plan records how much data might be lost and how long it would take to restore. A recovery point objective (RPO) sets an upper limit to how much lost data the organization can tolerate if it must restore from a backup, effectively dictating how frequently backups must be taken. Most restored systems have some amount of lost data based on when the last backup took place. Real-time backups, which are really just redundant servers, are the exception. Likewise, the recovery time objective (RTO) sets an upper limit to how long the organization can tolerate an outage before full functionality must be restored.

The CompTIA Network+ objectives directly refer to two hardware-specific disaster recovery items, MTBF and MTTR. I’ll throw MTTF into the middle just for fun. Here’s the scoop on these redundancy and high availability concepts.

The mean time between failures (MTBF) factor, which typically applies to hardware components, represents the manufacturer’s best guess (based on historical data) regarding how much time will pass between major failures of that component. This assumes that more than one failure will occur, which means that the component will be repaired rather than replaced. Organizations take this risk factor into account because it may affect likelihood and impact of the risks associated with critical systems.

The mean time to failure (MTTF) factor indicates the length of time a device is expected to last in operation. In MTTF, only a single, definitive failure will occur and will require that the device be replaced rather than repaired.

Lastly, the mean time to repair (MTTR) is the amount of time it takes to fix a system after it fails. That includes time to replace components, repair parts, and restore the system to its fully functional state.

Disaster recovery handles everything from restoring hardware to backups, but only at the primary business location. Anything that requires moving part of the organization’s business offsite until recovery is complete is a part of business continuity.

Business Continuity

When a disaster disables, wipes out, floods, or in some other way prevents the primary infrastructure from operating, the organization should have a plan of action to keep the business going at remote sites. The planning and processes necessary to make this happen are known as business continuity (BC). Organizations plan for BC with business continuity planning (BCP). As you might expect, the goal of the team doing BCP is to produce a worthwhile business continuity plan that details risks to critical systems, cost to replace or repair such systems, and how to make those replacements or repairs happen in a timely fashion. Good BCP will deal with many issues, but one of the more important ones—and one that must be planned well in advance of a major disaster—is the concept of backup sites.

Every business continuity plan includes setting up some form of secondary location that enables an organization to continue to operate should its primary site no longer function. CompTIA identifies four types of secondary site: cold, warm, hot, and cloud.

•   A cold site is a location that consists of a building, facilities, desks, toilets, parking—everything that a business needs…except computers. A cold site generally takes more than a few days to bring online.

•   A warm site starts with the same components as a cold site, but adds computers loaded with software and functioning servers—a complete hardware infrastructure. A warm site lacks current data and may not have functioning Internet/network links. Bringing this site up to speed may start with activating your network links, and it most certainly requires loading data from recent backups. A warm site should only take a day or two to bring online.

•   A hot site has everything a warm site does, but also includes very recent backups. It might need just a little data restored from a backup to be current, but in many cases a hot site is a complete duplicate of the primary site. A proper hot site should only take a few hours to bring online.

•   As organizations increasingly migrate servers and services to the cloud, a cloud-site backup becomes a viable alternative to any of the traditional options. With a cloud site, everything of note is stored in the cloud, including servers, client machine images, applications, and data. If some disaster hits, an organization can quickly move to a new location unaffected by the disaster and access its resources as soon as it has Internet connectivity. In the increasingly decentralized workplace today, having a cloud-based system makes disaster “recovery” almost a moot point.

Business continuity isn’t just about backup sites, but this aspect is what the CompTIA Network+ exam focuses on. Another term related to continuity planning is succession planning: identifying people who can take over certain positions (usually on a temporary basis) in case the people holding those critical positions are incapacitated or lost in an incident or disaster.

Forensics

Computer forensics is the science of gathering, examining, analyzing, preserving, and presenting evidence stored on a computer or any form of digital media that is presentable in a court of law. Computer forensics is a highly specialized science, filled with a number of highly specialized skills and certifications. Three of the top computer forensic certifications are the Certified Forensic Computer Examiner (CFCE), offered by the International Association of Computer Investigative Specialists (IACIS); the Certified Computer Examiner (CCE), from the International Society of Forensic Computer Examiners (ISFCE); and the GIAC Certified Forensic Analyst (GCFA), offered by the Global Information Assurance Certification (GIAC) organization. Achieving one of these challenging certifications gets you well on your way to a great career in forensics.

The CompTIA Network+ exam doesn’t expect you to know computer forensics—that’s a topic for the Security+ Exam—but it’s still a good idea for you, as the typical technician, to understand enough of forensics that you know what to do in the rare situation where you find yourself as the first line of defense.

In general, CompTIA sees you as either the first responder or the technician responsible for supporting the first responder. The first responder in a forensic situation is the person or robot whose job is to react to the notification of a computer crime by determining the severity of the situation, collecting information, documenting findings and actions, and providing the information to the proper authorities. In a perfect world, a first responder has a toolbox of utilities that enables him or her to capture the state of the system without disturbing it. At the very least the first responder needs to secure the state of the media (mainly hard drives) as well as any volatile memory (RAM) in a way that removes all doubt of tampering either intentionally or unintentionally.

Like so many aspects of computer security, there isn’t a single school of thought on how exactly you should do computer forensics. There are, however, a number of basic attitudes and practices shared by every school of thought, especially at the very basic level covered by the CompTIA Network+ exam.

In general, when you are in a situation where you are the first responder, you need to

•   Secure the area

•   Document the scene

•   Collect evidence

Secure the Area

The first step for a first responder is to secure the area. In most cases someone in authority has determined the person or persons who are allegedly responsible and calls you in to react to the incident. As a first responder, your job is to secure the systems involved as well as secure the immediate work areas.

The main way you secure the area is by your presence at the scene. If possible, you should block the scene from prying eyes or potential disturbance. If it’s an office, lock the door, define the area of the scene, and mark it off in some way if possible.

Keep in mind that an incident is rarely anything as exciting (or scary) as catching a user committing a felony! In most cases an incident involves something as simple as trying to determine if a user introduced malware into a system or if a user was playing World of Warcraft during work hours. In these cases it’s often easy to do your job. Simply observe the system and, if you identify an issue, provide that information in-house. The rules for forensics still apply. If, however, you’re responding to one of the scarier scenarios, it’s important for you as a first responder to understand when you need to escalate an issue. Given that you were called in to react to a particular incident, most escalation situations involve you discovering something more serious than you expected.

Document the Scene

Once you have secured the area, it’s time to document the scene. You need to preserve the state of the equipment and look for anything that you might need to inspect forensically.

While it’s obvious you’ll want to locate computers, switches, WAPs, and routers, be sure to take copious notes, paying particular attention to electronic media. Here are a few items you will want to document:

•   Smartphones

•   Optical media

•   External hard drives

•   USB drives

•   Cameras

•   VoIP phones

Collect Evidence

With the scene secured and documented, it’s time to start the evidence/data collection. The moment you take something away from an incident scene or start to handle or use any devices within the incident scene, there is a chance that your actions could corrupt the evidence you are collecting. You must handle and document all evidence in a very specific manner. Chain of custody, as the name implies, is the paper trail of who has accessed or controlled a given piece of evidence from the time it is initially brought into custody until the incident is resolved. From the standpoint of a first responder, the most important item to keep in mind about chain of custody is that you need to document what you took under control, when you did it, what you did to it, and when you passed it to the next person in line.

From a strict legal standpoint, the actual process of how you obtain evidence and collect data is a complex business usually left to certified forensic examiners. In general it boils down to using specialized utilities and tools, many of which are unique for the type of data you are retrieving. The tools used also differ depending on different OSs, platforms, and the personal tastes of the examiners. Every forensic examiner has a number of these tools in his or her unique forensic toolkit.

If you need to transport any form of evidence, make sure to document for chain of custody as well as inventory. In other words, make a list of who has what equipment/evidence at any one time. Pack everything carefully. You don’t want a dropped case to destroy data! If you are transporting evidence, don’t leave the evidence at any time. Delay your lunch break until after you hand the evidence over to the next person! Follow the proper procedures for data transport to avoid any problems with the evidence.

The end result of your forensics work is a forensics report. In general, this is where you report your findings. A good forensics report includes the following:

•   Examiner’s name and title

•   Examiner’s qualifications

•   Objective for the forensics

•   Any case or incident numbers

•   Tools used

•   Where the examination took place

•   Files found

•   Log file output

•   Screenshots

Forensics reports and evidence will be used in many circumstances. A forensics expert will present the report and evidence to the hiring entity. A company might review the report and discover potential criminal activity therein, and place a legal hold on the document and evidence. A legal hold is the process of an organization preserving and organizing data in anticipation of or in reaction to a pending legal issue. The data and the reports must be preserved in such a way that, should a legal authority want access to that data, they can reasonably access it. A forensic examiner will likely be called to court as an expert witness or for testimony.

Chapter Review

Questions

1.   Which item should be found in a security policy?

A.   Acceptable use policy

B.   Emergency exit plan

C.   Service-level agreement

D.   Instruction on how to fill out a change request form

2.   Through what mechanism is a change to the IT structure initiated?

A.   Users make a change to their environment, then report the result to the change management team.

B.   A user submits a request for funding a change to upper management, receives approval, and then submits a requisition to the change management team to source and purchase new equipment.

C.   Users submit a change request to the change management team.

D.   The change management team issues a proposed change to users in the organization, then evaluates the responses.

3.   Users need training from the IT department to understand which of the following?

A.   How to troubleshoot lost network connections

B.   How to secure workstations with screen-locking and password-security techniques

C.   How to send e-mail to the change management team

D.   How to check their network connection

4.   When is a memorandum of understanding used?

A.   As part of a legal contract

B.   As part of a statement of work (SOW)

C.   When a service-level agreement (SLA) expires

D.   When a legal contract is not appropriate

5.   The best way to know the vulnerabilities of an IT infrastructure is to run what?

A.   A system-wide antivirus scanner

B.   Cable certifier

C.   Critical asset scanner

D.   Vulnerability scanner

6.   What is succession planning?

A.   Identifying personnel who can take over certain positions in response to an incident

B.   The career path by which employees of an organization can grow through the ranks

C.   The selection of failover servers in the event of a catastrophic server failure

D.   The selection of failover routers in the event of a catastrophic router failure

7.   During and after a change to the IT infrastructure, what must be done?

A.   Downtime must be scheduled.

B.   New equipment must be installed.

C.   Operating systems must be patched.

D.   The changes must be documented.

8.   What is the job of a first responder?

A.   Investigate data on a computer suspected to contain crime evidence.

B.   React to the notification of a computer crime.

C.   Power off computers suspected of being used in criminal activity.

D.   Shut down computers and remove mass storage drives.

9.   Which of these describes the maximum time the organization can be without a critical system?

A.   Recovery point objective (RPO)

B.   Mean time between failure (MTBF)

C.   Recovery time objective (RTO)

D.   Mean time to repair (MTTR)

10.   Which deployment model uses employee-owned mobile devices for corporate use?

A.   BYOD

B.   COBO

C.   COPE

D.   CYOD

Answers

1.   A. An acceptable use policy (AUP) is a typical item found in a security policy.

2.   C. Users submit a change request to the change management team to effect a change to an IT structure.

3.   B. Typical user training includes how to secure workstations with screen-locking and password-security techniques.

4.   D. A memorandum of understanding (MOU) is used when a legal contract is not appropriate.

5.   D. Run a vulnerability scanner to find weaknesses in an IT infrastructure.

6.   A. Identifying personnel who can take over certain positions in response to an incident is essential in succession planning.

7.   D. When changing an IT infrastructure, always document the changes.

8.   B. A first responder reacts to the notification of a computer crime.

9.   C. The recovery time objective (RTO) defines the maximum time it should take to restore a critical system after failure.

10.   A. In a bring your own device (BYOD) model, employers allow employees to bring mobile devices into the workplace for corporate use.