HackingTheUniverse

Prelude to NIST (National Institute of Standards and Technology) Special Publications: In 2002, the Federal Information Security Management Act of 2002 (Public Law 107-347), gave NIST a mandate to issue Federal Information Processing Standards Publications (FIPS PUBS), which become Federal Standards once approved by the Secretary of Commerce. In March of 2006, FIPS 200 was released, which requires Federal Agencies to meet minimum information system security standards as specified in NIST Special Publication 800-53. NIST SP 800-53 also references many other SP documents that are also standards for Federal Agencies.

1. NIST Special Publications and Security Policy
The National Institute of Standards and Technology (NIST) has published a comprehensive set of documents that outline a framework of security policy and how to implement them. The heart and core of this is a “Special Publication” (SP) called NIST SP 800-53 “Recommended Security Controls for Federal Information Systems”. SP 800-53 lays out 171 controls divided into 17 groups known as families. Each control consists of a definition of the scope of the control and activities that are related to the control. They usually leave open the specifics of how to implement the security control, so that different organizations can fill in different details according to their needs. A corollary document, NIST SP 800-53A contains more specific information on how to test these controls.

Some key SP 800-53 security controls, for the purpose of this paper, are as follows:

AC family – Access Control

• AC-6 LEAST PRIVILEGE – in order to protect against abuse of privilege, the lowest possible level of privileges needed to accomplish tasks should be assigned to users.
• AC-11/12 SESSION LOCK/SESSION TERMINATION – these two controls are designed to prevent unauthorized access to a system by initiating a time-out that locks the system and requires a user to re-authenticate. After an additional time period, it will terminate the session.
• AC-18 WIRELESS ACCESS RESTRICTIONS – this control cross references SP 800-48 which goes into wireless security considerations in depth.

CM family – Configuration Management

• CM-6 CONFIGURATION SETTINGS – this control suggests that settings should be configured in a restrictive mode and managed by automated mechanisms. It cross references SP 800-70. More specific configuration settings can also be found in DISA STIGS, and NIST/NSA hardening guidelines.

IA family – Identification and Authentication

• IA-2 USER IDENTIFICATION AND AUTHENTICATION – this control addresses the entire area of user authentication, but for the purposes of this paper, the most interesting component is password complexity and strength, and primarily windows passwords.
• IA-3 DEVICE IDENTIFICATION AND AUTHENTICATION – this control might also be considered “port level security”, as it talks about authenticating devices on the network. In plain words, if you can plug any device into any network port and get connectivity without any type of authentication, this control is not being used.

PE family – Physical and Environmental Protection

• PE-3 PHYSICAL ACCESS CONTROL – deals with how physical access is controlled including “publicly accessible” areas.

RA family – Risk Assessment

• RA-3 RISK ASSESSEMENT – offers a very generalized framework and cross-references NIST SP 800-30 for details. SP 800-100 also offers a more detailed scheme for handling risk assessment.

PL family – Security Planning

• PL-2 SYSTEM SECURITY PLAN – calls for a security plan that outlines the system involved and the security controls needed to protect the system and cross references SP 800-18.

SI family – System and Information Integrity

• SI-2 FLAW REMEDIATION – this control specifies the need for automated and centrally managed patch and update management in a general sense. In actual implementation, the most important component of this control may be how the organization handles Microsoft security updates.
• SI-3 MALICIOUS CODE PROTECTION – this control describes the needs for automated and centrally managed anti-virus protection mechanisms that include automatic updates.
• SI-4 INTRUSION DETECTION TOOLS AND TECHNIQUES – this control requires that the organization performs Intrusion Detection and offers some guidance but leaves most of the details open. SP 800-94 is “Guide to Intrusion Detection and Prevention Systems”.

The CA family, “Certification, Accreditation and Security Assessments” specifies how a C&A process should be accomplished. This includes; assessing policies and procedures, testing controls, remediation plans, continuous monitoring and more. The assessment control cross references 800-53A. Federal Agencies are required to complete a C&A process every three years and maintain monitoring and updates in the intervening years. Controls from this family will not be discussed in this paper, but it’s important to note that the C&A process is quite intensive, is required by law for Federal Agencies and often diverts much attention and effort away from actually strengthening network defense, instead concentrating it on completing paperwork to get certification. Without the appropriate certification, the IT infrastructure of an agency does not have authority to operate. Greater detail for this entire family is also found in NIST SP 800-37 “Guide for the Security Certification and Accreditation of Federal Information Systems”.

Another NIST SP document, 800-100 “Information Security Handbook: A Guide for Managers” gives us a good look at the overall process of putting together a security plan and controls to secure a system. Chapter ten, “Risk Management” explains a process of identifying threats and vulnerabilities then using controls to mitigate risk. The likelihood of success of a particular attack against a particular vulnerability needs to be weighed against any possible impact to come up with an overall determination of risk level. Control recommendations can then be developed that tailor the security plan to respond to this risk assessment.

[diagram from NIST SP 800-100 for “Risk Assessment Process”]
This process is designed to consider both threats and vulnerabilities and weigh them together, producing an assignment of a risk value.

[diagram from NIST SP 800-100 for “Risk Mitigation Strategy”]
This process helps to decide whether or not a risk can be accepted, thereby enabling decisions on the approach to mitigation strategies and focus on controls.

2. RA-3 RISK ASSESSMENT (defender’s policy)
[the italicized section below is a security control from NIST SP 800-53]

<Control: The organization conducts assessments of the risk and magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems that support the operations and assets of the agency.

Guidance: Risk assessments take into account vulnerabilities, threat sources, and security controls planned or in place to determine the resulting level of residual risk posed to organizational operations, organizational assets, or individuals based on the operation of the information system. NIST Special Publication 800-30 provides guidance on conducting risk assessments including threat, vulnerability, and impact assessments.

[The following section is the PHA response to the security control described above]

[Implementation: A risk assessment of each facility was performed in 2006 and will be updated again in 2007. The risk assessment was designed to identify the threats and vulnerabilities of the system. It was performed using an automated tool that inputs the answers from risk assessment questions, calculates the risk, and produces reports. The risk assessment report for each facility is to be kept in a locked container and marked, “Sensitive Data”. The data in this report is used to support the Certification and Accreditation determination of risk.

3. PL-2 SYSTEM SECURITY PLAN
[the italicized section below is a security control from NIST SP 800-53]

Control: The organization develops and implements a security plan for the information system that provides an overview of the security requirements for the system and a description of the security controls in place or planned for meeting those requirements. Designated officials within the organization review and approve the plan.

Guidance: NIST Special Publication 800-18 provides guidance on security planning.

[the following section is the PHA response to the security control described above]

Implementation: The format for the System Security Plan (SSP) was developed by the PHA Certification and Accreditation project under the Office of Information Architecture and authorized by the Deputy Assistant Secretary for the Office of Information. The plan has been reviewed by the Office of Cyber Information and Security Compliance Assurance. Ensuring that the plan is kept up to date and current is the responsibility of the owner of each system.

4. Threat Analysis
The following is an excerpt from a document produced by the PHA, analyzing the threats that should be considered in a hospital network.

Threat Profile of a Network of Hospitals
Executive Summary:
In the normal day to day operation of a network that supports a group of hospitals, the most critical asset to the mission of the hospitals is patient information. If the patient information is incorrectly modified or missing, the potential exists for loss of human life. In a modern cyber attack against a network that supports a group of hospitals, the most valuable asset to the attacker is patient information. The attacker might have a motive to disrupt hospital operations by interfering with the availability of the patient information, or the motive might be simply financial gain from selling identity records harvested from the network. It is also possible for an attacker to embrace both motives simultaneously.

Analysis of the threat profile produces the following as major areas of concern:
• Accidental disclosure/modification/destruction of patient information by insiders, outsiders, malicious code, or infrastructure failures.
• Intentional disclosure/modification/destruction of patient information by insiders or outsiders.

Accidental issues are already largely mitigated by system controls, data backups, redundant power supplies and other conventional defenses against natural disasters. Accidental damage is also far more likely to be limited to a local area.

This leaves intentional issues as the major threat vector. Loss analysis predicts possible large scale loss of life caused by nationwide disruption of the network and/or the possibility of many millions or even billions of dollars in financial gain for the attacker by selling identity records.

Vulnerability Analysis:
Physical security is weak at most hospitals since most areas of a modern hospital are open to access by the public. Even when certain areas of hospital space are “off-limits” to the public, both security measures and staff awareness of security considerations is very low. In most cases, an intruder can freely explore all areas (except where sterility is required) without being challenged. Physicians’ workrooms (common office areas with shared computer and printer access) are of particular concern, since the doctors usually walk away from a computer system when they are finished using it without logging off from the system.

Network security is also weak. Most hospitals do not patch security holes announced to the public within forty-eight hours, do not have strong enough authentication procedures (password complexity and storage is an issue), or access control (session timeouts and port control are issues). Configuration hardening is not done well, and Intrusion Detection is either absent or lightly monitored. More and more hospital equipment is using wireless connectivity with all the vulnerabilities attached to it. Enterprise Anti-virus installations may be the only network security strong point found in a modern hospital network, but as targeted attacks using customized malware (malicious software such as viruses, worms or trojans) become more common, its effectiveness is dropping quickly. Data encryption is becoming more common on laptops, but is rarely found anywhere else on the network.

5. Scenario: Defenders’ Policy
The process of identifying threats and vulnerabilities and weighing them is critical to success in any later defense efforts. If the threat analysis is not done correctly, the security plan and the controls that are selected might not be appropriate. Most large organizations find it easy to get this right when considering natural disasters, because they have been dealing with them for many years and often build up local experience and expertise. A hospital located along a hurricane prone coastline understands that during a serious storm, their utility grid power supply will be out and the bottom floor of their facility will be flooded, so the backup generator and any IT infrastructure need to be located on floors above some flood line. Likewise, facilities located in northern regions deal with snowstorms and cold conditions gracefully and so on.

Many security plans today almost ignore cyber attack threats and almost all of them fail to take the threat seriously enough. SP 800-100 says, “In other words, it is not possible to estimate the level of risk posed by the successful exploitation of a given vulnerability without considering the efficacy of the security controls that have been or are to be implemented to mitigate or eliminate the potential for such an exploitation; nor the threat’s motivation, opportunity, and capabilities, which contribute to the likelihood of a successful attack; nor the impact to the system and organization should successful exploitation of a vulnerability occur.” (bold added for emphasis)

An analysis of security controls (based on SP 800-53A) is supposed to be done simultaneously with the rest of the risk management process in order to help determine the likelihood of success of a particular threat. This is almost never done and this case was no exception. The site security plan was assembled by cutting and pasting from a template distributed by the organization and it was composed by members of the security team with more experience in handling the legacy problems (such as natural disasters) and little awareness of modern cyber attack technology and methodology. As a result, special focus was given to controls that mitigate the threats perceived as being most important and other controls related to cyber attacks were given little attention, instead simply producing the paperwork needed for certification.

The threat analysis paper excerpted above seems to have identified some serious threats to the hospital network, but the focus and security controls that should be expected as a result were not noted in any other documentation. The threat analysis seems to have gotten lost in the bureaucracy of a large government agency and not used. Unfortunately, it was published on a public web page.

The defenders’ policy was encyclopedic in its size and volume, and only a few small excerpts are represented here. It was also quite sketchy and vague when it came to specifying the details needed in order to actually defend the network. It almost seemed as though many of the policies were written because there was a requirement to have one, and so the wording was selected to meet expectations instead of being aimed at enforcing security controls designed to contain vulnerabilities.