Service Management Functions: Security Management (Part 1)

by Microsoft [Published on 9 March 2005 / Last Updated on 23 Jan. 2013]

The business world is increasingly reliant on technology to supply information and communications facilities to staff, partners, and customers. Securing organizational information and the systems that are used to manage and transmit data has become a high profile function. Failure to secure information can have a severe impact on business credibility.

Please read Service Management Functions: Security Management (Part 2).

For the latest information, please see

On this page

Executive Summary  

The business world is increasingly reliant on technology to supply information and communications facilities to staff, partners, and customers. Securing organizational information and the systems that are used to manage and transmit data has become a high profile function. Failure to secure information can have a severe impact on business credibility.

Threats to an organization come in a variety of forms, for example from hacking, viruses, and simple human error. The types of threats change constantly, so management must sponsor, design, and implement business and technical processes to safeguard critical business assets. To create a more secure business environment the organization must:

  • Assess business exposure and identify which assets to secure.
  • Identify ways to reduce risk to an acceptable level.
  • Design a plan for mitigating security risks.
  • Monitor the efficiency of security mechanisms.
  • Re-evaluate effectiveness and security requirements regularly.

All of these activities must be coordinated within a well-defined strategy. An organization can manage risk to an acceptable level by developing security policies and making staff and commercial partners aware of their responsibilities within them. Security can also contribute to an organization’s bottom line, because customers value the reliability of a supplier.

This Security Management service management function (SMF) guides organization leaders and senior managers through issues that they should consider when developing an effective security policy and implementing it through a security program. The SMF discusses the individual and team security roles and their interrelationship with operational functions. The SMF also reviews tactics and best practices to increase staff awareness and encourage continuous improvement.

Security management is only one aspect of providing information technology (IT) services to an organization. This SMF works within the wider Microsoft Operations Framework (MOF) to align defense with other critical services, such as Business Continuity Management and Change Management. The Security Management SMF also relates to industry security standards and initiatives, such as the International Standards Organization (ISO) 17799:2000 and the IT Infrastructure Library (ITIL) Best Practice in Security Management.


This service management function (SMF) provides information about security management for organizations that have deployed, or are considering deploying, Microsoft or other technologies in a data center or other enterprise-level computing environment. The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of the Microsoft Operations Framework (MOF) and the Microsoft technologies that this SMF discusses.

You can find detailed information about the concepts and principles of MOF on the MOF Executive Overview v3.0 site that is available at
. An overview of all of the MOF SMF guides is available on the Service Management Functions Introduction site at


This SMF provides security management information for a broad range of business and technical roles within an organization. It offers business executives and managers a basic understanding of the reasons for developing a security program. It also provides detailed information for those individuals who are responsible for designing and managing the implementation of security policies.

Organization Leaders

The term "organization leader" applies to those roles at the highest level of influence within an organization. In many organizations, these roles might include one or more chief officers (Executive, Operations, Information, Technology, and others). Organization leaders specifically:

  • Sponsor security.
  • Establish commercial criteria for security.
  • Drive the high-level adoption of security policies across the organization.

The areas in this SMF that are of particular use to organization leaders are the explanations of the language of security, the planning necessary for an effective security program, and the means of communicating security policies throughout an organization.

Operation and Service Managers

Managers in these roles are primarily concerned with using information technology (IT) to deliver valuable business services. Securing these services means that developing and maintaining effective processes and procedures that support the aims and objectives of the organization are essential. Common goals for those people who are working in these positions include:

  • Service efficiency.
  • Service quality.
  • Service availability.
  • Quality user experience.
  • Service improvements.
  • Maintenance of data confidentiality, integrity, and availability.

This SMF benefits operation and service managers through a descriptive narrative that provides insights into the objectives that drive management processes that security policy governs. Management involvement prompts staff in a division or department to resolve security issues within each phase of operations. Security must be an organizational requirement that does not become a roadblock to success.

Security Managers

Security managers are responsible for the assessment, resolution, and maintenance of effective security requirements within the organization. As such, this role has senior management responsibility. The security manager leads the organization in developing effective strategies for:

  • Identifying the most important requirements in developing a secure environment.
  • Identifying the types of data in the organization and the level of security required to protect this data.
  • Identifying and documenting business-focused security rules.
  • Identifying security issues and managing identified risks.
  • Responding to security incidents.

This SMF provides detailed information on the strategic and tactical processes that security managers must consider when developing an ongoing security management program.

Security Administrators

Security administrators are responsible for the ongoing management of security infrastructure within the organization. When the organizational policy has been defined and the security mechanisms identified, security administrators will:

  • Establish the detailed configuration of security solutions.
  • Deploy the security solutions, managing the provision of access to staff within the organization.
  • Maintain the delivery of the security solutions.
  • Monitor the components and the overall security implementation.
  • Evaluate potential security problems that may occur on a system.
  • Report on security issues that occur.

This SMF gives high-level information on the administration functions, providing a framework within which specific security products are implemented.

Business Managers

Business managers own the information assets within an organization. To support senior business decision makers and advise IT personnel on the information requirements of the business, these managers must understand the role that security plays in protecting information assets. Business managers must:

  • Understand the issues surrounding the securing of business information.
  • Help identify the importance of information assets to their divisions or departments.
  • Take an active role in the development of an effective security framework to improve business efficiency.

This SMF explains the requirements of security for commercial and business effectiveness, which business managers will have a particular interest in.


Please direct questions or comments about this SMF guide to

Security Management SMF Overview  

This section provides you with important background information on the remainder of the service management function (SMF) guide.

Goals and Objectives

This SMF guide describes security management processes within the Optimizing Quadrant of the Microsoft Operations Framework (MOF). This SMF is not a traditional security plan or a security plan outline. Instead, it is a series of processes used for security planning and management in an organization. The overall objective of the SMF is to describe “what” to do rather than “how” to do it. This is an important distinction to remember while reading this SMF.

The process flows defined within the Security Management SMF affect the management of security interests in terms of the confidentiality, integrity, and availability of all information technology (IT) systems, in addition to the data that is stored on or that traverses these systems. The processes manage the risks confronting an organization that uses IT systems. For this SMF guide, security management includes risk management.

The Security Management SMF is a practical support document for business and IT professionals who are working to develop security management policies based on industry best practices. The primary goals and objectives of the Security Management SMF are to:

  • Introduce security controls and explain the reasons for using them.
  • Provide security management process flows within the Optimizing Quadrant of MOF.
  • Describe best practice activities and processes for developing a security program.
  • Develop a security management program by establishing:
    • Rules for securing data.
    • Processes for assessing and managing security risks.
    • Processes for security monitoring and security auditing controls.
    • Processes for handling security issues when they occur.
  • Establish key performance indicators and identify assessment methodologies to measure them.
  • Relate the Microsoft security management principles to allied industry initiatives and other Microsoft SMFs.


Given that security is such a vast and complex subject, this SMF does not cover all information security topics in detail. Instead, it focuses on high-level recommendations for securing information that either is stored on or traverses computer systems. For example, this SMF discusses security controls that are required when you send sensitive data outside of a trusted network. The SMF does not consider mandates for conversations about the same sensitive information.

The following elements are within the scope of this SMF:

  • Developing security leadership and methods of assessing security risks within the overall enterprise security blueprint
  • Identifying strategic and tactical components (policy and plans, respectively)
  • Providing a strategic review of developing a multi-level approach to securing the environment
  • Providing security management process flows that affect the management of security interests in terms of the confidentiality, integrity, and availability of all IT systems
  • Identifying options for reducing data security risks within an organization
  • Providing high-level recommendations on securing information
  • Developing an asset classification scheme
  • Providing details on establishing a program for security monitoring, security auditing, and reporting

The following elements are outside the scope of this SMF:

  • Calculating the probability and impact of risks, because the Security Risk Management Guide, available at, covers this in detail
  • Identifying and valuing assets, because the Security Risk Management Guide discusses this
  • Assessing vulnerabilities, because the Security Risk Management Guide discusses this
  • Specifying regulatory compliance, because this guide covers generic security compliance best practices and not geopolitical specific requirements
  • Specifying physical security and personal safety policies, because the focus of this document is IT operations security management
  • Providing a detailed discussion of risk assessment and management, because the Security Risk Management Guide discusses this
  • Defining specific events to monitor
  • Providing a detailed discussion of the elements of a defense-in-depth security policy

Key Definitions

This document is also a reference source. An understanding of the following key terms will help clarify the materials. Some of these terms have more than one meaning; within the IT profession there is disagreement about the definitive meaning of some of these terms. The intention is not to provide an official definition but rather to define the use of these terms within this SMF.

Security Program

Security program is a collective term for the implementation of the integrated components that relate to the conception, design, deployment, and maintenance of organizational security. The program incorporates the elements described in this SMF, including:

  • Policies.
  • Awareness programs.
  • Security risk management processes.
  • Asset classification.
  • Security monitoring and security auditing.
  • Incident response.
  • Key performance indicators.


In this SMF, the terms control and controls describe a variety of processes, procedures, or tools for reducing risk to an acceptable level. When a risk is identified, the organization must assess its potential impact, prioritize its importance, identify the options for managing the risk, and assess the business value of introducing a mitigating control. Specifically, controls are security tools, programs, policies, restrictions, and other methods used to mitigate identified risks.

Examples of controls include such elements as:

  • Documented processes and procedures to manage security incidents.
  • An intrusion prevention system.
  • The configuration of security options and settings for systems or applications.

A firewall is an example of an intrusion prevention system. After identifying and assessing the risk associated with unauthorized external access to an internal network, a technician can configure a firewall to segregate one portion of a network from another, allowing only authorized network traffic to pass through according to traffic filtering rules.

The configuration of security settings can make an environment more secure by limiting the authority of users to access systems, or by enforcing a security policy that forbids or restricts user activity.


The terms organization and organizations represent a logical or physical grouping of people. These groupings include businesses, corporations, agencies, companies, and conglomerates.


The terms policy and policies represent a variety of written sources that direct security practices within an organization. Policies are statements that reflect an organization’s attitude toward security and how it affects the organization, or that detail specific security issues. Policies are usually broad statements that cover general security concerns.

A policy represents the organization’s directives on recommended and acceptable practices for ensuring the security of information. Policies are usually high-level descriptions that do not change frequently. Standards and guidelines define what the benchmarks are, whereas procedures generally provide prescriptive guidance. Procedures can be step-by-step instructions and are likely to change more frequently than policies.

Examples of policies include:

  • E-mail security, outlining the rules governing a secure e-mail environment for users and administrators of the service.
  • Network security, identifying directives for securing network access and standards of network usage.
  • System security, dictating the requirements for operational security, such as virus management.


The term risk refers to the probability of an event occurring, and its consequences. (In the context of this SMF, the event would be a security issue.) Risks can be assessed using quantitative or qualitative measures. The process of assessing a risk identifies the risk and its impact on an organization or group. An organization can manage risk by determining an acceptable level of risk, assessing the current level of risk, taking steps to reduce the risk to the acceptable level, and maintaining that level of risk.


Stakeholders commonly are individuals and groups who work in an organization and have an interest in how security affects the operational environment. Stakeholders might also be external to an organization, for example customers and business partners. It is important to identify and involve the stakeholders when planning, implementing, and monitoring security projects.

Stakeholders have a major interest in an issue, project, or process and are often managers whose responsibilities include process and system management. A stakeholder can be someone who has authority to make decisions that affect a system. By identifying the stakeholders for a given issue, project, or process, it is possible to ensure that business and technical decision makers are involved.


The terms system and systems refer to all computers, networks, and devices that receive, manipulate, store, or transfer data. Commonly, a system includes physical hardware and system software—operating system or applications—and business information.


The terms trust, trusts, trusted, or trusting refer to the level of confidence shared between two entities performing a task or activity at an expected level. Entities can include organizations, computers, people, or networks. Trust can be permissive or restrictive depending on the amount of risk that the organization and the entities involved accept.

Security Monitoring

The term security monitoring describes the process of continual review of security controls. The primary function of monitoring is to identify atypical security activity within systems. A security program must mandate the administration of all of these components. Security monitoring can be automated, using hardware or software tools, or manual, using process-driven schedules.

Security Auditing

The term security auditing describes discrete assessments of all or part of the security infrastructure to ensure compliance with security policies. Staff from outside the security administration or security operations functions commonly undertake audits. The auditors may be security specialists from outside the organization. The primary function of an audit is to develop a holistic assessment of the security of an area, report findings, and make recommendations on security improvements.

Exposures, Threats, and Vulnerabilities

There are a number of terms used to express the dangers associated with a failure in data security. The following list, although not exhaustive, defines the terms that this SMF uses to describe these dangers:

  • Exposure. A threat action whereby sensitive data is directly released to an unauthorized entity. The Microsoft security risk management process narrows this definition to focus on the extent of damage to a business asset.
  • Threat. A potential cause of an unwanted impact to a system or organization.
  • Vulnerability. Any weakness, administrative process, act, or physical exposure that makes an information asset susceptible to exploit by a threat.

Defining Security Management

Information is a critical resource for organizations because it supports commerce and enables business managers and staff to make informed and effective decisions. It is essential to protect such a valuable resource so that it remains accurate and available to those who have the authority to use it. Today, computer systems hold the vast majority of business information. It is incumbent on business leaders, managers, and staff to maintain information security.

Security Management Processes

Security management, as discussed within this SMF, develops the framework to maintain computerized information and achieve the business-defined service levels that are necessary for commerce to occur. Security management comprises four key processes:

  • Establishing and maintaining an organizational security policy
  • Establishing and maintaining a security risk management process
  • Establishing and maintaining security monitoring and security auditing processes
  • Establishing and maintaining an incident response process

Security Fundamentals

Security objectives fit into three functional categories:

  • Confidentiality
  • Integrity
  • Availability

Data is not secure if it is:

  • Disclosed to unauthorized users.
  • Corrupted.
  • Unavailable to authorized users.

If a policy item does not fit into one of these three functional categories, it is probably not a security concern.


The goal of confidentiality is to protect data from unauthorized monitoring. The idea is that only specific parties may access certain data.

Many security plans include statements such as, "All data must be kept absolutely secure." This is usually impossible. If you have absolute security, your solution becomes unusable. Confidentiality must always be stated within a given scope or context, such as "Data classified as confidential must not be accessible by individuals outside the organization without explicit written permission of the data owner." This statement is more specific, clearer, and easier to enact. Examples of methods to maintain confidentiality include:

  • Financial information. Within an accounts department, it is essential to protect financial information from unauthorized access. Password or biometric access authentication ensures that only authorized users can access confidential information.
  • Data transmission. Organizations can use key-based cryptography to transmit information across internal or external computer networks. The data is secure from unauthorized viewing because only authorized entities hold the decryption key for the information.

Often, confidentiality requires the use of underlying technologies that implement authentication and authorization. These technologies are frequently dependencies for the solution.


Integrity refers to the trustworthiness of data. Security solutions have to ensure that the data provided to users is trustworthy. In a number of situations, confidentiality measures can provide data integrity. Integrity is a broad requirement for a wide number of business activities. Examples of integrity issues include:

  • E-commerce. An individual or a business wants to establish two-way certainty of identity before transacting business. For example, an individual wants to know that he or she is providing credit card details to the correct vendor. Similarly, businesses must ensure that they receive commercial orders from authorized sources.
  • Information change. Changes to information can be an issue, for example, when a report or financial information is altered so that it is no longer valid or correct.

By establishing a policy that documents provable criteria for authorizing information transfer or change, it is possible to mitigate many security attacks. The most common technology-based devices for ensuring integrity are hashing or using digital signatures. Digital signatures can provide a high level of assurance that data has not been altered since it was signed. Use of secure devices for access, such as passwords, digital certificates, or smart cards, can provide an increased level of confidence in terms of the reliability of business information.


Information availability is a frequently overlooked security goal. Keeping data available is essential when designing a security policy. For example, if all data in a security solution is kept confidential and has to retain complete proof of integrity, data access will be slower or more cumbersome. This adversely affects the overall usefulness of the solution.

Common availability-based solutions include regular backups, highly available systems, and redundant data storage. These solutions are included in a business continuity plan, a discussion of which is outside the scope of this SMF but can be found in other SMFs including the Availability Management SMF, available at
, and the IT Service Continuity Management SMF, available at
. However, discussions of some specific elements of a business continuity plan are within scope, such as incident response.

Examples of availability failures related to security might include:

  • Denial of service attack. A computerized assault that seeks to disrupt Web access, most commonly by overwhelming an Internet server with so many connection requests that the attacked Web site is unavailable to legitimate users.
  • E-mail worm. A computer virus resends e-mail in high volumes, which overloads the receiving e-mail systems with unnecessary traffic.

Security policies that cover the control of access to systems, through access flow control or virus detection, can mitigate such availability issues.

Understanding Controls

Controls are mechanisms—either computer-based or procedure-based—that limit exposure to vulnerabilities and threats. There is an enormous range of potential controls that can mitigate security issues. It is essential for security policy designers to understand that it is important to:

  • Implement security controls in response to a perceived and assessed risk.
  • Implement security controls at a number of levels to reduce risk from evolving threats.
  • Monitor all security controls by security audit and review to maintain their effectiveness.

Types of Controls

There are several different types of controls that can reduce risk:

  • Administrative controls
  • Physical controls
  • Technical controls

Administrative Controls

Administrative controls are items like policies, standards, and procedures that set the principles and directives that provide a secure environment. These controls are subject to rigorous assessment in the same way that technical controls are subject to scrutiny. The administrative controls establish the framework for implementing and managing physical and technical controls and define the limits for physical or technical controls.

Physical Controls

Physical security, although not within the scope of this SMF, is an important feature of overall organizational security. Locked doors and restricted locations are an important part of any thorough security program. To achieve a layered defense strategy, physical controls must include secure facilities and equipment.

Technical Controls

Technical controls include the hardware and software devices that protect systems and data. The use of technology is paramount when developing a secure environment that can be readily adapted to changing threats. It is important that security be able to anticipate that threats change. Regular audit of technical controls identifies any circumvention of controls or any ploy to hide an attack from automatic scanning tools. An obvious example is the requirement to keep virus-scanning signatures up-to-date, because an out-of-date virus control may simply not recognize that a virus has infected the host system.

Control Functions

Just as there are different types of controls, the controls that implement a secure environment have different functions. Security controls usually have a primary function that falls into one of the following categories:

  • Protect
  • Detect
  • Defend
  • Recover
  • Manage

Securing data with controls that provide multiple functions increases defense against a particular threat.


From the installation or initial configuration stage, the protection group of controls implements security policy. The security policy specifies protection methods and levels, which is the result of a thorough risk analysis. Protection prevents a security event from occurring at all.

Examples of protection include closing ports on routers, setting access control lists (ACLs) on files, and installing virus-scanning software. These are all preventative measures that try to stop an attack before it achieves its goal.


The purpose of the detection function is to identify security breaches. Technology-based security specifically configures security monitoring and intrusion detection systems to look for attack patterns. A detection system alert must trigger a documented response.


Defense is the response to an alert or the detection an attack. A defense response requires that the security policies anticipate what should happen when an attack has breached preventative controls. Defensive controls include active defenses, such as intrusion prevention systems that will actively block attacks that are occurring, and administrative defenses, such as written security policies that activate defense processes.

For example, an Internet-based attack against a protected network asset might terminate the Internet connection to stop the attack. Alternatively, the attack may activate an audit procedure to trace the attack back to its originator for prosecution.


Businesses must be resilient to attacks. Recovery is usually a two-step process: the immediate closing of security holes, and long-term attack analysis that may result in changes to security policy.

Expanding on the previous example, if an organization defends itself against an Internet-based attack by cutting its Internet connection, recovery is obviously mandatory. The immediate steps may be to block the port used for the attack and block all incoming traffic from the attacker's Internet Protocol (IP) address. Next, the organization must conduct a thorough analysis of logs and network traffic to determine exactly how the attacker accessed the system, identify the affected assets, and establish whether the attack was successful. From there, the organization can implement changes, such as to deny unsolicited incoming network traffic and to move sensitive data to well-protected servers.


Some controls maintain the stability of the asset in question. Improper asset management can offer vulnerabilities that an attacker can exploit.

Managing assets and the controls that defend them is a broad discipline. It includes not only maintenance tasks, such as developing a backup and restore methodology, but also pre-emptive tasks, such as installing operating system updates. Management of the end-to-end process is required to ensure an adequate level of risk mitigation. Documented management procedures ensure that the appropriate roles receive the information they require.

Control Functions Example

Planning an antivirus policy provides a good example of the control functions.


The policy prescribes an antivirus software control. Each host has the antivirus software installed with the most current virus signature file.


The antivirus software monitors for virus signatures and, on detection of a virus signature, sends an alert to the user and the system administrator. Examination of security logs reveals patterns associated with viruses or worms.


The antivirus software quarantines any files suspected of containing viruses. Administrative procedures prescribe that a user should disconnect from the organization’s network.


Procedures define the actions taken to remove the virus from the infected host and restore corrupted files, if required.


Management of the antivirus software ensures that virus signatures installed are up-to-date. A regular backup of organization data ensures a level of data protection even if an attack does succeed. The organization undertakes procedures to test backup validity and evaluate software patches.


Defense-in-depth is a security strategy that focuses on the effective implementation of security controls. Organizations use this strategy to examine and categorize risks and to apply layers of defenses. Defense-in-depth provides a framework to apply a combination of people, process, or technology at each "layer" of an enterprise to prevent a certain threat. This methodology provides a way to reduce risks with overlapping controls to prevent a particular threat. Security professionals must consider multiple defensive layers when examining a risk and determining the appropriate mitigation plan.

Figure 1: Defense-in-depth

Protecting the Perimeter

The network perimeter encompasses every point at which the internal network connects to external networks and hosts that the organization’s IT team does not manage. This includes connections to the Internet, business partners, virtual private networks (VPNs), and dial-up connections. Today, most computers connect to other computers through some type of networking. These connections are potential points of attack. Attacks range from eavesdropping (in which the attacker listens to network communications) to infiltration (in which the attacker directly compromises computers on the network). In addition, worms (self-replicating viruses) often take advantage of network connectivity to enable them to attack systems. Perimeter security often integrates with physical security, because a combination of physical prevention and perimeter protection most effectively secures a network against attackers.

Protecting the Internal Network

Defending the network is a well-explored topic. Many technologies and approaches exist that protect against network-based attacks, such as WiFi Protected Access (WPA), Internet Protocol security (IPsec), and network segmentation. The organization's connection to the Internet network is a critical source for security attacks. A robust secure-network perimeter design and implementation is essential.

Protecting the Host

Any network-based computer system is a host, and each host must have a level of protection against attack. Protection helps ensure that even if a virus gets through other security layers, the host can control the infection before it affects an asset. Two common examples of host-based defense are virus scanners and firewall software. Controls that fall into this category may also include additional security settings, reduction of attack surfaces, or restricting the ports and protocols that a system uses.

Protecting the Application

Each application that runs on a host must provide some integral security. Applications that are not designed to be resistant to attack can be compromised and used to attack other assets.

Related to applications are IT services. An IT service is the set of functions that a computer system provides. These services might be obvious, such as making business data and e-mail available or invisible to the user, for example, Dynamic Host Configuration Protocol (DHCP) IP addressing provision. While data exists on a DHCP server, the most important function is the service that the system provides to users.

Software Development

In-house software development must offer the same robust security as that which packaged application software provides. A well-structured development lifecycle is essential for all program development. From the initial phase of establishing the business requirements through to a rigorous and systematic testing and fully-documented release management processes, it is critical that functionality and security are built in.

The security architecture of software design is equally important. Development using the Microsoft® .NET Framework uses evidence-based security, so signed code shows where software functions originate. For example, if a component originates outside the host system, from elsewhere on a network or even from the Internet, the Common Language Runtime (CLR) will limit the functions that it can execute. For example, only locally installed code, which is under the control of organizational release and change management functions, can write a file to disk.

Protecting the Data

The majority of security effort focuses on protecting organizational data. Examples of data that an organization might consider worthy of defending include customer account databases, files with sensitive information, and e-mail. Security policies and controls must differentiate between computer systems and data. Ensuring that a computer system is secure does not necessarily mean that the data on that system is secure. The hardware, applications, and operating system software can be far easier to replace than company information.

There are numerous data protection technologies and techniques available. Technologies, including Encrypting File System (EFS) and ACLs, provide defense for files stored on hard disks. Other types of data defense include hard disk wiping and storing sensitive files on portable media. There are also application-specific data protection methods, such as protecting Microsoft Outlook® (.pst) data files.

Physical Defense

Physical security is the foundation for all security layers discussed previously in this SMF. This component of defense represents the actual physical access to objects, such as computers, networks, and all assets. A lack of physical security can allow an attacker to bypass nearly any other control that is in place.

Examples of physical security include prevention of direct access to servers or network ports. In addition, software can often have physical security requirements.

Policies, Procedures, and Awareness

To implement a security program successfully, an organization must define processes and activities for staff and systems. These policies and procedures define security controls and usage of the controls. An awareness program enhances staff understanding of the security controls. The policies and procedures define and describe all the controls at the physical, perimeter, network, host, application, and data layers.

A number of documents may be included within an organizational security policy. Irrespective of the title given to the documents within a hierarchy, there are functions that the security policy documentation must cover. These include:

  • Defining "information security" for the organization, and establishing its scope and importance.
  • Stating what the organization business leaders want to achieve, including goals and overall measures for security.
  • Delivering a concise explanation of the business reasons for implementing a secure environment, such as legislative or contractual compliance.
  • Positioning security within other IT service functions, such as business continuity management.
  • Setting expectations of security compliance, general standards for security management, and security policy violation.
  • Organizing the hierarchy of related security management documents, such as standards and procedures.
  • Developing an awareness program.

As an organization begins to assess the different ways to mitigate a given threat, it can use this model to evaluate several options. Instead of implementing a single control to prevent a threat, the organization might want to implement multiple controls at different layers, creating a more reliable security infrastructure.

For example, an organization that is developing antivirus defenses might implement security at many levels of the control hierarchy, including:

  • Policies, procedures, and awareness. Specific rules controlling antivirus scanning and acceptable software are documented and users are trained to understand the dangers of viruses and common ways to prevent infection of their computers.
  • Physical security. Potential virus access points, such as floppy-disk or CD-ROM drives, are inaccessible to unauthorized users.
  • Perimeter security. Virus-scanning gateways intercept potential viruses before they penetrate the organization network.
  • Host security. Antivirus software and patches keep the operating system up-to-date.
  • Application security. Application-specific antivirus filters or packages are used to defend the application against attack.
  • Data security. A backup of critical data ensures that, in the event of a virus attack, the organization can reinstall the pre-attack data state.

This example demonstrates that different controls apply at different levels. Note that controls do not apply at every layer. Each risk requires specific consideration. Defense-in-depth gives organizations a simple way to evaluate controls based on the potential reduction of risk compared with other options.

Processes and Activities  

The term security management describes the essential processes and activities that are required to establish and maintain a sound security program across an entire organization.

The resulting benefits are:

  • The appropriate level of security—confidentiality, integrity, and availability—for each informational asset based on its value to the business, its susceptibility to a security breach, and the cost of implementing the necessary protection.
  • Minimized disruption to business operation that results from security incidents.
  • Continuously adapted security policy and procedures, which accommodate changes in the organization business objectives, the external business environment, security threats, and the emergence and use of new technologies.


This section describes benefits of the four key processes in this SMF that collectively deliver the overarching security management program for an organization.

Process Flow Summary

The following diagram illustrates the primary flow among the four processes.

Figure 2: Security management process relationships

Establishing an Organizational Security Policy

An organizational security policy defines the organization's security direction and goals and a security policy framework for developing protection strategies with related controls, processes, and mechanisms. The business benefits include:

  • Agreeing on a shared vision for security within the organization and commitment from key stakeholders.
  • Identifying the organization's security requirements.
  • Identifying the levels of security required for data within the organization.
  • Identifying the security roles and responsibilities.
  • Implementing a regular review process to update security policies in line with business requirements.
  • Establishing an awareness of the importance of security and the rules governing it.

Establishing a Security Risk Management Process

By establishing an effective and regularly-reviewed security risk management process, an organization can ensure that it continues to use its security budget most efficiently to mitigate risks. The business benefits include:

  • Identifying, in line with business requirements, the appropriate level of security for specific information assets.
  • Determining the most appropriate and cost effective type of control mechanism to mitigate each security threat.
  • Establishing regular security risk reviews, to ensure continued protection to the organization.
  • Implementing the right controls for the most pertinent issues in the most effective manner possible.

Establishing a Security Monitoring and Security Auditing Process

An effective process for security monitoring and security auditing an environment will identify any potential issues or security problems in an organization. Security monitoring focuses on evaluating system activity, whereas security auditing verifies compliance with corporate policies. Both methods help to ensure that security practices are within policy constraints. The business benefits include: 

  • Identifying any potential attacks or security issues as they occur.
  • Proactively identifying any weaknesses in system configurations.
  • Providing consistent and accurate methods of reporting problems to the appropriate resources.

Establishing an Incident Response Process

An effective incident response process minimizes the impact of security incidents on the business. The business benefits include:

  • Ensuring that all staff know their responsibilities and understand how to respond if an incident occurs.
  • Providing a fast, structured, and deterministic response to security incidents.
  • Establishing the consistent and accurate recording of incidents and their resolution, which provides a body of knowledge that helps to resolve similar incidents and provides input to refine existing security controls and security policies.

Establishing an Organizational Security Policy

The following diagram, illustrating the primary flow among the four processes, focuses on the first process: establishing an organizational security policy.

Figure 3: Organizational security policy

The development of an organizational security policy involves establishing a number of documented statements including:

  • A security vision and mission.
    • Where the organization is currently
    • The security goals of the organization
    • The objectives that will achieve the security goals
  • The security requirements of the organization.
    • The external influences that affect the organization's security posture
    • The internal business initiatives that affect the security posture
    • How technology is currently being used in the organization
  • Organizational roles and responsibilities.
    • Which individuals and groups have authority to define, develop, and implement policies
    • Who is accountable for the security policies within the organization
    • Who is responsible for enacting the policies
  • A data classification model.
    • Types of information common within the organization
    • Guidelines on how to classify new data assets
    • Rules on how information should be handled
  • Policy documents.
    • Policies covering physical, perimeter, network, host, application, software development, and data security
    • Standards, guidelines, and procedures within these categories
  • An awareness program.
    • Processes for disseminating security policies to users and managers
    • Methods of training and motivating staff

To develop an organization-wide security program, it is necessary to assemble a team of key stakeholders to drive the initiative forward. The team, called the Security Steering Committee, is responsible for making decisions before and after the implementation of the resulting security program. Use external support in the planning phase of the program if you need more expertise. Assign key positions, such as project manager, security manager, or officer to this project. The success of the security program depends on the project management and the support of the stakeholders.

When the gathering of requirements is complete, the next step is to develop a realistic set of security policies. Write policies for an audience that has average reading skills, and make the policy security goals both achievable and measurable. If the policy will be localized, the writer must also take into account style and terminology considerations. A policy is a security directive or mandate from the highest levels of authority within the organization as a whole, not just within the information technology (IT) organization. All individuals within an organization are required to follow a policy for the policy to be fully effective. A policy or policy item that is unrealistic or unenforceable will invariably be ignored.

Security Vision and Mission

The planning of an overall security program requires a vision and an articulated mission statement. This is the charter of the plan. The vision and mission must identify where the organization is currently, where it wants to go, and how it will get there.

The security vision establishes the security goals of the organization. There is always a danger that visions can be either too futuristic or unrealistic. The vision must always be tempered by a realization of what is possible within the constraints of business requirements, IT resources, and technical capabilities. If staff cannot relate the vision to their working environment, they probably have doubts about the entire security program.

A security mission looks at the objectives that will deliver the overall vision. This statement encompasses all of the security goals and sets targets. The mission must also identify the elements necessary to make the security vision a reality.

It is the responsibility of the enterprise security manager, or security officer, to keep the participants on track with the plan and to achieve the intended results from the security program. The program description must be as comprehensive as possible by encompassing all paths that information may take within the organization. The stakeholders should agree on a preferred result, which is typically an environment for processing business information with minimal risk.

Executive management must continually reinforce the importance of directives defined in security policies. Toward this end, it is a good idea to place an executive management letter of support early in the security policy document, or even to make it the cover page. This letter of support describes the organization’s overall security and risk management vision, mission, and objectives. It also directs staff to adhere to the policy and explains the results of noncompliance.

Inputs to Policies

An important initial step is to gather all of the organization’s security requirements. This involves examining the various internal and external business influences and sources. Examples of internal and external influences include:

  • Organizational initiatives.
  • Organization, division, and department business targets.
  • Commercial contracts.
  • Government legislation.
  • Industry regulation.

Internal and external sources include:

  • Service level agreements (SLAs).
    • Operational
    • Contractual
  • Customers.
  • Industry partners.

The main purpose of this step is to determine the scope of an organization's requirements. This involves identifying assets, or informational resources, to secure. You use risk assessment at a later stage to quantify the risks. Quantifying risks involves identifying the potential threats to assets and the likelihood of these threats materializing, and then using these details to estimate the potential impact on the business.

For more information about industry standards and best practices, see Appendix B: Resources.

Internal Requirements

It is important to decide on the types of assets to protect within the security program. If the sole objective is protecting data assets or information resources, other areas such as personal safety or theft of items are not of concern.

Business Requirements

First, it is important that security is seen as a vital step in furthering the goals of the business and not an unnecessary set of rules or administrative processes that act as blocks to success.

To identify the business requirements, it is necessary to have the full participation of both the data owners and the security managers. Data owners must thoroughly understand the business system that contains this data; how the data is used; its importance to the company (its classification); the effect that a loss of confidentiality, integrity, or availability would have locally and on the organization overall; and any contingency plans. The security and operations managers add a further dimension through their understanding of the technologies that handle the data, so they can highlight potential weaknesses and threats. It is important to accurately record all the information. The information can then be used to classify resources and for risk assessment.

SLAs are an excellent source of information on user security requirements. SLAs normally set standards for service availability as well as security. Although service availability is usually associated with service management functions, such as availability management or business continuity planning, it is also a good indication of the level of importance that information and systems have for individual business user groups.

Technical Direction

When developing a security plan, consider the security implications of new technologies that may affect the organization. These might include:

  • The availability of high-speed connections and new collaborative tools that make it easier and more cost effective for staff to work from home.
  • The use of mobile computers with wireless connectivity that enable mobile users to connect conveniently from many locations.
  • The increasing technical sophistication of network attack, virus, and spamming tools.
  • The improvements in technical infrastructure components, such as:
    • Better security within operating systems and automated patch management to block any security weaknesses that surface.
    • Improved communication with partners through an extranet.
    • Smart cards and biometric identification to verify user identity.
    • Single logon across disparate systems and technologies so that users need only remember a single password.
    • Tools to centralize and consolidate security logs through the organization to separate the administration and security auditing functions.

For more information about Microsoft security publications, see Appendix B: Resources.

Identifying the technical trends that are likely to influence an organization assists in creating policies that are more durable. Missed trends means more changes later, which is costly.

External Requirements

An external business requirement is one that originates outside of the organization. These requirements often have a direct and profound impact on a security plan.

An example is a high-level business requirement for the integration of an organization’s order database with a partner’s supply-chain management system. Although a risk assessment may identify this access as a risk, the business requirement is assessed before determining a plan of action.

Other types of external business influences are legislative, regulatory compliance, industry, and contractual standards.

Legislative Requirements

Legislative requirements are legal requirements set by government bodies that apply to all organizations that operate within the jurisdiction of the government bodies. Typical examples of government legislation include:

  • Data protection and privacy of personal information.
  • Secure retention of organizational records.
  • Intellectual property rights.

With increasing globalization and use of the Internet, it is important that an organization’s legal department understands which country or region’s legislation applies in any business situation.

Regulatory Requirements

Regulatory requirements apply to specific industry sectors. Many industries, such as financial services companies, banks, and health care companies, have strict mandatory security regulations with which organizations must comply. Examples in the United States include the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Sarbanes-Oxley Act of 2002.

Whenever regulatory compliance is required, organizations must clearly document and establish the processes and procedures for dealing with it in their security plans. This provides a foundation and ensures that security solutions meet the regulations. A solution that circumnavigates a regulation is a flawed solution.

Industry Standards

Industry standards are not usually as rigidly enforced as regulatory compliance requirements. Often these standards are established, information-handling practices and security techniques that are in common use within an industry. Conformity with these standards often provides a business with some reassurance that, because it is following the guidance of peers, it is following proven practices.

Always consider established industry standards. For example, mandatory regulations do not often require a locked door between public areas and secure data centers. However, it is a standard in most industries and could prove to be a liability if overlooked.

A widely used and recognized industry standard in manufacturing is ISO 9001. This standard rigidly defines processes and controls to help ensure consistency and reliability of manufacturing output. Part of this standard is copious documentation of all processes. Adopting this standard could potentially result in documentation that contains sensitive business data or trade secrets that a security policy needs to control.

Contractual Requirements

A contractual requirement is a legally binding obligation for an organization to provide a service to another. Failure to do so may invoke punitive actions or penalties defined in the contract.

An example would be an organization that hosts e-commerce sites. The contract may stipulate such things as:

  • Secure retention of all customer and order information until the contract is terminated.
  • No loss of any customer or order information.
  • Access to the customer and order information by the outsourcing organization at any time.
  • Downtime of less than one hour a month.
  • Adherence to all relevant legislation and regularity compliance regarding storage of user information.

Such a contract would have security requirements and implications for both the hosting and outsourcing organizations.

Data Classification

Often when organizations discuss information, the assumption is that all information is uniform in format, use, and value, which is untrue. In the same way that physical assets, such as desks, computers, or vehicles have different values to a company, so does information. The value of physical assets can change over time; for example, a new vehicle is worth more than the same vehicle when it is five years old. The same rules—varied value and changing value—that apply to physical assets are also relevant to information assets.

A data classification scheme influences the development of security policies. The core functions of confidentiality, integrity, and availability define the security of all types of data that exist in the organization. This can be developed into a matrix of data security requirements. Use this matrix as an input to the risk assessment process, identifying the generic value of data types. For example, a customer’s credit history is highly confidential but may be of low importance with regard to availability.

It is important to be realistic in developing a data classification scheme. It is very easy to say that every piece of information must be 100 percent available, confidential, and reliable. Although this might be the case, setting such rigorous standards means that security for all data is the same, which, for the vast majority of companies, is not true. Company information that is publicly available on the Internet must be highly available and have complete integrity, but it is not confidential.

The matrix defines the level and nature of the security that is required for data assets. Specifying levels, such as high, medium, and low, does not provide clarity to a data user, because the terms are only relative to one another. Instead, use explanatory terms to make the data asset security more understandable; for example, a data asset that should not be made available outside the organization should be labeled Company Confidential.

Data and Asset Classification Guidelines

In order to develop a structured security framework, all data must have a security status. Common values include:

  • Company Confidential
  • Private
  • Sensitive
  • Public

These values are also called data asset labels. Labeling a data asset as Company Confidential immediately shows that it is not for public consumption and that it must be managed securely within the boundaries of the organization. The label also suggests that there are, however, no internal restrictions regarding its distribution. The tag Company Confidential is a good asset classification because a user immediately understands how to handle the information.

Extending this convention, a set of company year-end results may be classified Company Confidential until 9:00 A.M. Monday, when the results become public knowledge. Users of the information know not only how to handle the information but also when the restrictions can be lifted.

It is easy to become overzealous in developing a rich data asset scheme, but resist the temptation. Using a restricted number of definitions makes it easier for users to understand the scheme. The restricted number of definitions also enables standardization of the security controls, which minimizes deployment and maintenance costs.

You can customize the core classifications that are available by using time or event dependencies, such as, "Until March 23rd” or “While Special Promotion is Running." The following table shows an example of an asset classification matrix. 






Comapany Confidential
























Table 1: Example Asset Classification Menu

Assigning Asset Labels

To avoid a complicated authorization process, their originators can classify the majority of information assets. For example, an author can designate his or her report as Private. Another important reason for keeping the scheme simple is that everyone uses it every day. If users have too many options, they might fall into the habit of using the same classification for all assets. A classification decision tree, as illustrated below, will help users assign appropriate values.

Figure 4: Example asset classification decision tree

Information Handling

From a security viewpoint, the handling and transmission of data assets are important considerations. The classification labeling must prescribe how to transmit an asset. Information specified as being Sensitive, for example, might require encryption before transmission. Establish rules to cover such actions as:

  • Copying assets.
    • Authorization to copy
    • Copy management
    • Copy distribution
  • Printing assets.
    • Authorization to print
    • Print distribution
    • Uncontrolled version management
  • Storing assets.
    • Security requirements
    • Longevity of stored assets
    • Version management
  • Transmission of assets.
    • Encryption rules
    • Use of e-mail services
    • Use of Internet transmission protocols
  • Destruction of assets.
    • Erasure of data from removable media
    • Deletion from servers
    • Computer destruction

Policy Planning

A policy defines the security for a specific area in the organization. The planning structure for the policy includes format, implementation, and enforcement processes. You must consider a variety of influences on a policy to reduce risk effectively for an organization.

Planning usually begins by creating an outline that lists organizational objectives for the policy. In designing the structure and body of a policy, it is important to ensure that the policy also serves as a reference. For this reason, a security policy document must include a table of contents, a glossary, and an index.

Include a justification for each policy item. Justifications generally state the reason for a policy item, which otherwise can be lost when technology and processes change. Providing users with justification for a policy helps to increase acceptance of it, because users can understand the objective and context of the policy. However, the security team—not users—is responsible for interpreting policy. It may be a good idea to produce one document containing policy justifications that is not generally available within the organization.

Policy templates and applications are available from many sources to assist in the development of a security policy that meets an organization’s specific requirements. It is often possible to find policies written for similar organizations. Although it may be tempting to use the same policy or policy set that another organization uses, it is important to tailor the policy to fit the requirements of each organization’s environment.

A policy does more than merely provide guidance for an organization; it also must steer the enterprise. Each policy for an organization is a directive. Items in each policy must not be open to interpretation. Use active verbs and use “must” and “will” rather than terms like “should” and “may” to avoid the possibility that staff will interpret the directives as optional.

Policy Hierarchy

Individual security policies within the overall organizational security policy have a hierarchical structure. Although an organization might decide to have more layers, the organization would generally include policy items or directives, standards, and procedures. This hierarchical structure is determined during the design phase.

Figure 5: Security policy hierarchy

The organizational policy provides an overview of the organization’s priorities regarding security, identifies the major security issues that face the organization, defines the security initiatives that the organization has undertaken, and provides a framework within which other policies are positioned.

Organizational Security Policy Statement

The organizational policy should be articulated through an Organizational Security Policy Statement, drawn from the specific security policies within the context of the organizational policy. The statement should reflect the goals and objectives developed through the security vision and mission.

Specific Policies and Directives

Specific security policies address each key area, such as e-mail, removable media, Internet usage, and remote working. Each security policy contains policy items, or high-level directives, that define what is allowed and what is not allowed.

  • Standards. Standards provide more administrative detail than policies and start to identify key elements of protection. They also include descriptions of the parameters and measurements that are used. Some organizations combine both policy and standards at the same level.

Standards specifically mention technologies, methodologies, implementation procedures, and other detailed factors. Policies refer to standards rather than include the details of the standards. Policies and standards are mandatory.

  • Best practices or guidelines. Best practices or guidelines are optional and consist of experiential tips and procedures for improving security.
  • Procedures. This level is the most detailed and provides instructions for users in the organization. Procedures change as the organization evolves and adopts different products, technologies, and operational initiatives. In this kind of structure, procedures are the most frequently updated, followed by standards, and then policies.

For more information about policies, standards, best practice guidelines, and procedures within this tiered structure, see Appendix A: Sample Organizational Security Policy.

Policy Evolution

Although policy items change far less frequently than their underlying standards and procedures, they are never completely static. For example, 10 years ago few policy planners could have imagined today's popularity and commercialization of the Internet–and the subsequent security implications for organizations.

Management must consider policy modifications to improve the state of security within the organization and mandate a security review at least once a year. Stakeholders and security policy experts must be involved in addition to Legal and Human Resources departments.

Occasionally, legitimate reasons will emerge for allowing exceptions to a policy, so organizations usually implement an exceptions process. An exception policy provides approval, on a case-by-case basis, to be out of compliance with a policy. Such an exception policy is a best practice. It helps to create stronger security policies that are restrictive yet still meet organizational requirements. An auditor often finds a documented list of exceptions quite useful when assessing an organization’s security program and the level of compliance with existing policy.

Roles and Responsibilities

The development and implementation of an organizational security program necessitates a staff model that can support the goals of the program. This does not mean that the organization needs to restructure, because roles that already exist gain additional responsibilities. However, simply handing out new duties is not sufficient. The role holders must have the competencies that enable them to execute their responsibilities effectively. The Microsoft Operations Framework (MOF) has identified required responsibilities and capabilities in what it defines as the Security Role Cluster. The Security Risk Management Guide, found at, also identifies groups that contribute to the risk management components of the security program.

Both management and administrator roles must exist in an information security organization. The primary function of management is to optimize the protection strategy, whereas the primary function of administration is to monitor the security of information systems and the handling of information.

When selecting security staff, choose people who can provide a required level of information security expertise. There are various security related certifications that can help in selecting information security staff. Selecting the information security infrastructure is a prerequisite for determining the level of security technical expertise that is required.

It is efficient to control information security through a central security organization. This team of security specialists must have a “read-only” objective for security monitoring and reporting on noncompliance with policy or suspicious activity. The function of this team is monitoring security practice within an organization. The results are a separation of responsibilities between system administrators and the security administrators. This allows there to be independent checks for those individuals who can add, delete, and modify any security and system controls. The following two tables identify individual and group roles as well as their associated responsibilities.

Individual Roles


Chief Officer (CxO)

Act as sponsor for the development of the organizational security policy.

An executive, such as the chief security officer or chief information officer, fills this role.

This role also serves as the last escalation point to define acceptable risk to the business.

Security Manager

Lead the development of the organizational and related security policies.

Take overall responsibility for the development of policies, awareness, and data classification.

Operations Manager

Support security initiatives and allocate and direct resources to realize the organization's security goals.

Business Manager

Support the development of a security policy that delivers business benefit by providing a commercial viewpoint for an individual division or department.

Security Architect or Security Professional

Provide specialist security knowledge to design, plan, implement, maintain, and audit the organization’s security policies.

Data or Service Owner

Own and be responsible for specific data or service assets in the organization. Own the responsibility to mitigate risks to these assets.

Data Manager or Data Custodian

Have the administrative responsibility for the day-to-day security management of assets.

Security Administrator

Define and deliver the implementation of the security policies. Manage security access to organization assets. Monitor security controls and processes that maintain a safe computing environment.


Provide internal or independent external security auditing to verify that security policies and controls in the organization are operating effectively.


Support and follow the guidance of the security policies in handling organizational information assets.

Table 2: Individual Roles and Responsibilities

Group Roles


Information Security Group

Develop security policies for all of the organization’s assets and own the larger information security process.

Define functional security requirements and measure IT controls and the overall effectiveness of the security program, based on internal and external inputs.

Establish content of awareness programs.

This group has ongoing responsibilities. Members might include the following roles, or their delegated officials:

  • Chief Officer as sponsor
  • Security Manager
  • Security Administrator
  • Operations Manager
  • Business Managers

Security Steering Committee

Establish, sponsor, and drive the adoption of the security program from a business and commercial perspective.

Promote security awareness and the organization security vision and objectives to all staff.

Approve the allocation of sufficient resources to the program.

Ensure that responsibilities are assigned.

Monitor overall progress of the program.

This group is involved primarily in the planning, design and initial implementation stages. Members might include the following roles:

  • Chief Officer
  • Security Manager
  • Operations Manager
  • Business Managers

Security Risk Management Team

Cross-company team of business and IT security staff that is responsible for driving the Security Risk Management process. This process maintains the security risk within the organization at an agreed-upon and acceptable level.

This group has ongoing responsibilities. Members might include the following roles, or their delegated officials:

  • Security Manager
  • Operations Manager
  • Business Managers

Security Incident Response Team

Management of escalated security incidents.

This team must have members with a good knowledge of security threats.

  • Business Operations
  • IT Functions
  • Escalation procedures
  • Contingency Planning

This group has ongoing responsibilities. Members might include the following roles, or their delegated officials:

  • Security Manager
  • Operations Manager
  • Security Administrator
  • Auditor

Information Technology Group

This group includes IT architecture, engineering, auditing, and operations.

Table 3: Group Roles and Responsibilities


A policy is of no use if individuals in an organization are not familiar with its contents. It is also important that staff understand how the policies affect them and their job roles. Creating a security awareness program to keep system users up-to-date on changes and new policies is another aspect of a successful security program. The objective is for all staff to be given the appropriate level of security training for their job roles. In addition to developing understanding of the security policies, staff must be aware of the consequences of failure to comply with security rules.

User Awareness

The training must ensure that users understand security principles, specific threats to the organization, the benefits of the security program, and their responsibilities.

The format of the training can be:

  • Classroom or directed training.
  • An online seminar.
  • A Web based e-learning solution.
  • Intranet or e-mail information briefs.

Each approach has benefits:

  • Classroom or directed training can ensure the active participation of attendees; however, if users must travel to attend the training, it can be costly in terms of their time.
  • Online seminars are easy to “attend” and replay to reinforce the content. However, the level of user participation is typically lower.
  • Web-based e-learning is expensive to develop; however, most tools make it easy to incorporate tests to provide remedial feedback to users. If used in conjunction with a learning management system, results can be captured automatically.
  • Information briefs are a cheap and flexible approach to information dissemination, but it is important to remember that most readers are not as conversant with the aims and objectives of a security program as the authors of the briefs.

Use a number of awareness raising activities for greatest impact. Whatever the training format, assessment is an excellent way to ensure that users understand the organization’s security goals. Incentives for taking and passing the security assessment test range from receiving a certificate to linking the results into employees’ job appraisals.

Security training is not a one-time exercise; an ongoing security awareness program helps to ensure that staff knowledge remains current. Ongoing awareness can also include a well-publicized security Web site to provide the latest information and bulletin boards. It is also effective to display posters or tent-cards in entry points and other common areas, such as employee lounges or cafeterias.

Security policies must be accessible and distributed to everyone in the organization in hard or soft copy. Providing an online version with a search feature can be an efficient means of delivery and also makes updates and version control simpler.

Management Awareness

System administrators and managers in the organization require additional security awareness training. System administrators have privileged access and must be aware of security best practices to lower the potential risk to systems. Managers must provide an extra level of protection in the organization to the data for which they are responsible. Confidentiality, integrity, and availability of critical data are at high risk when that data is handled on a daily basis. Despite the obvious requirement for extra security at these levels, the same individuals in these roles commonly find security to be an inconvenience and might remove controls to make their work easier.

As part of providing security awareness training, security managers might need to interpret a policy item that is confusing to readers. The security manager must accept this as constructive feedback and revise the policy so that individuals do not misinterpret the substance of the policy. A high number of user inquiries might indicate that change in the wording of a policy is necessary.

Security Communication

As part of a well-structured awareness campaign, it is necessary to provide feedback to staff within the organization. Typically, security only becomes an issue when there is a high profile security breach. The security policy has specific recommendations on the publishing of security news, such as security audit results. By maintaining a heightened level of awareness, an increased level of security consciousness exists among staff.

Emergency Communication

A formal security risk management process within an organization helps to ensure that serious security incidents with major impact on the business are rare. However, when such an incident does occur, a predefined method must exist for notifying staff of the situation and, if the situation requires, informing them of any action that they must take, beyond those prescribed in security policies.

The method selected depends on the scale of users affected and the type of incident. For example, if the network and users' computers are unaffected, then e-mail and intranet postings may be an appropriate method of communication. Other options include:

  • Contacting key staff in each affected area by phone.
  • Using a dedicated announcement or emergency display system.
  • Using the public address system.

The important point is to consider the various security incident scenarios and to develop appropriate strategies that integrate with other IT functions, such as IT Service Continuity Management. Communicate the resulting documented procedure to users through awareness training.


Policies serve as the blueprint for building protection strategies for the organization. Organizations that have security policies benefit from them in several ways. The policies serve as directives for acceptable and unacceptable actions. Also, their associated standards and procedures empower staff within the organization by providing them with a definitive security vision and specific goals. Policies also provide the framework to justify security features and solutions. They simplify the process of responding to those individuals within an organization who seek answers to questions about security. If an organization does not realize these benefits from its security policies, it should revise the policies.

Establishing a Security Risk Management Process

The following diagram, illustrating the primary flow among the four processes, focuses on the second process: establishing a security risk management process.

Figure 6: Security risk management process

The security risk management process produces a cost-effective control environment that is designed to minimize business risk to an acceptable level. The acceptable risk level varies among organizations and is a tradeoff with cost. For example, an organization that decides to operate with a high level of acceptable risk might require fewer, or less sophisticated, controls; however, the organization must be prepared to handle more security incidents.

The security risk management lifecycle covers the following four phases:

  • Assessing risk—to identify and prioritize risks to the business
    • Plan the assessment
    • Gather information and identify risks
    • Prioritize risks
  • Conducting decision support—to identify and evaluate control solutions based on a defined cost-benefit process
    • Define functional requirements
    • Assess possible countermeasures
    • Select risk mitigation approach
  • Implementing controls—to deploy and operate control solutions to reduce risk to the business
    • Organizational controls
    • Operational controls
    • Technical controls
  • Measuring program effectiveness—to analyze the security risk management process for effectiveness and verify that the controls are providing the expected degree of protection
    • Develop and maintain a security risk scorecard
    • Measure control effectiveness
    • Reassess new and changed assets and security risks

For more information about the security risk management process, see the Security Risk Management Guide at

Figure 7: Phases of the security risk management process

Assessing Risk

The objectives of the Assessing Risk phase are to identify and prioritize risks across the organization. If an organization does not know the risks to which it is vulnerable, it is unlikely to have adequate protection against them.

The first step in the Assessing Risk phase is planning. The primary tasks in the planning step are:

  • Properly aligning the Assessing Risk phase to business processes. Alignment means ensuring that major assessment reviews are timed to coincide with the organization’s annual budget planning process, so that funding can be requested for the controls selected.
  • Accurately scoping the assessment—the organization's size might not allow an enterprise-wide risk assessment. The scope includes identifying the associated stakeholders who will be involved.
  • Gaining stakeholder acceptance. As a best practice, work with stakeholders informally and early in the process to ensure that they understand the importance of the assessment, their roles, and the time commitment asked of them. Emphasize why a proactive assessment helps the stakeholder by identifying controls that might avoid disruptions as a result of future security events.

Planning is critical; failure to adequately align activities with the business budgeting process, scope the risk assessment correctly, or gain acceptance of the Assessing Risk phase diminishes the effectiveness of the other phases in the security risk management process.

After planning, the next step is to identify risk related information by conferring with stakeholders across the organization; this information will also be used in the Conducting Decision Support phase. Facilitated workshops, run by the Security Risk Assessment Team, should use a nontechnical, questioning approach to draw out risk information. The primary data elements collected are:

  • Organizational assets. Anything of value to the business.
  • Asset description. Brief explanation of each asset, its class or worth to the organization (based on the organization's data classification scheme), and ownership to facilitate common understanding throughout the Assessing Risk phase.
  • Security threats. Causes or events that might negatively affect an asset, represented by loss of confidentiality, integrity, or availability of the asset.
  • Vulnerabilities. Weaknesses or lack of controls that might be exploited to affect an asset.
  • Asset exposure. Extent of the potential damage to the asset for every threat and vulnerability combination.
  • Current control environment. Description of current controls and their effectiveness across the organization.
  • Proposed controls. Initial ideas to reduce risk.

The following are examples of risks, with the asset, the asset's classification, the vulnerability, and the threat highlighted:

  • A human resources database (the asset) contains Company Confidential information (asset classification) running on an older operating system for which security patches are no longer supplied (vulnerability), so the database might be compromised, resulting in the loss of confidentiality of personnel data (threat).
  • Company Confidential information (asset classification) sent in e-mail (vulnerability) can be maliciously forwarded to unauthorized individuals inside or outside the organization (threat).

For more information about developing well-formed risk statements, see the Security Risk Management Guide at

The last step in the Assessing Risk phase is risk prioritization. Because the Assessing Risk phase output drives future IT investments, establishing a transparent process with defined roles and responsibilities is critical to gain acceptance of the results and motivate action to mitigate risks. An open and reproducible approach helps the Security Risk Management Team to reach consensus quickly, minimizing potential delays caused by the subjective nature of risk prioritization.

To determine the relative priority of each risk, it is necessary to consider the:

  • Asset exposure and asset class combination to determine the overall impact on the business of a threat occurring.
  • Likelihood, or probability, of a threat materializing within a certain amount of time.

This probability is a subjective prediction of what is likely to happen in the future and is an important influence on risk prioritization. For example, a very important asset that, if compromised, would have serious consequences, might seem like a high priority risk. However, this initial assessment should be reevaluated if the probability of threats materializing is very low.

There are a number of security risk management tools and guides available. Some are available to the public, whereas others are proprietary products. Many of these sources present formulas that use numbering schemes to qualify and quantify risk assessment into a matrix. This scorecard approach simplifies both the logic and the calculation of relative values. For more information about risk assessment methodologies and tools, see the Security Risk Management Guide at

It is the responsibility of the Security Risk Management Team to maintain a prioritized list of risks. It is important to keep in mind that an organization’s list of risks is especially sensitive information. It is a best practice to protect this kind of information because it reveals, in a single list, all exploitable risks within an organization. There is an ongoing requirement to monitor for changes that may affect the confidentiality, integrity, or availability of an organization’s information or information systems. The objective is to detect the requirement for improved or new controls and assess them in the next review. Some examples of common change for organizations using IT services include:

  • Introduction, or creation, of new assets in the organization.
  • New or changing technologies.
  • New vulnerabilities, exposures, fraud techniques, and security patches.
  • Use of social engineering techniques—attempts to manipulate and trick individuals into giving away security information.
  • Discovery of a policy item that is open for interpretation.
  • Adverse security audit findings.

Conducting Decision Support

The objective of the Conducting Decision Support phase is to select the appropriate security controls to implement within the organization. To do this, the decision support process uses the prioritized list of risks, defined during the Assessing Risk phase, and focuses on the highest risks identified.

For each of these risks, the steps are to:

  1. Define the functional security requirements. This describes the functionality necessary to mitigate risk—what must be accomplished to reduce risk, but not how.
  2. Identify each control that potentially lessens the risk to an asset and review against requirements.
  3. Assess the degree of risk reduction that each control solution achieves.
  4. Estimate cost of acquiring, implementing, supporting, and measuring each proposed control.
  5. Select the risk mitigation strategy. A cost-benefit analysis compares the level of risk after the mitigation solution to the cost of the mitigation solution.

Data owners are responsible for proposing controls that will lessen the risk and then determining the cost of each control. For each proposed control, the Security Risk Management Team estimates the degree of risk reduction that the control can be expected to provide. With these pieces of information, the team can then conduct an effective cost-benefit analysis for the control to determine whether to recommend it for implementation. The Security Steering Committee decides which controls will be implemented.

There are two common approaches to identifying controls. The first is an informal brainstorming approach in which the Risk Assessment Team poses a series of questions to the team, such as:

  • What steps could the organization take to resist or prevent the risk's occurrence?
  • What could the organization do to recover from the risk after it has taken place?
  • What measures can the organization take to detect occurrence of the risk?
  • How can the control be security-monitored and audited to ensure that it continues to be in place?
  • How can the organization validate the effectiveness of the control?
  • Are there any other actions that could be taken to manage it?

The second approach is to organize the controls into three broad categories: organizational (or administrative), physical, and technical. These are each further subdivided into controls that provide prevention, detection, recovery, and management.  

After you identify the list of potential controls for each asset, recalculate the overall risk reduction to the business. Compare the amount of risk reduction to the cost of the mitigation solution.

When determining the relative degree of risk reduction for a control, be sure to consider all of the ways in which the control may affect risk. Some questions to consider include:

  • Does the control prevent a specific attack or a collection of attacks?
  • Does it minimize the risk of a certain class of attacks?
  • Does the control recognize an attack while the attack occurs?
  • If it does recognize an attack, is it then able to resist or track the attack?
  • Does the control help to recover assets that have suffered an attack?
  • What other benefits does it provide?
  • What is the total cost of the control relative to the value of the asset?

These questions can become complex when a particular control affects multiple vulnerabilities and assets.

The options for each risk are either to mitigate it, which means using the most cost effective control, or to accept it. There are a number of reasons for accepting a risk. It might be a consequence of the cost of implementation and ongoing support; perhaps the controls identified offer inadequate risk reduction, or maybe the controls negatively affect the business by slowing down key business procedures. If the risk is accepted, there is still the option of transferring the risk to a third party, such as an insurance company or a managed services company.

Having selected the appropriate controls, the final step in this phase is to obtain approval from key stakeholders who may be affected by any new or modified controls. The security team must articulate the benefits of the controls to these stakeholders and often has to gain financial support from multiple stakeholders before making the decision to implement the controls. This requires clear business justification that demonstrates to stakeholders why the risk should be mitigated to ensure against greater loss.

For more information about the Conducting Decision Support phase, see the Security Risk Management Guide at

Implementing Controls

The objective of the Implementing Controls phase is to ensure that the prioritized control solutions, to which stakeholders agreed during the decision support process, deploy successfully.

This process involves developing action plans for implementing the controls in a specific period with minimum interruption to the business. Consider the following points in the deployment project plan:

  • Using the organization's established change management process
  • Mandating that the implementation staff submit regular and frequent status reports to the Security Steering Committee
  • Ensuring that all business areas and IT functions that may be affected are identified and consulted
  • Determining the disruption to each area during the deployment of the control and communicating this to the relevant managers
  • Ensuring that staff:
    • Have been identified from the business and IT areas to work on deploying and testing the control(s)
    • Are able to reprioritize other duties
    • Have all necessary resources, budget, support, equipment, and training
  • Identifying and acquiring any special expertise or services that are required from inside or outside the organization
  • Ensuring that all software and hardware is available prior to the deployment
  • Creating a test plan to test the control
  • Ensuring that users are aware of any changes to their current working procedures
  • Determining how procedures are to be documented and made available to users
  • Arranging for any post-deployment user training that is required

Some of these points should have already been covered, at least partially, in the decision support process. The actual detailed steps in the deployment process depend on the processes and procedures that the organization has in place.

A solution that is required to mitigate a particular risk might involve a number of separate technical controls. Defense-in-depth is a common and effective strategy. It does, however, increase the complexity of the deployment project, because it involves more areas of the organization and requires more coordination and testing than other strategies.

For more information about implementing controls, see the Security Risk Management Guide at

Measuring Program Effectiveness

The objective of the Measuring Program Effectiveness phase is to determine how the control-versus-risk-balance is evolving. Ideally, the results obtained confirm the organization’s progress toward its goal of reducing risks to acceptable levels.

Security Risk Scorecard

The security risk scorecard is an important high-level tool to help communicate the current risk posture of the organization. It also helps demonstrate the progress of managing risk over time and can be an essential communication device to demonstrate the importance of security risk management and its value to the organization. The scorecard should provide a summary level of risk, over time, to executive management. It is not designed to summarize the tactical view of the detailed risks identified during the Assessing Risk phase. The security risk scorecard helps the Security Risk Management Team drive to an acceptable level of risk across the organization by highlighting problem areas and focusing future IT investments on them. The security risk scorecard can organize risk in any way that is appropriate. For example, by:

  • Defense-in-depth layers.
  • Business units across the organization.
  • IT environments—a collection of IT assets that share a common business purpose and owner.

Measuring Control Effectiveness

Implementing a control is of little use if management cannot measure the success of the control after its deployment. The level of confidence that an organization has in reducing or monitoring a risk is in proportion to the results of measuring the control. The goal is to determine whether the control meets the requirements and expectations of the organization. It is important to quickly identify what works and eliminate what does not.

Feedback from system users, administrators, and stakeholders is a useful measurement. For example:

  • Stakeholders provide feedback related to their areas of responsibility.
  • System and security administrators provide feedback on the effectiveness of a new security control.
  • End users in the organization can also provide feedback. In many cases, the impact of a new security control is transparent to users. But others, like a new logon screen created to control access to a service, may cause users to object.

Whenever possible, gather feedback proactively and promote an environment in which feedback, both good and bad, is positively encouraged; this opportunity to contribute reactions and ideas promotes a sense of involvement and ownership.

In addition to feedback, other security auditing techniques (as discussed in the next section, Establishing a Security Monitoring and Security Auditing Process) are useful for assessing the effectiveness of controls.

Lastly, regular reports that categorize and provide details of the security incidents handled by the incident response process are vital in terms of determining the effectiveness of security controls that are in place.

Reassessing New and Changed Assets and Security Risks

To be effective, security risk management must be a continuous and ongoing process. This means regularly repeating the risk assessment process. The team can use its resources most efficiently by focusing on changes to the organization's operational environment. The team can determine where to focus its attention by collecting timely, accurate, and relevant information about changes that affect the organization's information systems. Internal events that require scrutiny include installation of new computer software or hardware; new, internally developed applications; corporate reorganizations; corporate mergers and acquisitions; and divestures of parts of the organization. It would also be prudent to review the existing list of risks to determine whether any changes have occurred. Additionally, examining the security audit logs might provide insight on new areas to investigate.

The team should also stay alert for changes outside the organization that might affect information security. Some examples include:

  • Reviewing vendor Web sites and mailing lists for new security updates and new security documentation.
  • Monitoring third-party Web sites and mailing lists for information about new security research and new announcements regarding security vulnerabilities.
  • Attending conferences and symposiums that include discussion of information security topics.
  • Undertaking information security training.
  • Staying current by reading books on computer and network security.
  • Monitoring for announcements of new attack tools and methods.


The security risk management process is a proactive, iterative approach for managing security risks within an organization to an agreed-upon and acceptable level. The security risk management process comprises four distinct phases. The Assessing Risk phase identifies and prioritizes the risks to the organization in a systematic, efficient, and timely manner. Next, the Conducting Decision Support phase uses a cost-based analysis to identify the appropriate control, or controls, for each of the prioritized risks. Then the Implementing Controls phase plans and systematically deploys these controls. Finally, the Measuring Program Effectiveness phase monitors the ongoing effectiveness of the control solutions in mitigating risk and the changes inside or outside the organization that might have an impact on information security.

Establishing a Security Monitoring and Security Auditing Process

The following diagram, illustrating the primary flow among the four processes, focuses on the third process: establishing a security monitoring and security auditing process.

Figure 8: Security monitoring and security auditing process

The security monitoring and security auditing process comprises two main activities.

  • Security monitoring. This continuous activity observes computer systems and identifies attempts to compromise security within the organization, in as real time as possible. The overall objective is to minimize damage and disruption to the organization by identifying any actual security incidents as soon as possible.
  • Security auditing. This periodic activity checks for compliance with the security policies that the organization has put in place. The objective is to assess any security deficiencies or non-compliance and identify the appropriate corrective actions required.

Security Monitoring

When monitoring computer systems, security administrators concern themselves with system events that are atypical. The overall objective is to protect the systems and the security of the data that they contain. Examination of the detailed records of operations on a system helps to accomplish this task.

All computer networks differ in behavior; what might be typical activity on one could indicate an attack on another. In addition, most network policies differ in what they want to monitor, because assets have different values in different organizations. The security risk management process helps organizations to evaluate their assets, determine what controls are required, and the level of monitoring required. It is also important to determine the difference between typical and atypical conditions and to identify the appropriate actions to take when atypical conditions exist.

For example, an organization might change its password policy to mandate the use of long and complex passwords for all user accounts. As a result, the number of failed logon attempts recorded increases by 20 percent, because users forget their passwords or have difficulty typing them. The increase in failed logon attempts could be of concern if one lacks a full understanding of the root cause of the change.

Investigating Alerts

Security alerts are real-time notifications that inform individuals or systems when specific security-related events occur. Security controls, such as intrusion detection and prevention tools, network monitoring tools, firewalls, antivirus, and proxy solutions, all generate security alerts automatically when they detect events outside their normal, defined parameters.

Alert investigation is a formal process that organizations use to evaluate the significance of suspicious events that their reporting systems identify. Alert investigation involves:

  • Discovery of an unusual event.
  • Investigation to assess the cause of these alert events.

If the cause is non-hostile, such as an incorrect configuration, normal administrative procedures correct the situation. However, if the activity is hostile, the security administrator must escalate the issue to the Incident Response Team as defined in the Incident Management SMF. For more information about the Incident Management SMF, see The Incident Management SMF at

The discovery portion of alert investigation can be:

  • Passive. The system reports alerts and stores them on a central system that a security administrator monitors routinely. This may be appropriate for less critical classes of alerts.
  • Active. The security administrator receives alert notifications in the form of a screen pop-up window, a pager message, or an e-mail message.

This discovery and investigation activity must include the requirements of the organization’s security policies and the results of the risk assessment process. To service these requirements might mean 24-hour-a-day, seven-day-a-week monitoring of critical alerts in near-real time so that a security administrator does not arrive one morning to discover numerous compromised systems. However, other classes of alerts may only require monitoring during business hours.

The approach and actions taken to investigate an alert depend on the nature of the situation. For example, where legal or disciplinary proceedings may be an outcome, strict procedures, as defined by the appropriate security policy, are necessary to preserve potential evidence.

One of the primary ways to assess the seriousness of an alert is to conduct further analysis of the logs to determine the context and other activities that occurred around the same time. For example, numerous logon failures are quite likely at 9:00 A.M. following a long holiday weekend but may be highly suspicious at 3:00 A.M. on a Saturday.

Reviewing Logs

Examining event logs—such as Web, network, system, and application logs—is a fundamental part of the security monitoring process. Reviewing logs is a normal part of investigation of the cause of security alerts.

For systems that do not incorporate automatic alerting mechanisms, in order to find the all-important exceptions to typical activity and atypical events, it is necessary to manually scan the logs. Administrators review the event logs for each critical computer, at the optimal time interval. To identify potential attacks or misuse, administrators require security policy information that describes the thresholds for events that take into account time and frequency of occurrence.

The disadvantages of manual examination of logs on systems are that the method is time consuming, and potentially important security events are not available in real time. These two issues can be solved by:

  • Scripting tools that run scripts against logs to help quickly scan and highlight interesting events.
  • Event management systems that continually monitor systems and network infrastructures and, on predetermined threshold limits, generate alerts automatically.

Reviewing Microsoft Windows Event Logs

Microsoft® Windows® operating systems support a number of different types of event logs, such as security, system, and application logs. You can view event logs manually, by using the standard administrative tools. In addition, Microsoft Operations Manager (MOM) 2005 can automatically monitor Windows event logs and generate security alerts automatically.

The types of security events typically monitored in a Microsoft environment include:

  • Logon events. The local computer records logon and logoff events, and where the logon attempt occurred.
  • Account logon events. The computer records user account logon events and validates the account logon operation (for example, a domain controller for a domain logon).
  • Account management events. These are events such as create, change, or delete users or groups; rename, disable, or enable user accounts; and set or change user passwords.
  • Policy change events. These are events such as change user rights assignment policies, trust policies, or audit policies. For example, an intruder may attempt to disable security event monitoring.
  • System events. These are events such as computer shut down or restart, or events that affect either the system or the security log. For example, an intruder may attempt to clear the security event log.

Windows-based computers can also log additional types of security events if required; Directory service access, Object access, Privilege use, and Process tracking. However, the log of these additional types of activities can include large numbers of events that can potentially obfuscate or overwrite other, more important data. Therefore, only log these events for specific situations.

For information about the types of security events logged and how to interpret log data for Windows operating systems, see chapter 9, Windows 2000 Auditing and Intrusion Detection, found in the Microsoft Solution for Securing Windows 2000 Server guide at

Reviewing Other Application Event Logs

In addition to reviewing the Windows server event logs, administrators may also want to review the private logs that applications often create. These application logs can include valuable information about potential attacks that can supplement the information found in the Windows security event log. Some Microsoft examples include:

  • Internet Information Services (IIS). IIS creates log files that track connection attempts to Web, File Transfer Protocol (FTP), network time protocol, and Simple Mail Transfer Protocol (SMTP) services.
  • Microsoft Internet Security and Acceleration (ISA) Server. ISA Server provides logs for packet filters, the ISA Server Firewall Service, and the ISA Server Web Proxy Service.  
  • Internet Authentication Service (IAS). IAS provides centralized authentication and accounting for remote access authentication using the Remote Authentication Dial-In User Service (RADIUS) protocol.

In general, organizations should consider all Microsoft and third-party applications that implement local logging functions to determine the potential usefulness of the events they record in identifying security breaches.

Reviewing Installed Services and Drivers

Many security attacks are facilitated through the services installed on the target computer, or by replacing valid drivers with versions of the drivers that include Trojan horses, which would allow an attacker to access the target computer. To minimize this risk it is important to:

  • Reduce the attack area by ensuring that only absolutely necessary services are running on a computer. The Windows Server 2003 Security Guide, available at, includes recommendations about restricting services.
  • Monitor the version and installation date (and time) of drivers on computers.
  • Regularly monitor, or be alerted, when services on systems start or stop.

Incident Identification Recommendations

When significant system events occur, communication must take place among the people within an organization who have the appropriate skill sets and responsibilities for dealing with the issues. More investigation must be done to determine the possible impact of events that may have to be declared as incidents. Affected, or potentially affected, systems must be identified before an appropriate response can be formed. This activity is dynamic and often feeds into a formal incident response process.

Event detection and analysis requires that event information be interpreted within operational activities of the organization. A system may produce a large number of significant events due to a simple increase in user activity or the deployment of a new application. It is difficult to evaluate a large volume of events without the use of automated tools. The proper tools decrease the amount of time that it takes to determine whether events are legitimate or are indicative of an attack. A wide range of tools are available to make the monitoring and investigation of security events and alerts easier. Appendix C: Security Monitoring and Security Auditing Tools, lists some of the tools that are available from Microsoft.

After administrators have investigated an event and determined it to be a potential attack, they escalate the situation to the Incident Response Team. Keep in mind, however, that many incidents are not associated with clear symptoms. Skilled attackers are careful to cover their tracks, and even unskilled attackers are becoming more difficult to detect. It is therefore important to establish a consistent method for evaluation of security incidents to assist an organization in identifying such attacks.

The recommendations in the following graphic for making event and incident analysis easier and more effective are based on information from the NIST Computer Incident Handling Guide (SP800-62).

Figure 9: Event and incident analysis recommendations

Build a Profile of Systems and Networks

Profiling (also called baselining) is a good approach to the event analysis process. An administrator can audit the characteristics of expected activity and easily identify any deviations from the expected results against an established baseline. For example, an administrator might expect to see a certain number of failed logon attempts over a period of time. However, when the number of failed logons exceeds this expected threshold, the Incident Response Team might need to investigate further. A system administrator might also want to use file-integrity checking software on hosts to derive checksums for critical files. Another area to monitor closely is host resource usage, which can identify when average and peak usage levels fall outside typical parameters.

Profiling should be automated as much as possible. Automated solutions can provide alerts to administrators when the solutions detect changes to activity. It is important to remember that although profiling is a useful technique, organizations should use it only as part of their approach to detecting and analyzing security events.

Identify and Document the Typical Behaviors of the Environment

Administrators are often the front line for incident response. To be able to recognize and identify abnormal behavior and patterns of activity, it is crucial that they understand their systems and the networks on which the systems reside.

Administrators probably will not, and should not, be expected to have a complete knowledge of all behavior throughout the environment. However, employing a team approach can utilize individuals who have unique areas of specialization.

Administrators who are more familiar with logs and alerts can quickly identify unexplained events for further investigation. Regular event log reviews keep their knowledge fresh. The reviews also give administrators an indication of the reliability of each source.

Utilize Centralized Logging

Events that can comprise an incident might be recorded in several places, such as server system and application logs, in addition to firewall, router, and intrusion detection system (IDS) logs. A good approach is to use a technology like MOM to monitor and consolidate certain events. Additionally, security administrators may configure devices in the environment to send duplicates of their log entries to the centralized logging servers. Centralized logging gives administrators and Incident Response Team members access to all pertinent log entries, in one place. Additionally, it helps simplify the process of securing logs in accordance with organizational security policies.

Centralized logging makes it more difficult for potential internal abusers and attackers to disable logging or to modify logs on compromised systems. The logging policy should include clearly stated privacy and escalation procedures. Policy documentation should also specify the amount of time that log data should be maintained. Older log data can be extremely helpful in the analysis of events that occurred just prior to a current incident. These entries may show reconnaissance activity or previous instances of similar attacks. In some circumstances, an incident might have occurred days, weeks, or even months before it was detected, so it is good practice to retain log data for a few months, or as long as is reasonably feasible.

Perform Data Filtering

Data filtering greatly enhances the ability of the security administrator to analyze data. Without filtering, the amount of data collected in logs can quickly overwhelm anyone trying to process it, which can lead to important information being overlooked or ignored. Filtering events and other information can greatly improve the efficiency of the analysis effort. The ability to know what activity is considered typical makes it easier to identify when something is suspicious.

Filtering can identify those events that are most likely to need further investigation. As stated before, an administrator needs to be able to determine whether an event, or series of events, warrants escalation to the Incident Response Team. In an event log, an administrator may want to look only for certain security events, such as failed logon attempts. However, administrators must be sure not to use this approach exclusively, because it might not recognize new malicious activities.

Implement Event Correlation

The events that comprise an incident may reside in different logs. For example, a user name might be contained in an application log. Another piece of information extracted from the network IDS log identifies that the attack targeted a specific host. However, the IDS log may not be able to determine whether the attack was successful. Administrators examine the logs of the host to gather that information.

The best approach for dealing with this situation is to perform event correlation from these multiple indication sources. Centralized logging makes event correlation easier and faster. It also enables security administrators to collate data from hosts, services, applications, networks, and security devices.

Synchronize the Clocks of All Devices

The network time protocol synchronizes clocks among systems. When administrators look at events and try to correlate them from logs on different hosts, consistent clock settings are extremely important.

In terms of evidence, consistent timestamps in the logs are also critical. As an example, assume that three logs show events associated with an attack that occurred at 10:28:05 P.M. If the clocks were not synchronized, the logs could show the events occurring at 10:28:05, 10:30:19, and 11:28:08. This variance in system clock times could make it very hard to determine the root source of the attack.

Build a Knowledge Base of Information

A knowledge base stores the records from past event analysis and incident responses in a way that enables the data to be easily searched and analyzed. Administrators can use this information for quick reference during event analysis. It is important that explanations of the preliminary indicators exist in the knowledge base, such as operating system log entries, application error codes, and other alerts from security devices.

A knowledge base should be straightforward in its structure and accessibility. The structure can be in the form of a spreadsheet or database that can perform queries. In terms of accessibility, a special Web server placed on the organization’s intranet that is restricted to certain authorized administrators should suffice. This can provide effective and flexible mechanisms for sharing data among team members.

The knowledge base should also reference other relevant resources inside, as well as outside, the organization. This can include links to viruses, malicious code, and hoax information. Part of the knowledge base may contain links to blacklisted domains that send spam.

Perform Research on Internet

There are a number of authoritative Web sites that are useful for researching security issues, such as the SANS Institute, the CERT Coordination Center, and the Center for Internet Security; see Appendix B: Resources, for more information. These key sites should be well publicized within the organization. Additionally, Internet searches can quickly provide useful, up-to-date security information and tips, as well as serve as a source for general security related topics. For example, if an administrator notices unusual scans that target Transmission Control Protocol (TCP) port 33121, a search on the terms “TCP,” “port,” and “33121” might yield some valuable results. The search might identify logs of similar activity or provide an explanation of the significance of the port number. Most Internet search engines will examine public mailing lists related to incident response or intrusion-detection Web-based archives. Administrators might also want to search private mailing lists and forums.

Run Packet Sniffers to Collect Additional Data

There are circumstances in which event logs do not record the appropriate level of detail to give an administrator a good understanding of what is happening. For example, if a denial of service attack uses fragmented packets, a sniffer is usually the fastest way to collect the necessary information about what is occurring within network traffic. In particular, a system administrator can work with network administrators to track down the source and destination of potential attacks. To keep the amount of captured data manageable, the sniffer should be specifically configured to record traffic that matches specified criteria. This also minimizes the inadvertent capture of other information. Before running any sniffers, administrators must obtain permission to use them, to avoid potential privacy concerns. Sniffers can be a useful tool for gathering critical information about what causes security events to occur at the host level, because the source usually comes from the network.

Value Experience

It is a challenge to discern the intention and effect of certain types of activity. For example, an administrator notices unusual incoming network traffic patterns on the Domain Name System (DNS) server. The traffic might simply be inquiries from a new load balancer that is coming online, or it could be the precursor of an attack. An administrator who is familiar with the environment and is aware of what is happening throughout the network has a distinct advantage. The more events and incidents to which administrators are exposed, the better the administrators are at identifying and responding to them. Additionally, continuous education about technologies and techniques is critical to keep administrators as prepared as possible.

Build a Diagnosis Matrix

A diagnostic matrix links types of security activity with potential causes and the appropriate actions to take. The objective is to enable less experienced personnel to take advantage of knowledge distilled from senior administrators and to quickly become efficient and effective. This approach is most helpful for help desk staff and other administrators who are involved in preliminary analysis as part of their job functions. New staff members benefit from knowing what kinds of activity to expect and how the organization usually responds. Data from actual event analysis in that environment is the basis for building the matrix. Another essential element in the matrix is prescriptive guidance on how best to respond to the activity and any additional resources for further information. For example, an alert notification may provide detailed diagnostic codes that match entries in the matrix. Less-experienced staff members can then follow the recorded incident responses to resolve situations in a proven manner.

Security Auditing

Security auditing, which is also referred to as security policy compliance, is the responsibility of the Information Security Group. This group:

  • Uses tools and techniques to proactively detect and report on elements within the system that do not comply with the organization's security policy.
  • Confirms whether systems are configured correctly, users are performing correctly, and data is protected.
  • Ensures that security controls are configured and functioning properly.

Any items, or other vulnerabilities that are non-compliant, are investigated, the root cause determined, and corrective action put in place. This may involve employee training, clarification of specific controls and related procedures, or even modification of security policies.

Security Auditing Techniques

Security auditing uses a range of techniques or approaches to focus on people and processes or the technical systems. The results that each approach produces are not mutually exclusive; together they provide a more comprehensive set of results. Typical security auditing techniques include:

  • Observing the environment.
  • Conducting interviews.
  • Checking system configurations.
  • Conducting live penetration tests.

Observing the Environment

The objective of observing the environment is to validate that users and administrators are adhering to established security controls. Security controls involve, or require, a level of human intervention—some more than others. It is this involvement that is often the weak link. For example, the security control for handling removable media may require disks to be labeled with the appropriate security classification. If individuals do not always correctly label disks, it may be because:

  • They find the control or associated procedures unclear.
  • They sometimes do not know the classification of data.
  • They cannot see why it is necessary.
  • They are too busy and do not have time.

Another example might be that administrators do not always perform the required monitoring check on security logs of critical computers, and this may be because:

  • They simply forget.
  • They get called away to handle urgent security issues.
  • There is no cover when they are sick or away from the office on other matters.

One method to identify these violations is to observe or monitor staff in the work environment. This could take the form of a line manager or a user tasked with this observation role. The objective is not simply to identify individual security events but rather to identify why a control or controls are not being adhered to and to determine the corrective action or actions.

Conducting Interviews

Interviews should consist of a series of questions that measure adherence to established security controls. This activity is similar to the observation activity, but it tests users' knowledge of policy. The questions must address functional knowledge, not just memorization of policy. A key success indicator of a policy can be based on how well a user understands the intent of the policy. Scenario-based questions are often very effective.

The results of these interviews should be formally documented, and a gap analysis should be performed against the current corporate security policies based on the results of such interviews. These interviews involve individuals at various levels throughout the organization. Additionally, it is important to interview those whose responsibilities include enforcing and interpreting security policies. Managers and trainers are also a key target for interviews, because a single, poorly-trained person could provide incorrect training and guidance to a large number of users.

Always conduct interviews in line with Human Resources department guidelines for such activities.

Checking System Configuration

Security audits performed one-by-one on an organization's computers or network systems are time consuming, tedious, and prone to error. Automated tools solve this problem by scanning systems across a network from a central location.

There are a number of tools available to cover the full range of security auditing requirements; these tools can:

  • Locate and identify computers and other devices on the network.
  • Check network configurations.
  • Check operating system and service configurations.
  • Check each specific application configuration.
  • Check versions of software installed.
  • Check data backups.
  • Check system, services, and application logs.

In addition to checking systems for compliance, these automated tools can also scan for known vulnerabilities. In most cases, systems can avoid compromise if the latest security updates are consistently applied.

Microsoft Baseline Security Analyzer (MBSA) is an important tool for security auditing of computers that use Window operating systems and applications. It scans Microsoft Windows NT® version 4.0, Windows 2000, Windows XP, Microsoft Windows Server™ 2003, and many key Microsoft applications for the following:

  • Common system misconfigurations
  • Missing security updates (service packs and patches)

For more details on MBSA, see Appendix C: Security Monitoring and Security Auditing Tools.

MBSA is an important security auditing tool; however, it does not provide an automated patch management solution. Organizations should implement an automated patch management solution to ensure application of patches to relevant systems in a timely fashion. Microsoft solutions are Microsoft Systems Management Server (SMS), available at, and Microsoft Windows Update Services (WUS), available at

Conducting Live Penetration Tests

One common technique for security auditing is to conduct a live examination of the strengths and weaknesses of the organization's network from an external perspective. These tests, frequently called penetration tests, can be very effective in helping to identify discrepancies with IT security policies and, in general, weaknesses and flaws in a security implementation.

A third-party security expert, with little or no knowledge of the internal systems, typically conducts the penetration tests. The third party probes the network to seek out any security vulnerabilities. This enables the third party to test the system much as an attacker would, without regard to internal considerations such as political or financial boundaries. They probe and attack the system from all angles until the relevant attacks are exhausted and vulnerabilities have been identified. They then generate a report of their activities and the results. The organization determines which areas to work on and in what order, by prioritizing the levels of risk. For example, an open port on a router that allows remote access to a domain controller would be a higher priority than removing unused but harmless files on the FTP server.

Because of the sensitivity of the information resulting from the penetration tests, it is important to select a trusted third party with a proven reputation and have an appropriate contract in place.


The reporting activity focuses on the documentation of noncompliant items that the security auditing activity has identified.

Consolidating Violations

Security audit noncompliant items are, by definition, important, but they do not necessarily require real-time notification and urgent resolution. For example, a system security audit may identify that strong password creation rules are not enabled in the way that the organization security policy mandates. If the company security policy requires that this incident type is reported, the non-compliance must be consolidated into a document and distributed to concerned parties. Noncompliance can also result from changes in security policies. For example, new types of external security threats identified may mandate policy changes that then require specific security audit checks to systems to ensure that they are compliant. In either case, the outcome will be an investigation, report, and a plan to resolve the noncompliance.

If a security policy violation represents an immediate threat to resources within the organization, the violation would trigger a security alert for processing through the security incident response process. Otherwise, the violation should be included in a report for resolution.

Distributing Findings

Communicate noncompliance reports to the asset owners, the system administrator, the security administrator, and the security manager. Before distribution, translate information in the report into a meaningful format, such as in the form of a trend analysis that tracks the number and types of nonconformance and their resolutions. It is important to remember who will receive the report and how they will perceive its benefits. Reports should demonstrate how security metrics align with, and support, organizational objectives.


The overall strategy for security monitoring and security auditing should be consistent with the security policy of the organization and the controls implemented. It is common to employ automated solutions to monitor for abnormal or atypical security events, which then alert the security administrator to suspicious behavior in real time. Skilled administrators can then use their knowledge and experience of the organization's systems to provide an initial security assessment before escalating the alert to the incident management process. The event and incident management recommendations described in this section make security monitoring efficient.

Security auditing complements the security monitoring and alerting activities because it provides regular reviews that confirm conformance to security policies. There are various security auditing techniques and tools to assess people, processes, and technical systems. Consolidate any identified, non-urgent noncompliance items into a report for resolution. Urgent noncompliance security items must initiate a security alert.

Establishing an Incident Response Process

Figure 10:
Incident response process

Establishing an incident response process is an important element in delivering a robust platform for organizational security. The incident response process defines the way that security incidents are reported and that appropriate responses are initiated. Incidents range from those that are merely logged to ones that require immediate, organization-wide action to mitigate the effects of a security breach.

The goals of the incident response process are:

  • To develop effective, timely reactions to given security incidents and to repair any damage, which might involve temporary workarounds and fixes. Even in serious security breaches, the objective is to minimize the impact on the business and particularly to business customers.
  • To ensure that a security incident cannot reoccur; this might involve further investigation into the cause of the incident. The result is usually the introduction or amendment of security controls.

User Reporting Responsibilities

Many types of security incidents are undetectable through technical controls, or it is not cost effective to do so. For example, in a high security environment, users who fail to lock their computers when they leave their desks temporarily are difficult to detect automatically, as would the actions be of an unauthorized person who uses a vulnerable computer. Manual detection of security incidents like this depends on the vigilance and active participation of staff. This can mean reporting security incidents that relate to colleagues.

There are a number of approaches to help resolve issues in this area:

  • Use automated technical controls where possible. In the example cited previously, it would be possible to use a sensor to detect when users leave their desks. Statistics show that manual controls are the weakest link. However, technical controls require investment and can add complexity.
  • Ensure that employees attend security awareness training, which reinforces the importance of security, security policies, the consequences of security breaches, and employee responsibility.
  • Include specific incident reporting responsibilities in job role descriptions.
  • Encourage colleagues to assist each other. For example, if a co-worker notices that a colleague has forgotten to label a CD with a security classification, or that a colleague is about to go home and leave sensitive material on her desk, the co-worker should remind his colleagues that this is a security breach.
  • Allow staff to report security breaches anonymously.
  • Ensure that the organization’s security disciplinary policy is widely publicized.

The incident response process must ensure that all employees are fully aware of the actions that they must take when a security incident occurs. Even if employees are unsure that an incident has occurred, suspicion must still be reported as an incident.

The normal reporting procedure for users would be to immediately report any security incident through a service desk—the central point for coordinating all activities and communication about incidents—and to follow any instructions that the service desk analyst gives. It is therefore important that the service desk have sufficient resources and a strategy to handle calls generated by a security incident that has affected the whole organization.

Examples of security incidents that users should report include:

  • Loss of removable media devices, portable computers, and authentication devices, such as smart cards.
  • Attempts to use social engineering to obtain information.
  • Suspicious e-mail messages and attachments—attachments may contain viruses or worms that can potentially infect a large part of the organization in a few hours.
  • Unexpected or inconsistent behavior of a user's PC—increasingly, viruses are subtle and do not immediately reveal themselves.
  • Corrupted, inconsistent, or non-availability of data.
  • Non-adherence to security policies by staff, contractors, or visitors.
  • Suspicious behavior of staff, contractors, or visitors.

The service desk is responsible for initially registering and then tracking the progress of each incident. If this is a known and well-understood type of incident that has a standard administrative procedure or workaround—for example, the loss of a smart card—the service desk will contain and manage the incident. The service desk escalates incidents for which there are no standard solutions to the Incident Response Team within the Incident Management function for examination and ultimate resolution.

For more information about the service desk, see the Service Desk SMF at

Escalation to Incident Response Team

Regardless of incident type, the response process to address any security incident should be consistent, well documented, and agreed upon by all relevant IT parties. Within Incident Management, the Incident Response Team handles security incidents. Using defined processes and procedures, this team should employ its expertise and where necessary the expertise and services of other IT functions, such as IT service continuity management and availability management, to ensure that there is an escalation path and strategy to handle any situation, no matter how serious the security incident.

For more information about IT service continuity management, see the IT Service Continuity Management SMF at For more information about availability management, see the Availability Management SMF at

The Incident Response Team will typically comprise both a permanent core group that focuses on security full time, and those that form a virtual, temporary team by becoming involved in incident response only when a specific type of incident occurs and their expertise is required (for example, virus attacks, denial of service attacks, or attacks focused on particular products). This structure is not rigid, and some organizations might not have permanent core team members, instead assembling a team to handle specific incidents as required. The Incident Response Team must have a strong technical security capability with members that are skilled in security techniques, technologies, and products used within the organization. In addition, the Incident Response Team might also include:

  • A communication group to manage all internal and external coordination and communication.
  • An investigation group that conducts forensic examinations and maintains evidence related to security breaches.

Security incidents escalated to the Incident Response Team initiate the following activities:

  • Evaluation of the significance of the incident; internal business operations, partners, customers and public relations
  • Evaluation of the possible and probable extent of the damage based on the nature of the incident identified
  • Escalation of the incident within the organization if identified as high risk and widespread within the organization
  • Development of a detailed incident response plan
  • Coordination of activities and communication with all affected areas in the organization
  • Isolation of any systems necessary to contain the size of the incident.
  • Execution of the incident response plan to restore the organization to a satisfactory operational status as soon as possible
  • Post-incident evaluation to analyze the incident and accordingly improve the incident response process

Note that this list was derived from the "Incident Response: Managing Security at Microsoft" white paper, which is available at  

Incident Assessment

For the incident response process to be successful, it is important to capture security incident information as accurately and completely as possible. Considering and understanding what this information will be used for, not just operationally but also strategically, enables a template to be developed that identifies the information to be recorded. In addition to the core fields, there will be optional information fields that are only appropriate for certain types of incidents. This template is not fixed, because it must evolve to accommodate new types of incidents. At a high level, this information includes:

  • Initial contact and incident symptoms, which may come from a user or a technical control.
  • Damage caused and its impact to the business.
  • Incident urgency, priority, and escalation status.
  • Classification and description of the cause of the incident.
  • Key staff involved in the assessment and resolution.
  • Important decisions made.
  • Actions taken to repair any damage and the associated cost.
  • Details of any temporary solutions or fixes, including timeline, cost, and any impact to the business.
  • Details of the ultimate solution, including timeline, cost, and any impact to the business.

Incident information can be utilized in many ways, including:

  • Helping to resolve new security incidents through comparison with previous incidents.
  • Providing justification for implementing new technical or manual controls.
  • Identifying the requirement to upgrade business systems or elements of the IT infrastructure.
  • Estimating the cost to the organization of a specific incident or related incidents.
  • Monitoring the effectiveness of new or existing controls.
  • Determining whether specific key performance indicator targets have been achieved.
  • Providing evidence for an internal disciplinary hearing, or in civil or criminal proceedings.
  • Providing evidence for compensation claims from software and service providers.

This information and the subsequent analysis are essential feeds into the regular security assessment review of the organization’s security policies.


The incident response process defines the procedures that ensure that all security incidents are dealt with effectively and in a timely manner, while minimizing impact on the business. It defines the escalation procedures and integration with other IT functions necessary to achieve a resolution of new or more serious types of incidents. It also defines the procedures that users must follow when reporting security incidents and their responsibilities. The information captured in resolving incidents is useful in many ways, such as helping to resolve new security incidents, refining security controls, and serving as performance indicators or evidence for disciplinary, compensation, civil, or criminal actions.

Please read Service Management Functions: Security Management (Part 2).

See Also

See Also

Featured Links