OVER THE PAST FEW YEARS, there has been a huge influx into the workplace of wireless local area network (WLAN) technology and mobile devices. Even before the advent of bring your own device (BYOD), security departments considered it a risk to introduce new technologies and devices into the workplace. However, the desire of those in business to accept these new technologies and their advantages has outweighed these security fears. This has put the onus for mitigating the risk onto security departments.

Of course, before members of a team can properly mitigate the risk of new technologies or new technology policies, they must first fully understand the risk in the context of their specific environment. This chapter focuses on the risk-assessment procedure as applied to WLANs and Internet Protocol (IP) mobility.

Risk Assessment

The National Institute of Technology Standards (NIST) defines risk assessment as follows:

The process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the nation, resulting from the operation of an information system. Part of risk management incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place.

Also according to NIST:

The purpose of risk assessments is to inform decision makers and support risk responses by identifying:

(i)   relevant threats to organizations or threats directed through organizations against other organizations;

(ii)  vulnerabilities both internal and external to organizations;

(iii) impact (i.e., harm) to organizations that may occur given the potential for threats exploiting vulnerabilities; and

(iv) likelihood that harm will occur.

Risk assessments are performed less frequently than security audits, which you’ll read about later. They are used to determine any change in requirements, technologies, or threats since the last risk assessment (assuming there was one). The actual assessment process includes the identification and analysis of the following:

•  All assets related to the system or network

•  Known threats that could affect the security of the system or network

•  System or network vulnerabilities

•  Potential impacts and levels of risk associated with threats

•  Required measures to mitigate the vulnerability and threat

To determine the risk, you must know the system or network’s vulnerabilities. These vulnerabilities can be categorized into three general groups:

•  Interception—This applies to data that travels over the network. This data sometimes travels over connections or media, such as the Internet, that are out of the company’s control. Data can be intercepted, stolen, or modified, resulting in a loss of confidentiality and integrity.

•  Availability—Systems, servers, and applications must be available for the purpose they serve under the service level agreements (SLAs) to which they must adhere. (An SLA is a document that identifies an expected level of performance.) Today, as IP mobility and remote mobile access become more pervasive and more workers are based outside the office, there is an even greater focus on providing SLA availability goals.

•  Access—This refers to the points where remote users can join the network and where internal users can communicate with the outside world through e-mail, instant messaging (IM), and all the other myriad services available on the Internet. These access points are the most vulnerable locations in a network.

Of course, identifying network vulnerabilities is only part of the assessment. You must also identify suitable controls. Fortunately, for most network vulnerabilities, there are recommended, tried-and-tested controls. These ensure that most vulnerabilities that are identified will be effectively mitigated. Some of the controls used to address existing vulnerabilities in the three categories listed earlier—interception, availability, and access—include the following:

•  Interception—The most effective control for combating interception is encrypting data. The purpose of encryption is to devalue any intercepted data, as it requires an attacker to invest a lot more time and effort to decrypt it.

•  Availability—The most important control for combating availability issues is the use of fault-tolerant and high-availability designs that eliminate single points of failure. This means no single fault can break a network. There will always be an alternative path, server, or application to provide uninterrupted service.

•  Access—You control access through security devices such as firewalls, intrusion prevention systems, and Secure Sockets Layer/virtual private network (SSL/VPN) concentrators. An administrator implements these controls through network designs and configuration in demilitarized zones (DMZs) or virtual private network (VPN) access networks. Because these points in the network are effectively the gateways into and out of the network, a robust security policy should be in place to authenticate and authorize remote users. There should also be strict rules to filter incoming network protocols and activity.

To identify and address all network vulnerabilities, network inventories, network diagrams, and network designs should be available as input into the process. Because there will be far more network vulnerabilities in a real-world scenario where Web applications and Web servers are open to the Internet, it is important to get an understanding of their requirements and protocols.

This is where gathering information and collaborating with application developers and server administrators becomes relevant. Holding interviews with key parties is the standard way to gather information, along with doing research on vendor Web sites. Running vulnerability scanners is also critical. A vulnerability scanner such as Nessus can check for thousands of known operating system (OS) vulnerabilities, as well as those of hosts, infrastructure devices, and servers. After you identify all the assets and their vulnerabilities, it is time to suggest or introduce appropriate security measures.

You should conduct security risk assessments at least every two years, as they are only snapshots of the time they were performed. Whenever new technologies or major changes are introduced into the system or network, it is best to undertake a new security risk assessment. An example of this would be recent trends in BYOD and bring your own application (BYOA). (BYOA includes cloud-based applications such as Dropbox and Google Docs, for example.) These have introduced new vulnerabilities and risks that previous risk assessments did not identify. This scenario would entail performing a fresh, comprehensive assessment. This assessment should have the scope to redefine security policy and asset management as well as identify new vulnerabilities that come with mobile devices, such as differing OSes, applications, malware, and connectivity methods. Once a comprehensive network risk assessment is complete, you typically follow it with a security audit.

Risk Assessment on WLANs

Looking at risk assessment from a wireless perspective, it’s critical to identify how a risk assessment on a WLAN differs from one done on a traditional wired network. This means identifying the risks associated with mobile devices in particular. The most common risks on WLANs in a business network are as follows:

•  Exposure of critical information to wireless sniffers and eavesdroppers

•  Leakage of critical information beyond the network boundaries on unsecure devices

•  Theft of data

•  Loss, theft, or hijacking of a mobile device

•  Fraud caused by disruption, eavesdropping, and copying of data

•  Viruses, worms, and Trojans

Although most of these risks also exist on wired and static networks, the nature of mobile and wireless networks greatly increases the probability of the first four items, which are all interrelated. Even so, the key elements necessary to mitigate risks associated with WLANs and mobile devices have not changed from the fundamentals of risk mitigation for wired networks. These elements include the following:

•  Access control

•  User authentication

•  Data encryption

•  Intrusion prevention

•  Antivirus and anti-malware software

•  Standards, guidelines, and policies

•  Network-perimeter and Internet security

•  Transmission security

•  Application and Web services

The steps taken to assess risk on a wireless network or on a single segment that uses portable mobile devices (laptops, mobiles, and tablets) are no different from the steps taken to perform a traditional risk assessment. Your efforts should be seamlessly incorporated into a single, all-encompassing risk-assessment procedure. To that end, this chapter examines a framework for IT security management that includes a risk-assessment and security-audit model for the entire network infrastructure, whether fixed or mobile.

Other Types of Risk Assessment

Not all risk assessments are comprehensive in scope or scale. In some cases, risk assessments can be limited in scope or depth. Examples include the following:

•  Pre-production assessment—This type of assessment is comprehensive, but its scope is restricted to the production of the information system before it is rolled out. It concerns itself with the major functions and changes that the system under production will produce.

•  High-level assessment—This type of assessment involves high-level risk analysis across the entire network, without a deep or fully detailed technical review. High-level assessments are typically applied during the planning phases of network or system development, before the design process begins.

IT Security Management

IT security management involves several related activities. These may be performed as part of a cycle of repeating security processes, depending on the organization’s size and complexity. Security practices and policies should be appropriate for the size and value of the network and its assets. They should be cost-effective and in proportion to the value of what you wish to protect. The first step, then, logically requires identifying the assets needing protection, as well as their relative value and importance to the company. Subsequently, you must identify the threats to those assets and the possible consequences of those threats.

Methodology

There are two methods for performing a risk assessment:

•  Quantitative assessment—In this scenario, the assessment assigns a monetary value to the assets. The result is a quantitative statement on risk and the cost of impact.

•  Qualitative assessment—This method uses a more subjective calculation of risk by assigning it a level—low, medium, or high—and a probability multiplier to determine the risk and impact level. The qualitative approach is the most commonly used.

Legal Requirements

Laws and regulations require periodic risk assessments in many different enterprise environments. In the United States, both the Sarbanes-Oxley Act and the Health Insurance Portability and Accountability Act (HIPAA) require security and control infrastructures to be put in place. Although compliance with these acts does not require specific methods or techniques, it does require that the company be able to prove to an independent auditor that it has effective and reasonable security in place.

Other Justifications for Risk Assessments

There are other rationales behind performing security risk assessments, such as justifying the cost of security. An effective risk assessment identifies threats to valuable company assets and raises awareness within management of the required costs to protect systems and services. Additionally, it can promote communications and productivity and break down interdepartmental barriers because collaboration is required across all the disciplines of the IT department and its business partners. Furthermore, this interdepartmental collaboration raises awareness of security and its requirements, and enables non-technology departments to provide input into the process. Consequently, a department may revise its work practices or procedures to mitigate the risks it has become aware of thanks to the assessment. This is a form of self-auditing.

Assessing security risk is typically the initial step in security management. When you are assessing network assets (such as servers, hosts, infrastructure, and applications) for risk, the goal is to identify vulnerabilities, prioritize, and apply quantitative or qualitative values to possible impacts or consequences. The network auditors can then use this assessment as the basis for establishing a cost-effective security program, which they can present to the company’s management.

Risk assessments vary in scope depending on the complexity of the network and the company assets. For instance, a small company with just one WLAN and a single Internet connection may follow the same framework but will not cover the scope or require the full diligence and rigorous investigation of an enterprise risk assessment. For the purpose of clarity and completeness, the following sections discuss a framework suitable for a company of any size.

Security Risk Assessment Stages

The activities undertaken when performing a risk assessment are as follows:

•  Planning

•  Information gathering

•  Risk analysis

•  Identifying and implementing controls

•  Monitoring

Before discussing the stages of a risk assessment, it’s a good idea to review the following points:

•  An asset is anything of value, such as people, property, intellectual property, or information. In essence, an asset is what you are trying to protect.

•  A threat is anything that can damage or compromise an asset. In other words, a threat is what you are trying to protect against.

•  A vulnerability is a weakness that makes a threat possible or even probable. A vulnerability can also be a gap in the protection measures against a threat.

•  Risk is the combination of all three, related in the following way:

Asset × Threat × Vulnerability = Risk

In other words, risk is a function of a threat exploiting a vulnerability to damage an asset. Consequently, if there is no vulnerability, there is no risk. Similarly, if there is no threat, there is no risk. (This is a dangerous justification, however. You must take great care before dismissing a threat when there is a known and defined vulnerability.)

These are important definitions. Understanding the relationship between assets, threats, vulnerabilities, and risk is a crucial step in accurately assessing risk and ultimately securing assets.

Planning

Planning is an essential stage. It occurs before any security risk assessment can take place. Even when doing small security audits with limited scope, you should complete the planning stage in its entirety. During this stage, stakeholders, roles, and responsibilities are determined. Even more vital, it is when permission is sought, granted, and documented.

Information Gathering

The objective of the information gathering stage is not just to collect information, but also to gain an understanding of the existing systems, network, and environment. This knowledge, gleaned through interviews, group discussions, and other research, will enable you to identify risks, as well as controls for those risks.

The information typically gathered during this stage includes the following:

•  Security policy and objectives

•  System and network architecture

•  As-built designs and diagrams

•  Physical asset inventories

•  Network protocols and services

•  Access control procedures

•  Firewall deployment and policy

•  Identification and authorization mechanisms or systems

•  Documented policies and guidelines

There are two general types of information gathering: a general controls review (GCR) and a system review.

General Controls Review

A general controls review (GCR) identifies threats existing in the general security processes. GCRs are concerned with the high-level security of an existing system. The review involves collecting data to check whether physical security measures match policy and documentation. Physical access control can also be visibly noted, and policy and procedures checked for compliance and efficiency through group meetings or multilevel interviews.

An auditor carries out a GCR via documentation reviews, site visits at data centers and computer rooms, and stakeholder interviews with staff at different operational levels. These multilevel interviews can prove particularly effective in revealing a failure to implement security policy at the hands-on, operational level, as well as a lack of security awareness.

A general control review is concerned with high-level functions such as the following:

•  Physical security

•  Change-management control

•  Access control/authentication and authorization

•  Awareness programs and training

•  Roles and responsibilities

•  Security policy, guidelines, standards, work practices, and procedures

The GCR is used to check that these features are implemented properly, not just stated on paper in policies and guidelines. If access to computer resources and applications is restricted to roles and authorized persons with privileged access, then that should be demonstrable.

System Review

Unlike a GCR, a system review seeks to identify vulnerabilities at the network and application levels. This type of review focuses its attention on the operating system, administration, and monitoring tools used by administrators of the different platforms. Typically, a system review will look to server logs and system files for baseline vulnerabilities, but it will also consider other information sources such as the following:

•  Access control files

•  Running services and processes

•  Configuration settings

•  Security patch levels

•  Encryption and authentication tools

•  Network management tools

•  Logging or intrusion detection tools

•  Vulnerability scanners

The review team will attempt to spot abnormal behavior, such as repeated unsuccessful login attempts on secure accounts like administrator or root. In addition, system configuration files and network configurations can be checked against documentation for compliance. Noncompliance can be an indicator of poor change-control procedures, unauthorized configuration changes, or improvised emergency configuration changes.

During a system review, it is often worthwhile to use specialized tools or scripts to collect all the data from the individual systems in the network. These can automate and greatly reduce the time taken to collect configuration files manually. After all the system data has been reviewed, the next stage is the risk analysis.

Risk Analysis

This is the stage where the security team uses risk-analysis techniques to determine the value of assets and identify any associated risks. Risk analysis is a component of risk assessment, a single-process stage. It does involve several subprocesses, however, including:

•  Asset identification and valuation

•  Threat analysis

•  Vulnerability analysis

•  Asset, threat, and vulnerability mapping

•  Impact and probability assessment

•  Risk results analysis

Asset Identification and Valuation

A risk assessor must identify all the assets that fall within the scope of the risk assessment. These assets can be physical, real objects, such as servers, hardware, or network devices, or intangible assets, such as information, services, or reputation.

Classification is an important part of identification. An asset should be classified by category, such as process, application, server, router, or information. (These categories will differ depending on the type of system or network under assessment.)

The purpose here is to show the importance and relevance of the asset to the system under assessment. The assessor can then place a value on the asset in terms of its importance. This should take the form of an inventory checklist of assets and their corresponding values in terms of the following:

•  Tangible values, such as the cost of replacing physical devices

•  Intangible values, such as reputation or lost data

•  Information values

•  The name and type of information

•  Information flows, whether incoming or outgoing

•  The physical location of physical assets

•  Software installed on servers

•  Indicators showing the importance or value of the asset

•  Indicators of services supplied by the asset

•  Values assigned to each individual asset

Threat Analysis

When the asset inventory checklist is complete, it’s time to start the threat analysis, in which each asset is analyzed to identify any current threats. A threat is anything that can exploit a vulnerability, whether accidentally or maliciously, and disrupt or destroy an asset. Sources of threats include human error, hacking, industrial espionage, disgruntled employees, theft, malicious actions, and environmental phenomena.

Threats can be classified into one of three general categories:

•  Social threats—These threats are related to human actions. They can be intentional or unintentional.

•  Technical threats—These threats result from technical issues or faults.

•  Environmental threats—These threats are the result of environmental elements such as storms, floods, fires, and power outages.

The purpose of the threat analysis is to identify and document the threats to each asset. It is not just a case of listing each possible threat, however. You must also indicate the likelihood that the threat may occur and the threat’s potential to harm or destroy the asset.

You can identify and evaluate environmental threats using your knowledge about the history of the climate in the geographic area in question. Similarly, historical records will reveal the likelihood of main power supply outages. You can evaluate social threats against human actions such as lack of training or negligence. Again, knowledge of history is a way to qualify these types of threats. In contrast, technical threats can be more specifically identified using a vulnerability scanner. After all, a risk cannot exist without a vulnerability.

Vulnerability Assessment

A vulnerability is a weakness or gap in the defenses of an asset that makes it a potential target for exploitation by a threat. The vulnerability could be any number of things—for example, a missing security patch, which would allow an asset to be compromised. It could also be poor security awareness among employees and management or environmental causes such as a poor regional or national electrical supply. Vulnerability analysis is the task of identifying, evaluating, and documenting the existence of these possible asset vulnerabilities.

System or network vulnerability is measured in terms of accessibility and the corresponding number of authorized users. Therefore, a system or closed network with strictly limited authorized users and no external connection will have less inherent vulnerability than a Web server DMZ that is open to the public Internet and accessed by tens of thousands of users on an hourly basis. Accessibility and the number of authorized users make systems or networks vulnerable to threat by increasing the threat landscape and the possible number and variety of threat sources and vectors.

Each vulnerability must be considered and evaluated by applying a level of degree of importance, such as low, medium, or high. Mission-critical assets and their vulnerabilities should be identified first. With technical vulnerabilities, tools such as vulnerability scanners are used to identify missing patches or gaps in a system or network’s security. A vulnerability scanner uses databases containing thousands of known vulnerabilities to check a server or router for existing problems. Scanners such as OpenVAS 7.0, an open source program from the Nessus Project, are updated daily and can test for more than 35,000 vulnerabilities.

Scanning such a large number of system requests on a server or host can cause it considerable stress, leading to a performance drop as resources are consumed. Therefore, it is best to have the server administrator present when the asset is being checked so he or she can monitor the server’s health during testing.

Running a vulnerability scanner, such as Nessus, Saint, or OpenVAS, will detect many vulnerabilities in operating systems, applications, Web servers, and services, including open ports and missing OS and security patches. Not all detected vulnerabilities are genuine, however. Indeed, some may be false positives—for example, when the scanner highlights a known vulnerability that doesn’t apply to the device being scanned. There are several types of false positives. Typically, these are caused by one of the following:

•  A response header that is hidden or suppressed

•  A header rewritten by a firewall

•  A version update that is loaded but not active (version updates often activate on a server reboot)

•  Failed or prematurely terminated version updates

Researching and evaluating these false positives can waste time. Worse, they can result in testers skipping other vulnerabilities, which may or may not also be false positives.

There is also the real potential for false negatives—that is, when the scanner doesn’t highlight a vulnerability, leaving the security flaw still in place. Such false negatives can be very dangerous. Generally speaking, it’s worth dealing with false positives to reduce as much as possible the occurrence of false negatives, which are essentially time bombs in the network. Therefore, the accuracy of the vulnerability scanner is of paramount concern.

Vulnerability scanners typically use version analysis, in which the scanner sends out requests to the target system and, upon receiving a response, analyzes the headers for the version details. After the scanner has ascertained the hardware or OS version, for example, it assumes that the vulnerabilities known to be associated with that hardware or OS version will be present, and lists them. This can produce a quick and impressive list of vulnerabilities that do not actually exist and at the same time miss real vulnerabilities.

The alternative method is to employ a vulnerability scanner that uses behavior analysis. Behavior analysis relies not on version data, but on how the system responds to requests, the aim being to find unexpected responses to a query. These unexpected responses enable the scanner to accurately identify that a vulnerability is present. Behavior analysis takes longer, but is more thorough and accurate.

You can quickly rectify most identified vulnerabilities, but you should take care to gain permission for any changes to the system through the proper change-control channels. Again, you must never make changes without proper authority, even if the system is open to severe threat. Permission must always be granted, and the relevant change control process followed.

Asset, Threat, and Vulnerability Mapping

Asset, threat, and vulnerability mapping is the process of documenting or pairing asset vulnerabilities with any potential threats that could expose those vulnerabilities. If you recall the relationship between assets, vulnerability, threat, and risk (Asset × Vulnerability × Threat = Risk), then you can see the purpose of asset, threat, and vulnerability mapping. It reveals that risk is present only if there is both a threat and a vulnerability. By performing this mapping, you can greatly reduce the list of potential risks that require risk results analysis, saving a lot of time and unnecessary effort.

The National Institute of Standards and Technology (NIST) offers the following guidance on mapping:

Threat-vulnerability pairing (i.e., establishing a one-to-one relationship between threats and vulnerabilities) may be undesirable when assessing likelihood at the mission/business function level, and in many cases, can be problematic even at the information system level due to the potentially large number of threats and vulnerabilities. This approach typically drives the level of detail in identifying threat events and vulnerabilities, rather than allowing organizations to make effective use of threat information and/or to identify threats at a level of detail that is meaningful.

In other words, there may be times when a detailed mapping is too resource-intensive, especially mapping that gets in the way of mitigating a vulnerability or threat. Remember, the object is to reduce the risk, not to provide documentation for its own sake.

Impact and Probability Assessment

As you might guess, an impact and probability assessment is a combination of the following:

•  Impact assessment—The purpose of an impact assessment is to determine the consequences (including the degree of harm) of a threat exploiting a vulnerability on an asset. Unfortunately, however, due to budgetary, technical, or time constraints, it might not be possible to address the impact of all threats. Therefore, the emphasis should be on addressing only those assets, threats, and vulnerabilities with the most severe potential impact. The impact might be on any number of things, such as availability of service, loss of reputation, profit loss, increased costs, or drops in performance. The more severe the potential impact, the greater the risk; therefore, these items should be addressed first.

•  Probability assessment—Also called a likelihood assessment, a probability assessment is used to identify greater or lesser threats based on a score rather than a mathematic probability. The probability assessment expresses its results in terms of high, medium, or low based on the ability or motivation of the threat source, the nature of the vulnerability, and the effectiveness of security controls.

Risk Results Analysis

Risk results analysis involves analyzing results and presenting them using any of the following methods:

•  Quantitative and qualitative methods

•  A risk map

•  A matrix approach

Qualitative methods rely on an assessor’s subjective assumptions, which are based on experience, research, history, and judgment. They are descriptive and are expressed in words and rankings of severity for comparison. Qualitative methods rely on the categorization of risks and a subjective ranking system, whether that system uses terms like “low,” “medium,” and “high” or a number-ranking system (for example, 1 to 10) to convey the degree of importance. Assessors typically use qualitative methods when doing high-level assessments prior to a planning phase. Qualitative methods are also used extensively in repeating enterprise risk assessments where there is neither the time nor the budget to use fully quantitative methods.

In contrast, quantitative methods are expressions of financial worth. They are usually presented in the following three terms:

•  Single loss expectancy (SLE)—The single loss expectancy (SLE) is the expected monetary cost of the occurrence of a risk on an asset.

•  Annual rate of occurrence (ARO)—The annual rate of occurrence (ARO) is the probability that a risk will occur in a particular year. It factors in the number of times it will occur in a year if no action is taken.

•  Annualized loss expectancy (ALE)—The annualized loss expectancy (ALE) is the product of the ARO and the SLE.

Quantitative methods require more time and greater effort on the part of the assessor because much of the detailed information is not readily available—either because it’s speculative or because it’s tightly controlled. In addition, collecting this information results in considerable operational overhead. Because of this, a qualitative approach is used for the majority of the report, with some quantitative methods employed for critical systems or where a large financial investment will be required to mitigate the risk.

A risk map is a way of graphically displaying assets and their risk levels, with the impact on the y-axis and likelihood on the x- axis. Both axes are measured from low to high, which means an asset plotted in the bottom-left corner of the map is a low-impact/low-probability risk. In contrast, one in the top-right corner is a high-impact/high-probability risk. Risk maps are good tools for visualizing the relationship and severity of risk within the scope of the assessment.

A matrix approach is a way to display the results of a qualitative assessment. A table or grid is drawn for each risk, with columns for impact, likelihood, and risk level (Impact × Likelihood); rows for the individual risk categories of confidentiality, integrity, and availability; and a final row for the overall assessment. Figure 10-1 shows an example of a matrix approach.

Identifying and Implementing Controls

After the completion of the risk-analysis stage, it’s time to start selecting and implementing appropriate controls, or safeguards, to mitigate the risk for each asset, threat, and vulnerability mapping. Of course, not all risk can be removed. That means there will be times when you must opt to avoid risk, reduce risk to a tolerable level, transfer risk (if possible), or accept risk. Which of these you choose depends on the asset value and the risk culture within the organization. Some companies are risk averse, whereas others live happily with high levels of risk. The purpose here is to find controls that, at a minimum, match the levels of risk that management is willing to tolerate.

In general terms, controls can be classified into three types:

•  Technical controls—These include access controls, antivirus software, firewalls, and so on.

•  Administrative or management controls—These include security planning and implementing rules.

•  Operational controls—These include security personnel, data backups, contingency plans, and system maintenance.

Choosing suitable risk controls requires technical knowledge and skill. The cost of managing risk must be appropriate for the risk exposure.

Monitoring

Risk assessment is a repetitive process, and each assessment represents a snapshot in time. Therefore, the results should be properly documented, as they will be the baseline for future reassessments of the environment.

As you have seen with wireless and IP mobility, technology in the enterprise can change quickly. New devices and technologies have quickly become pervasive in the network environment. Reassessments are necessary to address these new technologies. Therefore, having a solid risk assessment baseline is crucial. It can serve as the foundation for introducing new protocols and hardware. This allows the seamless introduction of change without requiring a full, ground-up assessment. Additionally, documenting and monitoring the existing organization’s systems and infrastructure by means of the risk assessment also facilitates conducting a security audit.

Security Audits

A security audit follows many of the same steps as a risk assessment. The difference is that a security audit looks for proof that best practices and procedures were followed. In many cases, these audits are internal. However, the same person or team who performed the risk assessment should not carry out a security audit.

An auditor conducting a security audit for WLAN security vulnerabilities should look at the following points (in addition to those items examined on a wired network):

•  The potential for unauthorized access to the WLAN

•  Radio frequency (RF) leakage beyond the physical perimeter

•  The use of weak encryption protocols such as WEP or WPA

•  The existence of rogue access points

•  If preshared keys are used, how widely the preshared key is known (or the method through which it is shared)

•  The knowledge, training, and awareness of security personnel and staff

•  The wireless network’s conformity to the company’s security policy

Security risk assessments and security audits occur at different times in the security management cycle. A security risk assessment is conducted at the beginning of the cycle. It is the means of identifying the assets to be secured and the possible vulnerabilities of those assets. These will determine the security tools or measures required. A security audit, on the other hand, is a repetitive checking process that occurs throughout the cycle. During a security audit, the security measures recommended in the risk assessment can be checked for effectiveness and compliance with the security policy.

Generally speaking, a security audit’s purpose is to ensure that the organization adheres to its own security policy. But a company with a poorly thought out and limited security policy can demonstrate a sterling record of compliance if auditors focus simply on checking the box. This may go on for years, with weaknesses exposed only when a breach occurs. Inevitably, the forensic (post-breach) assessment will not only reveal the root cause of the breach, but also point out severe lapses in the risk-analysis and risk-mitigation processes.

CHAPTER 10 ASSESSMENT

1. Risk assessment on wireless networks is significantly different from risk assessment on wired networks.

A. True

B. False

2. Vulnerabilities can be categorized into which of the following three groups?

A. Data, client, and people

B. Interception, availability, and access

C. Compliance, assessment, and audit

D. Encryption, authentication, and RF power

3. Common risks on WLANs in a business network include which of the following?

A. Exposure of critical information to wireless sniffers and eavesdroppers

B. Data leakage of critical information

C. Theft of data

D. Loss, theft, or hijacking of a mobile device

E. Fraud caused by disruption, eavesdropping, or the copying of data

F. All of the above

4. Which of the following describes preproduction vulnerability assessments?

A. The manufacturer performs them so you don’t have to.

B. They are the only assessments needed once the network is deployed.

C. They are performed on new solutions/devices before these are added to the production network.

D. They are a waste of time.

5. Risk can be calculated as which of the following?

A. Asset + Vulnerability + Threat

B. Asset × Vulnerability × Threat

C. Asset × Threat − Vulnerability

D. (Asset + Vulnerability)/Threat

6. Vulnerability analysis is the task of identifying, evaluating, and documenting the existence of possible asset vulnerabilities.

A. True

B. False

7. Risk analysis results can be calculated using both quantitative and qualitative methods.

A. True

B. False

8. The implementation of barriers, hardening, and monitoring are examples of which of the following?

A. Security controls

B. Protocols

C. Security regulations

D. Assessment techniques

E. All of the above

9. Which of the following is not a point of emphasis when auditing security on a wireless network?

A. Radio frequency (RF) leakage beyond the physical perimeter

B. The use of weak encryption protocols such as WEP or WPA

C. The completeness of the existing security policy

D. The wireless network’s conformity to the company’s security policy

10. The annualized loss expectancy (ALE) is which of the following?

A. The sum of the ARO and the SLE, which indicates the actual value of loss by combining the likelihood of a security event with the average cost of a security event

B. The sum of the ARO and the SLE, which indicates the likely loss for a specific year

C. The product of the ARO and the SLE, which indicates the likely loss for a specific year

D. The product of the ARO and the SLE, which indicates the actual value of loss by combining the likelihood of a security event with the average cost of a security event