Defining Risk

The definition of risk is stated as the probability or likelihood that a certain event or incident may occur that will have an adverse impact on an organization and the achievement of its mission or objectives. Since risk has been defined as a probability of something occurring, it may be represented by a mathematical function.

When information technology risk is defined, we are basically speaking of the unauthorized use, disruption, modification, exfiltration, copying, inspection, or destruction of information or information processing hardware or software assets. Company managers will use various tools such as risk analysis and risk assessments to analyze the potential risks that may impact organizational assets. There is no such thing as a risk-free environment, and there is no way to totally reduce risk to zero. The tools, devices, and techniques IT managers and security practitioner use are referred to as controls to reduce the level of risk. Residual risk is any risk remaining after the implementation of safeguards and controls. For instance, an asset valued at $100,000 may have a $100,000 insurance policy placed upon it. But that $100,000 insurance policy may have a $5,000 deductible, which is the amount an organization pays in the event of loss. Obviously, with a total loss, the insurance company would reimburse the organization $95,000. The residual risk would be the $5,000 deductible.

Risk Management Process

The risk management process is simply a business function that involves identifying, evaluating, and controlling risks (Figure 5.1). As you have seen, risks are prevalent throughout the organization. For example, a commercial market risk may occur when a competitor may lower its prices below what it costs another company to manufacture the same product. A major supplier may have a fire, thus eliminating a supply of raw material to the organization. A hurricane might cause the manufacturing facility to be closed down for an extended period of time. Each of these represents risks to the organization and must be addressed through the risk management process. For instance, in the example of the major supplier experiencing a fire, management would have recognized that nondelivery of production materials would pose a threat to the organization. During a risk analysis process, threats that might affect a major supplier would be identified. In the event such threats came to fruition, causing the supplier to not be able to supply raw materials, plans would be in place to purchase the raw materials through other suppliers. Although this ­scenario is simplistic in nature, it illustrates the process behind risk management.

The loss of information processing hardware, software, and information is a serious risk to any organization. Information risk management (IRM) is the process whereby risks to IT hardware, software, and information assets are identified and threats and vulnerabilities are reduced to an acceptable level and controls are implemented to maintain that level. At the heart of information risk management are decisions concerning priorities and monetary resources. The question for senior management is what assets to protect and how much to budget to protect it.

Several categories of risks to IT hardware, software, and information assets must be considered. The following are some of the categories that represent threat sources to an IT organization:

1. Weather Hurricanes, tornadoes, snowstorms, avalanches, floods, tsunamis, dry spells, and freezing temperatures
2. Utility and Services Disruptions of utilities and services such as water, electrical power, natural gas, telephone system, microwave communication, cellular communication
3. Human Activities Mistakes, neglect, sabotage, theft, vandalism, hacking, mischief
4. Business Process Equipment malfunction, supply-chain interruption, quality control ­problem, market pricing
5. Information Technology Equipment misuse, loss of information, damage or outage of IT equipment
6. Reputation Theft of customer information, release of trade secrets and proprietary ­processes, release of sensitive and confidential corporate information

The determination of risk requires the knowledge of various attributes that exist in every scenario where there is risk, as detailed in the following sections.

ISO/IEC 27005

The ISO/IEC 27000 series is a group of standards that offers guidance to IT security management organizations. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) have published an extensive series of best practices, recommendations, and guidelines. The ISO/IEC refers to its family of standards as an information security management system (ISMS). The most popular of the standards in the series is ISO/IEC 27002, which is a security code of practice and guidelines for IT security management. ISO/IEC 27005 offers a framework based upon a broad scope of various factors within the organization. This type of framework allows each organization to address the risks based upon their own ISMS. This framework covers such areas as the following:

• Information security risk assessment
• Information security risk treatment
• Information security risk acceptance
• Information security risk communication
• Information security risk monitoring and review

NIST Special Publication 800-37 Revision 1

While the ISO/IEC 27000 series has its foundations in establishing a structure of practices within an organization and then certifying and accrediting the organization for meeting established benchmarks, NIST Special Publication 800-37 Revision 1, “Guide for Applying the Risk Management Framework to Federal Information Systems,” was created to guide IT organizations within the U.S. federal government with a more practical approach to risk management. The National Institute of Standards and Technology (NIST) had its origination as the National Bureau of Standards and is a nonregulatory agency of the U.S. Department of Commerce. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems. Although the news bulletins and publications originated as guidelines for federal agencies, they are widely applied throughout private and public businesses and organizations.

There are a variety of terms associated with NIST publications:

1. FISMA The National Institute of Standards and Technology was given statutory responsibilities under the Federal Information Security Management Act (FISMA). Under the law, NIST is responsible for developing information security standards and guidelines. The determination as to which standards to mandate upon federal information systems under the law has been given to the secretary of commerce.
2. FIPSFederal Information Processing Standards (FIPS) are standards approved by the ­secretary of commerce as compulsory and binding standards for federal agencies.
3. Special PublicationsSpecial Publications (SP) are documents issued by NIST with ­recommendations and guidance for federal agencies. Only select Special Publications are mandated for compliance by federal agencies.

The risk management framework (RMF) that is detailed in NIST SP 800-37 Revision 1 offers a six-step process for implementing information security and risk management activities into a cohesive system development life cycle. The risk management methodology described by NIST and this Special Publication is composed of the following steps:

1. Step 1: Categorize The information system is examined to determine a category for the system. During this process, the information that the system processes, stores, and transmits is evaluated. This evaluation is used to determine the asset value and potential risks to the system.
2. Step 2: Select Baseline security controls are selected based on the category of the ­system. For example, a system that processes classified data must include a selection of controls that mitigate risks for federal information systems in that category. The baseline selection may then be ­augmented with additional controls, or existing controls may be modified or customized based on the needs of the organization.
3. Step 3: Implement In this step the selected security controls are installed and properly initiated throughout the system. The controls must be documented to show the implementation within the system and what category of risks they mitigate.
4. Step 4: Assess An assessment process is utilized to determine if the controls are installed and set up correctly, operating effectively, and meeting the risk mitigation requirements as established by the risk management plan for the system.
5. Step 5: Authorize Authorization occurs when an acceptable level of risk is achieved based upon the implementation of controls.
6. Step 6: Monitor This step involves the ongoing assessment of the baseline operation of a control and its risk mitigation effectiveness. This process also includes a change management process that documents not only changes to the control and the resulting impact analysis but also environmental changes throughout the system. Management reports also produces result of information system monitoring.

Simply put, a risk management framework is a continuous methodology of categorizing the system based upon a number of criteria and then implementing and monitoring various risk mitigation controls (Figure 5.2). This is referred to as a system security life cycle approach.

The categorization of the system can be quite extensive, requiring the determination of the system architecture.

1. System Architecture This may include the business processes, mission, architectural type or model, and boundaries between the system and other related systems.
2. Input Constraints This includes all of the items that must be considered, such as laws, policy, goals and objectives, availability, costs, and other input.

NIST Special Publication 800-39

NIST Special Publication 800-39, “Managing Information Security Risk: Organization, Mission, and Information System View” is a NIST document that concerns security risk in an IT environment. It was authored by the Information Technology Laboratory (ITL) at the National Institute of Standards and Technology, which provides technical leadership to the nation's measurement and standards infrastructure. ITL should not be confused with ITIL, which is the Information Technology Infrastructure Library, a six-book series of best practices for the IT services industry. ITL provides research, guidelines, and outreach efforts in information systems security for industry, government, and academic organizations.

NIST Special Publication 800-39 contains these major topics:

• Components of Risk Management
• Multi-tiered Risk Management
• Tier 1 – Organizational View
• Tier 2 – Mission/Business Process View
• Tier 3 – Information Systems
• Trust and Trustworthiness
• Organizational Culture
• Relationship among Key Risk Concepts

This publication offers a very good starting point to understanding risk and IT security.

Risk Analysis

Risk analysis is the method by which we identify and analyze risk. Risk analysis is performed by identifying potential threats and vulnerabilities to arrive at a risk determination. The application of numerical analytical techniques is employed to determine asset value and thereby arrive at the cost of controls required to reduce or mitigate the overall risk associated with the asset. There are two general methodologies used to analyze risk: quantitative and qualitative.

Risk Assessments

Risk assessments are the primary method used during effective risk management to implement risk reduction strategies. Because risk management is a continuous process throughout the System Development Lifecycle (SDLC), it is a process that can be used to identify, assess, and classify threats against the asset and determine the optimal mitigation technique or control to reduce risk. During this process, many operating parameters may be monitored and adjusted with the appropriate reports generated to facilitate management decision making.

Risk assessments build on risk analysis and incorporate the identification of specific risks, the likelihood of occurrence, the impact, and recommendations for controls. Even in small organizations, risk analysis and risk assessments require a substantial commitment of funds, personnel, and time. As might be expected, large organizations require teams to continuously perform risk assessments. In any organization, cost, time, and ease of use are primary concerns. Therefore, a proven framework may be adopted to provide efficient risk assessments.

NIST Special Publication 800-30 Revision 1, “Guide for Conducting Risk Assessments,” offers guidance for conducting risk assessments of federal information systems and organizations. The NIST Special Publication 800-30 Revision 1 publication has been adopted by a large number of organizations worldwide and forms the foundation of their risk management strategy.

The Special Publication outlines the risk assessment component of risk management and provides a step-by-step process on how to prepare for risk assessments, how to conduct risk assessments, how to communicate risk assessments to key organizational personnel, and how to maintain the risk assessments over time.

In the original version of NIST Special Publication 800-30, which is now retired, a nine-step risk assessment process was outlined in detail. It was designed to be similar to a project plan, using typical project management concepts, and each of the nine steps included an input, a process method, and an output. Although effective and comprehensive, it proved to be very bulky and detailed when applied to hundreds of assets. There was a requirement for simplification featuring both speed and adaptability.

In the most recent version, NIST Special Publication 800-30 Revision 1, the risk assessment process has been distilled down to four primary steps. All of the original nine steps are still included in the process. Figure 5.3 illustrates the four basic steps in the risk assessment process and the specific tasks for conducting the assessment.

1. Step 1: Preparing for the Risk Assessment The first step in the risk assessment process is to prepare for an assessment. The objective of this step is to provide a base framework of information concerning the risk goals of the organization, assessment methodologies to be used, and procedures for selecting risk factors and outlining various requirements, such as policies and regulations that impact the risk assessment. In preparation, there are five ­general categories of information that should be determined:
   • Identify the purpose of the assessment.
   • Identify the scope of the assessment.
   • Identify the assumptions and constraints associated with the assessment.
   • Identify the event information to be used as an input to the assessment.
   • Identify the risk model and analytical approaches.
2. Step 2: Conducting the Risk Assessment The second step in the risk assessment process is to conduct the assessment. The objective of this step is to come up with a list of risk information that includes resources and events and identifies vulnerabilities and the possible likelihood that a threat may exploit them. Organizations may apply their own criteria to prioritize the threats and vulnerabilities they wish to mitigate. In practice, keeping within available resources, many organizations generalize threat sources, events, and vulnerabilities only as necessary to accomplish the risk assessment objectives. Conducting risk assessments includes the following specific tasks:
   • Identify threat sources that are relevant to the organization.
   • Identify threat events that could be produced by those sources.
   • Identify vulnerabilities within the organization that could be exploited by a threat sources.
   • Determine the likelihood that an identified threat source would initiate specific threat events and the likelihood that a threat event would be successful.
   • Determine the adverse impact to the organizational operations and assets as a result of the exploitation of a vulnerability by a threat.
   • Determine the risk information based upon the combination of the likelihood of a threat exploitation of a vulnerability, the impact of such an exploitation of the organization, and any uncertainties associated with the risk determination.
3. Step 3: Communicating and Sharing Risk Assessment Information Decision-makers across the organization require the appropriate risk-related information to guide risk decisions. The third step in the risk assessment process is to communicate the results of risk assessments with managers and other individuals. Sharing information consists of the ­following specific steps:
   • Communicating the risk assessment results.
   • Sharing detailed information developed during the execution of the risk assessment to enable to make accurate management decisions concerning risk mitigation.
4. Step 4: Maintaining the Assessment In all organizations and enterprises, risk assessment, asset valuation, and threat and vulnerability identification is an ongoing process. The acquisition of new networking products, the requirements of new controls to mitigate risk, and changes to the system over time revealed by risk monitoring techniques, all contribute to changes to the overall risk landscape. The objective of this step is to keep the risk assessment current by noting and logging changes in risk knowledge as it occurs. This monitoring provides an organization with the ability to determine the effectiveness of risk controls, identify risk impacting changes, and verify that the systems and controls operate within established guidelines and baselines. In essence, the maintenance of the risk assessment verifies the compliance with the organization's risk strategy. Maintaining risk assessments includes the following specific tasks:
   • Monitor risk factors identified in risk assessments on an ongoing basis.
   • Update the assessment when new products or services are acquired, substantial organizational changes such as mergers and acquisitions occur, and the regulatory environment changes.

Treatment Plan

The treatment plan details how the organization plans to respond to potential risks. It ­outlines how risks are managed regardless of whether they are low, high, or acceptable risks and outlines preferred strategies for dealing with identified risks. Sometimes treatment plans are referred to as risk assessment plans, but in actuality, the treatment plan is the result of an assessment plan. The primary purpose of the risk treatment plan is to determine precisely who is responsible for the implementation of controls in what time frame and with what budget. It may also detail the response to an event or incident.

Risk Treatment

Once an organization identifies risks, it must choose from among several different strategies to deal with the risk. Risk treatment involves identifying a range of options for mitigating techniques that may be used to reduce risk. Risk treatment also refers to the overall process of prioritizing risks, evaluating various mitigation options by weighing their benefits and costs, preparing and implementing a risk reduction plan, and then monitoring the mitigation process.

The following risk response options are available for the treatment of risks:

Acceptance

1. When an organization acknowledges a risk and makes a conscious decision to just live with it, the organization is demonstrating risk acceptance. In the event of a total loss, the organization is willing to accept the cost of replacement. The decision to accept a risk may be the result of various situations or considerations:
   1. Cost The cost of a control can outweigh the damage if a threat situation is realized.
   2. Limited Damage Very little damage might occur if a threat situation is realized.
   3. Residual RiskResidual risk is risk remaining after a control has been put in place. For instance, an insurance policy may cover 100 percent loss of a $100,000 house and have a $2,000 deductible clause. In the event of a total loss, the residual risk would be $2,000.
2. Transference When the responsibility for the payment of loss is placed on a third party, it is called risk transference. In most instances, it would involve an insurance company. Transferring a risk may also involve an outside source that handles the risk and is responsible for various activities such as investigation, litigation, asset recovery, and claim processing. It's important to note that transferring risk does not mean the risk is going away. It just means that somebody other than the organization is responsible for payment. It is important to note that the ultimate responsibility still remains with the asset owner.
3. Reduction Risk reduction or mediation is the process whereby a control is put in place to reduce risk. Risks are always present, and no risk can be reduced to zero. Therefore, only the application of various controls will effectively reduce a risk to an acceptable level. As you have seen, controls can take many forms.

   The effect of risk may be addressed by reducing the possibility that a threat will exploit a vulnerability prior to the event being triggered, or it may be reduced through incident response activities that limit continuing damage after an event is triggered. Prior to an event, appropriate controls may be used to reduce the likelihood of an event being triggered. After an event, the appropriate testing taken by a damage control team or an incident response process can limit damage caused by the event.

4. Avoiding RiskRisk avoidance is to eliminate a risk situation. For instance, if you never climbed a ladder, you would never fall off. To avoid risks, you may identify them from prior experience and analyze what steps can be taken to eliminate a risk situation. There's a fine line between risk reduction and avoiding risk. For example, if you never wanted to have an auto accident on Elm Street, you could avoid the risk by always driving down Main Street. This helps to avoid the risk of having an accident on Elm Street, but in fact the risk of an accident still exists.

Risk Treatment Schedule

The risk treatment schedule documents the plan for implementing preferred risk mitigation strategies for dealing with identified risks. A risk treatment schedule is an output of the risk assessment phase. Risks have been identified, and various controls have been selected to reduce risk. The risk treatment schedule is a listing of risks in order of priorities. Figure 5.4 illustrates a typical risk treatment schedule.

Although each risk treatment plan can be customized specifically for an organization, at a minimum the plan should include the following sections:

1. Risk Identification Number For example, identified risks can be sequentially numbered in a hierarchy format such as 1.0, 2.0, and 3.0 as the main risks, with 1.1 as a sub-risk and 1.1.1 as an underlying risk under this risk.
2. Name of Risk Risks are listed in order of priority.
3. Risk Treatment Technique List techniques such as acceptance, avoidance, reduction, and transference.
4. Selected Control Include a list of controls selected to reduce the risk.
5. Risk Rating after Treatment Use high, medium, and low or a 1-to-10 risk rating scale.
6. Cost Benefit Analysis This is an optional analysis of the cost benefit of the control that mitigates risk.
7. Person Responsible for Implementation of the Control Usually listed by department and role.
8. Timetable for Implementation This is a date when the control will be fully operational.
9. Control Monitoring Method This is a description of how to monitor the control after it is in place. Baselines and standards to be used should be specified.
10. Incident Response A brief description of the intended response to an incident. This field may also refer to an incident response plan document.

Although the risk treatment schedule takes the form of a spreadsheet template, many of the fields are brief descriptions. The risk treatment plan should include full documentation supporting the identification of a risk during a risk assessment activity, an impact ­analysis, a control selection criteria, control baselines and standards, and an incident response document.

Risk Register

A risk register is a primary document used to maintain a record of risks. It is a direct ­output of the risk assessment process. A risk register includes a detailed description of each risk that is listed. Although the risk register may appear to overlap the risk treatment schedule, the two documents serve different purposes. The risk treatment plan should include complete documentation concerning the identification of threats and asset vulnerabilities. It also prioritizes risks so they can be addressed with available resources. The risk register might include the ­following fields or columns:

• Risk Identification Number
• Name of Risk
• Name or Title of Team Member Responsible for the Risk
• Initial Date Reported
• Last Updated
• Impact Rating
• Impact Description
• Probability of Occurrence
• Timeline for Mitigation
• Completed Actions
• Future Actions
• Risk Status

Other types of risk treatments exist that do not fall into the preceding categories. It is nearly impossible to predict all possible risks. In this case, the organization may acknowledge that other risks exist. If an unknown risk event is triggered and identified, it may be placed into an existing general response category. This type of response is called control and investigation. The damage is controlled by a general preplanned process, and then an investigation is launched as to the source of the threat, the scope of the attack, and the amount of damage caused.

For example, a network intrusion prevention system (IPS) could be attacked through an exploit of a previously unknown flaw in its operating system. This type of attack is called the zero-day attack because it is previously unknown to the manufacturer, and therefore no patches or mitigation techniques are known. The zero-day attack can exploit a vulnerability, allowing an attacker to place a Trojan on the network. The Trojan can enable its ­malware component to open a back door to a database application. Although the organization may not have listed this device as a possible risk in its risk register, it still may have taken action. The attack might immediately have been classified as an Internet intrusion, and an incident response team might immediately be called in to control any damage. After an event, an investigation should be undertaken to identify the specific attack.

Enterprise Risk Management

Enterprise risk management (ERM) is a program designed to change the risk culture from reactive to proactive and accurately forecast and mitigate the risk on any key programs. For ERM to be successful, it must be undertaken at an organizational level. This means that it must become part of the overall culture of the organization in order to identify and reduce risks on a proactive basis. To accomplish this task, senior management must decide to make the risk management program more visible throughout the organization.

Without access to comprehensive risk data, an organization may find it difficult to ­identify its outstanding risks and their probability of occurrence, causing forecasts to be less accurate. There may also be a disconnect between the information used by employees in the field and the information used by executive decision-makers.

An introduction of an enterprise risk management program may involve any of the following:

• Employee risk awareness workshops
• Risk identification across the organization
• Use of risk dashboards
• Incident reporting and incident response reports
• Implementation of an executive risk board or advisory committee
• Continuous monitoring of operational systems

An organization-wide ERM monitors the entire risk surface of an organization, which may include the monitoring of regulatory compliance, financial activities, and the physical attributes of the facilities as well as IT network risks. The ERM program is intended to raise the awareness of risks to the organization and enhance the reaction time to either mitigate the risk, thereby reducing the exposure, or react to the risk minimizing damage.

Continuous Monitoring

Managing the risk landscape involves many more actions than just identifying risks, establishing controls, and responding to problems. It involves a continuous monitoring requirement for the effective communication of the status of system internal controls, where threat events may be discovered immediately or as soon as possible after the incursion. Rapid identification of problems or weaknesses and quick response actions help to reduce the cost of possible risk events.

An ideal situation would be to continuously manage risk through real-time metrics. To perform this type of monitoring program, performance baselines must be established for all controls being monitored. These controls should trigger an alert in the event of state changes or even activities outside of normal operating parameters. The baselines must be monitored due to inevitable changes over time.

1. Passive Monitoring Passive monitoring is characterized by capturing traffic crossing a network or device, usually from a span port or mirror port on a switch or router directly or off the network using a network tap. Typically, the information is in the form of network traffic or packets and is recorded in log files for future review. Although the data is collected in real-time directly off the network, it is reviewed offline at a later time.

   The amount of data captured during passive monitoring can be substantial. Various software tools may be used on the data to search for anomalies. During the log review, various anomalies or activities are noted, requiring some procedure to be followed.

   During passive monitoring, logs are accumulated through various machines manually or routed to a monitoring console. The serious deficiency with passive monitoring in many organizations is that logs may not be examined on a timely basis. The passive monitoring activity is extremely helpful in device troubleshooting.

2. Active MonitoringActive monitoring is an approach in which special packets are introduced to the network in an effort to measure server and other device performance. It is ideal for the emulation of various scenarios and testing Quality of Service (QoS). System administrators utilize active monitoring to test the speed, accuracy, and statistical qualities of the overall network and various devices. On many occasions, these tests are required to meet various contractual compliance standards. Active monitoring is a test mechanism usually triggered by a system administrator or other individual in an effort to test a device for the entire network.
3. Real-Time Monitoring Real-time monitoring may also be referred to as automated ­monitoring. Various items such as network intrusion prevention systems (NIPSs) and other devices continuously monitor intrusions based upon a variety of signatures, behavioral characteristics, or heuristics. When intrusion is detected, the device immediately alerts the operator of an event. If the event is determined to be an intrusion, it then becomes labeled as an incident.

   Depending upon established procedures and protocol for a designated type of intrusion, the Computer Emergency Response Team (CERT) may be required to perform necessary activities. The difference between real-time monitoring and active monitoring is that real-time monitoring is continuously listening to the traffic on the network and automatically ­sending alerts based upon some criteria.

   Even with real-time monitoring, human response may not be sufficient. Various devices such as a network intrusion prevention systems may discover an intrusion and immediately trigger an action, such as modifying a firewall rule that closes a port or blocks an IP address. This automatic response would be much more timely and efficient than a human response.

4. Security Information and Event Management (SIEM) Security Information and Event Management (SIEM) software products are combined with hardware monitoring devices to provide real-time analysis of security alerts. In many cases, SIEM devices are sold as hardware units that monitor the network and devices on the network while aggregating data from all the various logs. Once the data is accumulated, the device correlates it. Through automated analysis, the data is turned into useful information.

   If an anomaly is located, operators are alerted based upon the severity of the intrusion. For instance, operators may be notified to mediate issues by special screens that appear on their consoles. These devices may also be configured to alert administrators by telephone or pager. Less severe intrusions for anomalies can be displayed on dashboards or in various reports.

Security Operations Center

Many organizations employ an in-house or a third-party security operations center (SOC) to monitor the physical perimeter, CCTV cameras, and facility access (Figure 5.5). An information security operations center (ISOC) primarily monitors the organization's applications, databases, websites, servers, and networks. The ISOC provides real-time ­situational awareness and is a primary center for network defense.

Many security practitioners are initially employed in an ISOC that provides an excellent opportunity to learn about the network and the business of the organization. The ISOC staff includes security engineers, system administrators, and other IT personnel and network professionals that have certifications such as the (ISC)² Certified Information System Security Professional (CISSP).

Real-time security operations are sometimes outsourced by service providers that provide managed services to monitor the client's network on a 24/7 basis. This is ideal for both the small to medium-sized organizations as well as organizations that have numerous branch offices or facilities.

Threat Intelligence

Time is of the essence in the world of cybersecurity. On the other end of the spectrum, organizational resources such as personnel, money, hardware infrastructure, and necessary skill sets are scarce. Threat intelligence is a method by which the organization has up-to-the-minute information concerning zero-day attacks, threat profiles, malware signatures, and other vital pieces of information required to protect the organization's resources.

The sharing of cyber threat information and threat intelligence has been strained at best. It does make sense, however, that if one company is attacked, other companies might want to know so that they can protect their own assets. The problem has been with current laws. The sharing of information between companies in the same industry may appear to be in violation of Security and Exchange Commission regulations. Many are concerned that sharing specific threat intelligence with the government may violate privacy laws and regulations.

Various laws proposed in the U.S. Congress have failed on a number of counts. Unfortunately, although logic dictates the wisdom of sharing information, the business sector's fear of sharing information with the government is based on distrust due to the possible opening of a door that would allow the government to use data that is acquired in a surveillance program. While generally private-sector organizations agree that attack information should be readily shared, the disagreement is with proprietary data such as customer lists and personally identifiable information.

A way around the current legal hurdles and legislation or lack thereof is by using a shared central proprietary attack database. Appliances are currently on the market that identify zero-day attacks or other anomalies and immediately upload the data to a proprietary database. Other appliances from the same company can access the database and immediately protect their user networks from the identified attack. Using this technique, only the intrusion data is shared while the end users remain anonymous. This may become an extremely viable method for participating organizations to share attack information as soon as it's available.

Security Analytics, Metrics, and Trends

As a security practitioner, you will undoubtedly be involved with monitoring the security aspects of networks and network-connected devices. This is different than the device monitoring discussed earlier. Device monitoring is a method of gauging the health of a device and the health of the network. During security device monitoring, various alerts will be generated based upon established templates or parameters of a network device.

There's a wide range of log files that track various events on the network. Servers and devices record a wide range of items in logs sometimes called syslogs. In practice, syslogs are used to gather information, usually in a database that may contain data aggregated from many different types of systems. The messages maintained in a syslog can be customized through templates to indicate facility level, location, type of activity, and the severity of the alert (such as emergency, critical, or error warning). The type of message the program is logging is indicated by the facility level. Various applications across the organization may have different facility level codes. Of importance to the security practitioner will be the levels of message severity. There are eight severity levels:

1. Code 0 Emergency This is the highest alert, possibly affecting major sections of the network or applications.
2. Code 1 Alert This indicates a major problem, such as the loss of a central application or communication method.
3. Code 2 Critical This represents the loss of a backup or secondary device.
4. Code 3 Error When detected, this means that the failure of an application or system was not critical in nature.
5. Code 4 Warning Warnings are usually set to indicate that a threshold is near. For instance, server utilization is at 90 percent.
6. Code 5 Notice These messages indicate potential problems that should be investigated.
7. Code 6 Information These are status messages and no action is usually required.
8. Code 7 Debug Debug messages are utilized by developers and programmers.

Event Data Analysis

Event data analysis is the process of taking raw data from numerous sources, assimilating and processing it, and presenting the result in a way that can be easily interpreted and acted upon. While the science of mathematical data analysis is quite extensive, the security practitioner should understand the sources of the data and what the data represents.

For many years, dashboards have been used to represent the correlation of data from numerous sources. At a glance, practitioners, analysts, administrators, and executives have been able to absorb large amounts of data when represented as a digital numerical display, dial with a pointer needle, bar chart, pie chart, or some other visual display technique. Microsoft products, such as Microsoft Excel, offer excellent capability to display graphs and dashboards of complex data. Excel tools such as those for formatting content, conditional formatting, pivot tables, and advanced data filtering have been used in IT data analysis.

Many vendors offer specialized tools that can be used to filter log files, memory dumps, packet captures, and other sources of raw IT event data. In many cases, data templates are used or modified to select the specific event data of interest. For example, log data or packet captures can be analyzed to identify the IP source of specific traffic. Large amounts of data over a period of time can be quickly analyzed to determine various factors such as frequency, length of visit, actions taken or data accessed, and other valuable information that can be used during investigation.

Visualization

Visualization is a technique of representing complex data in a visual form rather than a tabular form such as a list. Even simple network diagrams can be extremely complex and hard to understand. Visualization takes advantage of the human brain's capability of learning and processing complex information based upon visual input. It has been proven that the brain will notice intricacies and details all at once. This allows us to analyze and absorb vast quantities of abstract information at the same time. Prior to graphic visualization, flow charts, graphs, diagrams, and other techniques were used to depict the relationship between items on a network. As networks became much more advanced and complex, paper-based graphing techniques became inefficient.

Information visualization and IT network design is an emerging field of information communication. Data analysis is indispensable when diagnosing problems facing large data communication networks. By viewing the entire network as a spatial diagram of connected nodes and network devices, the analyst can easily visualize large amounts of information and apply reason and insight rather than analytical skills in deciphering information. Many vendors supply visualization software that will map entire networks and allow the user to zoom out or zoom in to comprehend the amount of information they desire. Future iterations of visualization software will be able to display problems and recommend solutions graphically.

In the past, IT network information has been represented by various methods, including nodes illustrated as hanging off of a central bus, host workstations and servers as circles network designs, tree diagrams for Ethernet networks, and clouds representing the Internet or other mass communication technology. Figure 5.6 represents a data visualization of a large ­network. Major work centers are represented by the larger circles. Work groups of satellite offices are represented by smaller circles in groups, and finally individual nodes are represented by single circles.

Communicating Findings

The results of data analysis van be communicated using a number of methods. The ­decision as to the medium or media to be used to convey the information is directly related to the speed of the communication. For example, displaying data on a computer screen is much faster than printing out a pile of paper. Also, utilizing a dashboard to quickly visualize data is much faster than analyzing a spreadsheet with columns of information.

Various roles within the organization require data to make informed decisions. Each of these roles generally requires the data in which they are specifically interested. Data should be presented in a manner that is actionable by the individual receiving the communication. The following roles might be receiving and acting upon data:

1. Security Practitioner Data concerning device error situations, misconfigurations, tasks to be performed, and assignments based upon network conditions
2. Database Administrator/Server Administrator Data concerning software or device performance, intrusions, penetrations, error conditions, and malfunctions
3. Network Administrators Performance reports, reliability, traffic flow, quality of service, security situations
4. Executives Operational summaries, executive reports, compliance reports