|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Program Managers: Markus Vilcinskas, Peter Van Niman
Reviewers: Christopher Budd, Glenn Berg
Other Contributors: Denis Bensch, Dawie Human, Louis De Klerk, and Johan Grobler, all of Inobits Consulting (Pty) Ltd
Microsoft Solutions Framework
Best Practices for Enterprise Security
Note: This white paper is one of a series. Best Practices for Enterprise Security ( http://www.microsoft.com/technet/archive/security/bestprac/bpent/bpentsec.mspx ) contains a complete list of all the articles in this series. See also the Security Entities Building Block Architecture ( http://www.microsoft.com/technet/archive/security/bestprac/bpent/sec2/secentbb.mspx ).
On This Page
The security methodology described in this document is designed to help security professionals develop a strategy to protect the availability, integrity, and confidentiality of data in an organization's information technology (IT) system. It will be of interest to information resource managers, computer security officials, and administrators, and of particular value to those trying to establish computer security policies. The methodology offers a systematic approach to this important task and, as a final precaution, also involves establishing contingency plans in case of a disaster.
Data in an IT system is at risk from various sources—user errors and malicious and non-malicious attacks. Accidents can occur and attackers can gain access to the system and disrupt services, render systems useless, or alter, delete, or steal information.
An IT system may need protection for one or more of the following aspects of data:
Confidentiality. The system contains information that requires protection from unauthorized disclosure. Examples: Timed dissemination information (for example, crop report information), personal information, and proprietary business information.
Integrity. The system contains information that must be protected from unauthorized, unanticipated, or unintentional modification. Examples: Census information, economic indicators, or financial transactions systems.
Availability. The system contains information or provides services that must be available on a timely basis to meet mission requirements or to avoid substantial losses. Examples: Systems critical to safety, life support, and hurricane forecasting.
Security administrators need to decide how much time, money, and effort needs to be spent in order to develop the appropriate security policies and controls. Each organization should analyze its specific needs and determine its resource and scheduling requirements and constraints. Computer systems, environments, and organizational policies are different, making each computer security services and strategy unique. However, the principles of good security remain the same, and this document focuses on those principles.
Although a security strategy can save the organization valuable time and provide important reminders of what needs to be done, security is not a one-time activity. It is an integral part of the system lifecycle. The activities described in this document generally require either periodic updating or appropriate revision. These changes are made when configurations and other conditions and circumstances change significantly or when organizational regulations and policies require changes. This is an iterative process. It is never finished and should be revised and tested periodically.
Overview of How to Compile a Security Strategy
Reviewing Current Policies
Establishing an effective set of security policies and controls requires using a strategy to determine the vulnerabilities that exist in our computer systems and in the current security policies and controls that guard them. The current status of computer security policies can be determined by reviewing the list of documentation that follows. The review should take notice of areas where policies are lacking as well as examine documents that exist:
Physical computer security policies such as physical access controls.
Network security policies (for example, e-mail and Internet policies).
Data security policies (access control and integrity controls).
Contingency and disaster recovery plans and tests.
Computer security awareness and training.
Computer security management and coordination policies.
Other documents that contain sensitive information such as:
Computer BIOS passwords.
Router configuration passwords.
Access control documents.
Other device management passwords.
Identifying Assets and Vulnerabilities to Known Threats
Assessing an organization's security needs also includes determining its vulnerabilities to known threats. This assessment entails recognizing the types of assets that an organization has, which will suggest the types of threats it needs to protect itself against. Following are examples of some typical asset/threat situations:
The security administrator of a bank knows that the integrity of the bank's information is a critical asset and that fraud, accomplished by compromising this integrity, is a major threat. Fraud can be attempted by inside or outside attackers.
The security administrator of a Web site knows that supplying information reliably (data availability) is the site's principal asset. The threat to this information service is a denial of service attack, which is likely to come from an outside attacker.
A law firm security administrator knows that the confidentiality of its information is an important asset. The threat to confidentiality is intrusion attacks, which might be launched by inside or outside attackers.
A security administrator in any organization knows that the integrity of information on the system could be threatened by a virus attack. A virus could be introduced by an employee copying games to his work computer or by an outsider in a deliberate attempt to disrupt business functions.
Identifying Likely Attack Methods, Tools, and Techniques
Listing the threats (and most organizations will have several) helps the security administrator to identify the various methods, tools, and techniques that can be used in an attack. Methods can range from viruses and worms to password and e-mail cracking. It is important that administrators update their knowledge of this area on a continual basis, because new methods, tools, and techniques for circumventing security measures are constantly being devised.
Establishing Proactive and Reactive Strategies
For each method, the security plan should include a proactive strategy as well as a reactive strategy.
The proactive or pre-attack strategy is a set of steps that helps to minimize existing security policy vulnerabilities and develop contingency plans. Determining the damage that an attack will cause on a system and the weaknesses and vulnerabilities exploited during this attack helps in developing the proactive strategy.
The reactive strategy or post-attack strategy helps security personnel to assess the damage caused by the attack, repair the damage or implement the contingency plan developed in the proactive strategy, document and learn from the experience, and get business functions running as soon as possible.
The last element of a security strategy, testing and reviewing the test outcomes, is carried out after the reactive and proactive strategies have been put into place. Performing simulation attacks on a test or lab system makes it possible to assess where the various vulnerabilities exist and adjust security policies and controls accordingly.
These tests should not be performed on a live production system because the outcome could be disastrous. Yet, the absence of labs and test computers due to budget restrictions might preclude simulating attacks. In order to secure the necessary funds for testing, it is important to make management aware of the risks and consequences of an attack as well as the security measures that can be taken to protect the system, including testing procedures. If possible, all attack scenarios should be physically tested and documented to determine the best possible security policies and controls to be implemented.
Certain attacks, such as natural disasters such as floods and lightning cannot be tested, although a simulation will help. For example, simulate a fire in the server room that has resulted in all the servers being damaged and lost. This scenario can be useful for testing the responsiveness of administrators and security personnel, and for ascertaining how long it will take to get the organization functional again.
Testing and adjusting security policies and controls based on the test results is an iterative process. It is never finished and should be evaluated and revised periodically so that improvements can be implemented.
The Incident Response Team
Good practice calls for forming an incident response team. The incident response team should be involved in the proactive efforts of the security professional. These include:
Developing incident handling guidelines.
Identifying software tools for responding to incidents/events.
Researching and developing other computer security tools.
Conducting training and awareness activities.
Performing research on viruses.
Conducting system attack studies.
These efforts will provide knowledge that the organization can use and information to issue before and during incidents.
After the security administrator and incident response team have completed these proactive functions, the administrator should hand over the responsibility for handling incidents to the incident response team. This does not mean that the security administrator should not continue to be involved or be part of the team, but the administrator may not always be available and the team should be able to handle incidents on its own. The team will be responsible for responding to incidents such as viruses, worms, or other malicious code; intrusions; hoaxes; natural disasters; and insider attacks. The team should also be involved in analyzing any unusual event that may involve computer or network security.
Methodology for Defining Security Strategies
The following section discusses a methodology for defining a computer security strategy that can be used to implement security policies and controls to minimize possible attacks and threats. The methods can be used for all types of attacks on computer systems, whether they are malicious, non-malicious or natural disasters, and can thus be re-used repeatedly for different attack scenarios. The methodology is based on the various types of threats, methods of attack, and vulnerabilities discussed in "Security Threats." The following flow chart outlines the methodology.
Predict Possible Attacks / Analyze Risks
The first phase of the methodology outlined in Flowchart 1 is to determine the attacks that can be expected and ways of defending against these attacks. It is impossible to prepare against all attacks; therefore, prepare for the most likely attacks that the organization can expect. It is always better to prevent or minimize attacks than to repair the damage after an attack has already occurred.
In order to minimize attacks it is necessary to understand the various threats that cause risks to systems, the corresponding techniques that can be used to compromise security controls, and the vulnerabilities that exist in the security policies. Understanding these three elements of attacks helps us to predict their occurrence, if not their timing or location. Predicting an attack is a matter of predicting its likelihood, which depends upon understanding its various aspects. The various aspects of an attack can be shown in an equation:
Threats + Motives + Tools and Techniques + Vulnerabilities = Attack
For Each Type of Threat
Consider all of the possible threats that cause attacks on systems. These will include malicious attackers, non-malicious threats, and natural disasters. The figure below classifies the various threats to systems.
Threats such as ignorant or careless employees and natural disasters do not involve motives or goals; therefore no predetermined methods, tools, or techniques are used to launch an attack. Almost all of these attacks or security infiltrations are internally generated; rarely will they be initiated by someone outside of the organization.
For these types of threats, security personnel need to implement separate proactive and reactive strategies, following the guidelines in Flowchart 1.
For Each Type of Method of Attack
In order to launch an attack, a malicious attacker needs a method, tool or technique to exploit various vulnerabilities in systems, security policies, and controls. A malicious attacker can use different methods to launch the same attack. Therefore, the defense strategy must be customized for each type of method used in each type of threat. Again, it is important that security professionals keep current on the various methods, tools, and techniques used by attackers. A detailed discussion of these can be found in "Security Threats." Following is a short list of these techniques:
Denial of service attacks
The proactive strategy is a set of predefined steps that should be taken to prevent attacks before they occur. The steps include looking at how an attack could possibly affect or damage the computer system and the vulnerabilities it exploits (steps 1 and 2). The knowledge gained in these assessments can help in implementing security policies that will control or minimize the attacks. These are the three steps of the proactive strategy:
Determine the damage that the attack will cause.
Determine the vulnerabilities and weaknesses that the attack will exploit.
Minimize the vulnerabilities and weaknesses that are determined to be weak points in the system for that specific type of attack.
Following these steps to analyze each type of attack has a side benefit; a pattern will begin to emerge, because many factors will overlap for different attacks. This pattern can be helpful in determining the areas of vulnerability that pose the greatest risk to the enterprise. It is also necessary to take note of the cost of losing data versus the cost of implementing security controls. Weighing the risks and the costs are part of a system risk analysis, and are discussed in the white paper "Security Planning."
Security policies and controls will not, in every case, be completely effective in eliminating attacks. For this reason it is necessary to develop contingency and recovery plans in the event that security controls are penetrated.
Determine Possible Damage Resulting from an Attack
Possible damages can range the gamut from minor computer glitches to catastrophic data loss. The damage caused to the system will depend on the type of attack. Use a test or lab environment to clarify the damages resulting from different types of attacks, if possible. This will enable security personnel to see the physical damage caused by an experimental attack. Not all attacks cause the same damage. Here are some examples of tests to run:
Simulate an e-mail virus attack on the lab system, and see what damage was caused and how to recover from the situation.
Use social engineering to acquire a username and password from an unsuspecting employee and observe whether he or she complies.
Simulate what would happen if the server room burned down. Measure the production time lost and the time taken to recover.
Simulate a malicious virus attack. Note the time required to recover one computer and multiply that by the number of computers infected in the system to ascertain the amount of downtime or loss of productivity.
It is also a good idea to involve the incident response team mentioned earlier, because a team is more likely than an individual to spot all of the different types of damage that have occurred.
Determine the Vulnerabilities or Weaknesses That an Attack Can Exploit
If the vulnerabilities that a specific attack exploits can be discovered, current security policies and controls can be altered or new ones implemented to minimize these vulnerabilities. Determining the type of attack, threat, and method makes it easier to discover existing vulnerabilities. This can be proved by an actual test.
Following is a list of possible vulnerabilities. These represent just a few of the many that exist and include examples in the areas of physical, data, and network security.
Are there locks and entry procedures to gain access to servers?
Is there sufficient air conditioning and are air filters being cleaned out regularly? Are air conditioning ducts safeguarded against break-ins?
Are there uninterruptible power supplies and generators and are they being checked through maintenance procedures?
Is there fire suppression and pumping equipment, and proper maintenance procedures for the equipment?
Is there protection against hardware and software theft? Are software packages and licenses and backups kept in safes?
Are there procedures for storing data, backups, and licensed software off-site and onsite?
What access controls, integrity controls, and backup procedures are in place to limit attacks?
Are there privacy policies and procedures that users must comply to?
What data access controls (authorization, authentication, and implementation) are there?
What user responsibilities exist for management of data and applications?
Have direct access storage device management techniques been defined? What is their impact on user file integrity?
Are there procedures for handling sensitive data?
What kinds of access controls (Internet, wide area network connections, etc.) are in place?
Are there authentication procedures? What authentication protocols are used for local area networks, wide area networks and dialup servers? Who has the responsibility for security administration?
What type of network media, for example, cables, switches, and routers, are used? What type of security do they have?
Is security implemented on file and print servers?
Does your organization make use of encryption and cryptography for use over the Internet, Virtual Private Networks (VPNs), e-mail systems, and remote access?
Does the organization conform to networking standards?
Minimize Vulnerabilities and Weaknesses Exploited by a Possible Attack
Minimizing the security system's vulnerabilities and weaknesses that were determined in the previous assessment is the first step in developing effective security policies and controls. This is the payoff of the proactive strategy. By minimizing vulnerabilities, security personnel can minimize both the likelihood of an attack, and its effectiveness, if one does occur. Be careful not to implement too stringent controls because the availability of information could then become a problem. There must be a careful balance between security controls and access to information. Information should be as freely available as possible to authorized users.
Make Contingency Plans
A contingency plan is an alternative plan that should be developed in case an attack penetrates the system and damages data or any other assets with the result of halting normal business operations and hurting productivity. The plan is followed if the system cannot be restored in a timely manner. Its ultimate goal is to maintain the availability, integrity and confidentiality of data—it is the proverbial "Plan B."
There should be a plan per type of attack and/or per type of threat. Each plan consists of a set of steps to be taken in the event that an attack breaks through the security policies. The contingency plan should:
Address who must do what, when, and where to keep the organization functional.
Be rehearsed periodically to keep staff up-to-date with current contingency steps.
Cover restoring from backups.
Discuss updating virus software.
Cover moving production to another location or site.
The following points outline the various evaluation tasks that should be evaluated to develop a contingency plan:
Evaluate the organization's security policies and controls to accommodate any opportunities found for minimizing vulnerabilities. The evaluation should address the organization's current emergency plan and procedures, and their integration into the contingency plan.
Evaluate current emergency response procedures and their effect on the continuous operation of business.
Develop planned responses to attacks and integrate them into the contingency plan, noting the extent to which they are adequate to limit damage and minimize the attack's impact on data processing operations.
Evaluate backup procedures, including the most recent documentation and disaster recovery tests, to assess their adequacy, and include them in the contingency plan.
Evaluate disaster recovery plans to determine their adequacy in providing a temporary or longer term operating environment. Disaster recovery plans should include testing the required levels of security so that security personnel can see if they continue to enforce security throughout the process of recovery, temporary operations, and the organization's move back to its original processing site or to a new processing site.
Draw up a detailed document outlining the various findings in the above tasks. The document should list:
Any scenarios to test the contingency plan.
The impact that any dependencies, planned-for assistance from outside the organization, and difficulties in obtaining essential resources will have on the plan.
A list of priorities observed in the recovery operations and the rationale in establishing those priorities.
A reactive strategy is implemented when the proactive strategy for the attack has failed. The reactive strategy defines the steps that must be taken after or during an attack. It helps to identify the damage that was caused and the vulnerabilities that were exploited in the attack, determine why it took place, repair the damage that was caused by it, and implement a contingency plan if one exists. Both the reactive and proactive strategies work together to develop security policies and controls to minimize attacks and the damage caused during them.
The incident response team should be included in the steps taken during or after the attack to help assess it and to document and learn from the event.
Assess the Damage
Determine the damage that was caused during the attack. This should be done as swiftly as possible so that restore operations can begin. If it is not possible to assess the damage in a timely manner, a contingency plan should be implemented so that normal business operations and productivity can continue.
Determine the Cause of the Damage
To determine the cause of the damage it is necessary to understand what resources the attack was aimed at and what vulnerabilities were exploited to gain access or disrupt services. Review system logs, audit logs, and audit trails. These reviews often help in discovering where the attack originated in the system and what other resources were affected.
Repair the Damage
It is very important that the damage be repaired as quickly as possible in order to restore normal business operations and any data lost during the attack. The organization's disaster recovery plans and procedures (discussed in "Security Planning") should cover the restore strategy. The incident response team should also be available to handle the restore and recovery process and to provide guidance on the recovery process.
Document and Learn
It is important that once the attack has taken place, it is documented. Documentation should cover all aspects of the attack that are known, including: the damage that is caused (hardware, software, data loss, loss in productivity), the vulnerabilities and weaknesses that were exploited during the attack, the amount of production time lost, and the procedures taken to repair the damage. Documentation will help to modify proactive strategies for preventing future attacks or minimizing damages.
Implement Contingency Plan
If a contingency plan already exists, it can be implemented to save time and to keep business operations functioning correctly. If no contingency plan exists, develop an appropriate plan based on the documentation from the previous step.
Review Outcome / Do Simulations
The second major step in the security strategy is to review the findings established in the first step (Predicting the Attack). After the attack or after defending against it, review the attack's outcome with respect to the system. The review should include: loss in productivity, data or hardware lost, and time taken to recover. Also document the attack and, if possible, track where the attack originated from, what methods were used to launch the attack and what vulnerabilities were exploited. Do simulations in a test environment to gain the best results.
Review Policy Effectiveness
If policies exist for defending against an attack that has taken place, they should be reviewed and checked for their effectiveness. If no policies exist, new ones must be drawn up to minimize or prevent future attacks.
Adjust Policy Accordingly
If the policy's effectiveness is not up to standard, the policy should be adjusted accordingly. Updates to policies must be coordinated by the relevant managerial personnel, security officer, administrators, and the incident response team. All policies should comply with the organization's general rules and guidelines. For example working times might be from 8am to 6pm. A security policy could exist or be created that allows users to logon to the system only during these times.
Example 1: Non-malicious Threat
An employee, John Doe, does not want to lose any information that he has saved to his hard disk. He wants to make a backup of this information, so he copies it to his home folder on the server that happens to also be the company's main application server. The home folders on the server have no disk quotas defined for the users. John's hard drive has 6.4 Gigabytes of information and the server has 6.5 Gigabytes of free space. The application server stops responding to updates and requests because it is out of disk space. The result is that users are denied the applications server services and productivity stops. Below is the methodology that should have taken place before John decided to back up his hard drive to his home folder.
Example 2: Malicious Threat (Outside Attacker)
Jane Doe writes viruses and hacks into systems as a hobby. Jane releases a new virus that will disrupt e-mail systems throughout the world.
Example 3: Malicious Threat (Inside Attacker)
An employee, Bob Roberts, works for a company that designs space ships. Bob is contacted by the competition and is offered a large amount of money to steal information on his company's latest design, the "Flingbot 2000." Bob does not have the necessary access rights to the information. He disguises himself as an administrator over the telephone, having a conversation with an employee who does have access rights. Bob tells the employee that he is doing routine administrative work on the server and requires the employee's username and password to verify it against the records on the server. The employee complies and gives Bob the username and password.
Example 4: Non-malicious Threat (Natural Disaster)
Company XYZ does not have fire protection and detection systems in their server room. An administrator of the company's computer systems leaves a couple of manuals lying on the air-conditioner. During the night the air conditioner overheats and starts a fire that burns down the server room and a couple of offices.
© 2000 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft is a registered trademark of Microsoft in the United States and/or other countries.