Service Management Functions: Security Management (Part 1)

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

For the latest information, please see http://www.microsoft.com/mof

On this page

• Executive Summary
• Introduction
• Security Management SMF Overview
• Processes and Activities
  

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.

Introduction  

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 http://www.microsoft.com/technet/itsolutions/techguide/
mof/mofeo.mspx. An overview of all of the MOF SMF guides is available on the Service Management Functions Introduction site at http://www.microsoft.com/technet/itsolutions/techguide/
msm/smf/default.mspx.

Audience

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.

Feedback

Please direct questions or comments about this SMF guide to msmfeed@microsoft.com.

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.

Scope

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 http://go.microsoft.com/fwlink/?linkid=30794, 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.

Control

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.

Organization

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

Policy

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.

Risk

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.

Stakeholder

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.

System

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.

Trust

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.

Confidentiality

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

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.

Availability

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 http://www.microsoft.com/technet/itsolutions/techguide/
msm/smf/smfavamg.mspx, and the IT Service Continuity Management SMF, available at http://www.microsoft.com/technet/itsolutions/techguide/
msm/smf/smfsrcmg.mspx. 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.

Protect

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.

Detect

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.

Defend

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.

Recover

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.

Manage

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.

Protect

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

Detect

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.

Defend

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

Recover

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

Manage

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

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.

Overview

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. 

	Until	Before	After	While
Comapany Confidential
Private
Sensitive
Public

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 http://go.microsoft.com/fwlink/?linkid=30794, 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	Responsibilities
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.
Auditor	Provide internal or independent external security auditing to verify that security policies and controls in the organization are operating effectively.
User	Support and follow the guidance of the security policies in handling organizational information assets.

Table 2: Individual Roles and Responsibilities

Group Roles	Responsibilities
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

Awareness

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.

Summary

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 http://go.microsoft.com/fwlink/?linkid=30794.

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 http://go.microsoft.com/fwlink/?linkid=30794.

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 http://go.microsoft.com/fwlink/?linkid=30794.

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 http://go.microsoft.com/fwlink/?linkid=30794.

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 http://go.microsoft.com/fwlink/?linkid=30794.

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.

Summary

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 http://www.microsoft.com/technet/itsolutions/techguide/
msm/smf/smfincmg.mspx.

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.
• Sy