U.S. Department of Health and Human Services May 2011 HHS Cybersecurity Program Training Information Security for Information Technology (IT) Administrators

U.S. Department of Health and Human Services

May 2011

HHS Cybersecurity Program Training Information Security for Information

Technology (IT) Administrators

1


Welcome

2

Welcome to Information Security for Information Technology (IT) Administrators

IT Administrators play a vital role in protecting information assets at the Department of Health and Human Services (HHS). This course will discuss your role as an IT Administrator within an information security program and during each phase of the HHS Enterprise Performance Life Cycle (EPLC).

• Note that references to HHS information security policies, standards, and guidance are provided for various course topics. However, be sure to always refer to your Operating Division’s (OPDIV) security policies and procedures, since they may provide further specificity, and in certain cases, may be more stringent than the Department’s.

Page 1 OF 2

U.S. Department of Health and Human Services3

Course overview

• How you integrate security into your role as an IT Administrator makes an important difference in how well HHS performs its mission. This course is organized as follows:

• Security Compliance of Your System - Laws, HHS policies, and other guidance you need to observe.

• Systems Analysis and Boundaries - Boundaries, features, and interconnectivity of systems, the System Development Life Cycle, and related security practices.

• Security Controls and Your System – National Institute of Standards and Technology (NIST) recommendations and HHS practices implementing security controls.

• Documentation, Testing and Authorization- Where security practices fit in each of these tasks.

• IT Administrators and Secure Systems - Security issues most likely to concern IT Administrators.

Page 2 of 2


• Safeguarding the HHS Mission• Information Security Program Management• Information Security and the EPLC• HHS Policy for Information Systems Security and

Privacy

Page 1 of 1

Agenda

Security compliance of your system


• All it takes is one incident...What happens when security is compromised at HHS?– Americans are affected.– HHS' reputation is tarnished.– Citizen/government trust is broken.

• HHS' information technology professionals assure system security. When IT Administrators observe compliance requirements and system controls, the HHS mission is protected.

Page 1 of 11

Safeguarding the HHS mission

The Challenge of Information Security


• Information systems are not perfect, nor are the people that interact with them or the environments in which they function. As such, systems are vulnerable to misuse, accidents and manipulation.

• Threats can come from inside or outside HHS. External forces can disrupt a system, such as a hacker maliciously accessing or corrupting data, or an ordinary storm disrupting power and network access. Internally, an employee can inappropriately change, delete, or use data.

• A threat that exploits a vulnerability can allow information to be accessed, manipulated, deleted, or otherwise affected by those without the proper authority. It may also prevent data or a system from being accessed.

Page 2 of 11


Vulnerabilities, Threats and Risks


• You are part of a complex interrelationship that includes policy, people, procedures, and products. Each element helps you to identify, control, and protect information from unauthorized use.

Page 3 of 11


Security is an Integrated Solution


• To ensure the Federal Government develops its technological infrastructure and stewards its information assets wisely, various policies govern how HHS handles information security. Policy helps define the what the information security practices are.

• For instance, the Federal Information Security Management Act (FISMA) is designed to link the agency’s budget to its performance in improving information security. You can leverage the FISMA reporting requirements to help you improve the security of your system and track the costs to do so.

page 4 of 11


Policy


• You are part of a network of IT professionals within HHS that enables information security. Knowing your responsibilities and those of others ensures communication and accountability.

• For a list of complete IT roles within HHS, please refer to the HHS-OCIO-2010-0006 policy at http://www.hhs.gov/ocio/policy/policy-hhs-ocio-2010-0006-html.html#_Toc272306722

Page 5 of 11


People



People

10

• The following roles play an active role in information security at HHS: – Executives translate Federal policy into HHS policy and set the tone and direction of

security initiatives.– Chief Information Officers (CIOs) are responsible for information security (IS) planning,

budgeting, investment, performance, and acquisition. – Chief Information Security Officers (CISOs) develop enterprise or OPDIV standards for

information security. – Contracting Officer’s Technical Representatives (COTRs) are responsible for some

contract administration, such as the technical direction and acceptance.– IT Investment Board manages capital planning and investment control process, as defined

by the Clinger-Cohen Act. – Program Managers/System Owners represent programmatic and mission interests during

acquisition process and are intimately familiar with function system requirements. – Privacy Officer ensures services or systems being procured meet privacy policy and

requirements.– Legal Advisor/Contract Attorney advises on legal issues during the acquisition process. – IT Administrators manage the daily operations and maintenance of an information system.

Page 5 of 11


• While you could experiment to find the best way to determine the how to handle information security, there is guidance you can use that is based on years of research. NIST provides many documents HHS uses to ensure high standards of IT practices. These and internal HHS procedures require continuous communication among all of those involved in security.

• By following NIST and HHS procedures and accepted professional practices, you can protect Americans and prevent costly mistakes.

Page 7 of 11


Procedure


• You must consider security when dealing with all systems that manage information. A system can involve anything as simple as an off-the-shelf piece of software–or a hardware peripheral like a printer–to an enterprise-wide web-based application that is used daily by thousands of employees. All components–hardware, software, interconnections, facilities, infrastructure (e.g., power, temperature), etc.–are all part of the information system “product.”

Page 8 of 11


Products


• HHS’s responsibility to ensure information security is significant when compared to other Federal agencies. HHS is protecting the health of all Americans and providing essential human services, especially for those who are least able to help themselves.

Page 9 of 11


Information Security at HHS


• Many, but not all, IT Administrators at HHS are system administrators. Even if you are not currently responsible for a specific system, this course helps you see how your network of IT Administrator peers and colleagues throughout the Department work together to ensure information security.

Page 10 of 11


IT Administrators at HHS


• IT Administrators Network Administrators– System Administrators– Database Administrators– Software Engineers/Developers– System Engineers and Integrators

Page 11 of 11


IT Administrator Roles


• Individuals with hands-on responsibilities for the implementation and daily operations of systems must understand how their roles relate to their respective information security program. Such an understanding will enable IT Administrators to perform their duties with a mindset of appropriate and adequate protection for HHS’ IT resources.

• This lesson will cover the following topics:

– Objective of an Information Security Program

– Elements of an Effective Program

– The Role of an IT Administrator within a Security Program

– Security and the EPLC

Page 1 of 6

Information Security Program Management

Lesson Introduction


• The overall objective of an information security program is to protect the information and systems that support the operations and assets of the agency. To safeguard each system at HHS is to ensure that the following security objectives can be realized for their information:

– Confidentiality - Preserving authorized restrictions on information access and disclosure

– Integrity - Guarding against unauthorized information modification or destruction

– Availability - Ensuring timely and reliable access to and use of information

Page 2 of 6


Information Security Program Objectives


• Two types of information security programs are in place at HHS:

– HHS Information Security Program (known as Cybersecurity Program)The enterprise program is responsible for strengthening HHS’ security posture across all OPDIVs and facilitating Departmental security reporting. Information about HHS Cybersecurity Program, inclusive of Department security policy and standards, can be found on the Program’s intranet site at http://intranet.hhs.gov/it/cybersecurity/index.html

– OPDIV Information Security Programs OPDIV programs are responsible for implementing a security baseline aligned with the OPDIV mission and the HHS Cybersecurity Program.

Page 3 of 6


Information Security Programs at HHS


• As outlined in the NIST SP 800-100, Information Security Handbook: A Guide for Managers, the foundations of an effective information security program are as follows:

– Information Security Governance; – System Security Planning (SSP);– Integration of Information Security throughout the EPLC;– Managing Risk;– Security Services and Products Acquisition;– Security Authorization (formerly Certification and Accreditation (C&A)) and

Periodic Security Assessments;– Security Awareness and Training;– IT Contingency Planning (CP);– Incident Response;– Configuration Management; and– Program Performance Measurement.

Page 4 of 6


Information Security Program Elements


• Listed below are key elements of an information security program, which intersect with the responsibilities and expertise of an IT Administrator. The activities and their resulting documentation provide useful information for you to securely administer your systems.– Integration of Information Security

throughout the EPLC– Security Authorization and Periodic Security

Assessments– IT Contingency Plan– Incident Response– Configuration Management

Page 5 of 6


IT Administrator Role Within the Program


• One of the most important tenets of an information security program is the integration of security into the EPLC. Doing so is a requirement of both the FISMA and the Office of Management and Budget (OMB) Circular A-130, Appendix III, to lower the overall cost of security and to enable the three security objectives to be obtained. The picture below maps security activities to the EPLC, as prescribed by NIST SP 800-64, Security Consideration in the Information System Development Life Cycle. This lifecycle mirrors the HHS EPLC.

Page 6 of 6


Information Security and the EPLC


Controls are policies, procedures, and practices designed to provide a level of assurance that business objectives will be achieved and that undesired events will be prevented or detected and corrected. Examples of the HHS controls include:

–Performance metrics for security incidents and annual FISMA reporting

–System security evaluation including the NIST 800-53A (Revision 1), security authorization, and the Office Inspector General (OIG) reviews

–Incident Response

–IT Contingency Plans

–Physical Security

–Personnel Security

–Training and Awareness - rules of behavior and specialized training.

Page 1 of 8


HHS Controls


• FISMA creates a tie between an agency’s implementation of their security program and the agency’s budget for IT. The annual FISMA report includes input from HHS’s Chief Information Officer, the Office Inspector General, and HHS’s Senior Agency Official for Privacy (SAOP). The exact content of the report is determined by the Office of Management and Budget (OMB) and may change from year to year.

Page 2 of 8


FISMA


• HHS CIO files the annual FISMA report, which includes: – The number of IT systems and impact levels – The number of systems that have received an

authority to operate (ATO), tested contingency plans, and tested security controls

– The plan to implement NIST SP 800-53 (as amended) security controls

– The tools available for incident response – Security incidents – Security awareness and training– Configuration management – Incident reporting – Documented policy for emerging technologies

Page 3 of 8


Annual FISMA Report


• Under FISMA, HHS must determine the effectiveness of its information security program by annually performing an independent evaluation. The OIG reviews HHS information security policies, procedures, and practices.

• The CIO and the OIG may ask for your help in reviewing existing security documentation, configurations, procedures, system testing, inventory, or anything else related to information security for the systems for which you are responsible.

Page 4 of 8


Independent Evaluation


• FISMA made NIST responsible for developing standards, guidelines, including minimum requirements for information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency (other than national security systems).

• NIST communicates standards in two types of documents: Federal Information Processing Standards (FIPS) and Special Publications (SP). These standards and guidelines are issued for use government-wide. Some standards are compulsory, some are voluntary.

Page 5 of 8


NIST


• With the passage of FISMA in 2002, there is no longer a statutory provision to allow for agencies to waive mandatory FIPS. The waiver provision had been included in the Computer Security Act of 1987; however, FISMA supersedes that Act. Therefore, the references to the "waiver process" contained in many of the FIPS listed below are no longer operative.

• Note, however, that not all FIPS are mandatory; consult the applicability section of each FIPS for details. FIPS do not apply to national security systems (as defined in FISMA). The detailed guidance on implementing FIPS can be found on: http://csrc.nist.gov/publications/PubsSPs.html

Page 6 of 8


Compulsory Standards


• FIPS are developed when there are no existing voluntary standards to address Federal requirements for the interoperability of different systems, for the portability of data and software, and for computer security. FISMA eliminates the waiver process for FIPS.

• The newest publications, FIPS 199 and 200, are applicable for HHS and are an integral part of information security. Not all FIPS are mandatory. You must read the “Applicability” section of each standard to determine if it applies.

Page 7 of 8


FIPS


• FIPS 199 is used to determine the system categorization level of an IT system. This categorization is then used to identify minimum security controls, which are described in NIST SP 800-53 Rev. 3, Recommended Security Controls for Federal Information Systems and Organizations.

• FIPS 200 established 17* families of security controls, also called “security-related areas." You will see the 17 families of security controls appear in many NIST special publications and processes, such as NIST SP 800-53 Rev. 3.

• Note: Of the eighteen security control families in NIST Special Publication 800-53, seventeen families closely aligned with the seventeen minimum security requirements for federal information and information systems in FIPS 200. One additional family (Program Management [PM] family) provides controls for information security programs. This family, while not referenced in FIPS 200, provides security controls at the organizational rather than the information-system level.

Page 8 of 8


FIPS


• HHS security policy is designed to protect all IT resources from unauthorized access, disclosure, modification, destruction or misuse. The policy ensures continued operation of mission-critical activities, ensures confidentiality, integrity, availability, and authenticity of data and information; and, protects assets from theft, misuse, and unauthorized use.

• Department policy is implemented locally through the efforts of OPDIV CISOs and ISSOs, IT Administrators, and other cyber security practitioners.

• To review in-depth information about HHS security policies, refer to the HHS-OCIO Policy for Information Systems Security and Privacy.

Page 1 of 5

HHS Policy

HHS Policy and Practices


• HHS must annually report the status of its information security program to OMB and the House Committee on Government Reform. These reports are called the Plan of Action and Milestones (POA&M) for each system. The POA&M tracks significant deficiencies in HHS security.

• The POA&M is a management tool to focus attention on improving the security posture of IT resources used within HHS. HHS tracks the POA&M in the SPORT system.

• As an IT Administrator, you may be asked to provide input to the POA&M. For reporting purposes, the data from each system is rolled up into one report which represents the entire HHS.

Page 2 of 5

HHS Policy

FISMA and the POA&M


• A significant deficiency is defined as a weakness in HHS’s overall information system security program, such as a finding from an IT security risk assessment, a vulnerability found during security control assessment activities within the security authorization, or a weakness discovered during an independent review.

• The POA&M report tracks the number of weaknesses identified at the start of the quarter, the number for which action was completed, the number in which action has been delayed along with a brief explanation, and the number of new weaknesses and how they were identified. It is important to accurately track the weaknesses reported in the POA&M. When there is a change in status of the weaknesses, that change must be reflected in the next POA&M quarterly update. The POA&M identifies who is responsible for mitigating the weakness as well as milestone dates for completion.

Page 3 of 5

HHS Policy

Significant Deficiency


• Which of the following references would you select for in-depth information about how HHS implements information security policies and procedures?– NIST Special Publications 800-18 Revision 1 and 800-53

Revision 3– HHS Policy– Appendix III to Office of Management and Budget (OMB)

Circular A-130– FISMA

Page 4 of 5

HHS Policy

Learning Check


• Which of the following references would you select for in-depth information about how HHS implements information security policies and procedures?– – HHS Policy– –

Page 5 of 5

HHS Policy

Learning Check


• Each of these laws and regulations is a major contributing factor to system security landscape. As an IT Administrator, you need to know what each of these laws or regulations requires of you to ensure your system is in compliance.

• Compliance ensures that HHS is taking a risk-based approach toward protecting information resources. However, complying with the array of security requirements found in Federal laws, standards, and agency policy is a challenge. Within HHS, the Office of Inspector General helps by providing oversight.

• FISMA takes a multi-faceted approach toward information security. Progress toward improving the security posture of HHS is measured by POA&M submissions. Metrics, provided by HHS in the annual FISMA report, are used to help measure compliance.

Page 1 of 1

Recap

Recap


• Development Phase Security• Identifying Boundaries• Types of Systems• Interconnecting Systems• Your System and the EPLC

Page 1 of 1

Agenda

Systems Analysis and Boundaries


• During the Development Phase, when the system is designed and constructed, an IT Administrator may participate in the following security activities: – Identification and refinement of the system’s

security controls– Incorporation of the appropriate security controls

within the system design and construction

• This lesson will cover the following topics: – Selection and refinement of security controls;– Security control classes;– Security controls most applicable to IT

Administrators; and– Security practices for IT Administrators during

development.

Page 1 of 5

Development Phase Security

Lesson Introduction


• A system’s set of baseline security controls (low, moderate, or high), required by NIST SP 800-53 Revision 3: Recommended Security Controls for Federal Information Systems, will correspond to the system’s security category, which is determined by utilizing the FIPS 199: Standards for Security Categorization of Federal Information and Information Systems.

• The minimal set of security controls may be augmented or refined, as necessary, throughout the EPLC. All planned and implemented security controls are documented within the SSP.

• Furthermore, after assessing risk to the system, additional controls may be necessary to lower the acceptable level of risk to the system. A Risk Assessment profiles a system’s security risk and provides the rationale for any supplemental controls necessary.

Page 2 of 5


Security Control Selection & Refinement


• NIST SP 800-53 Rev.3 is divided into 18 control families comprising three classes:– Management Controls focus on the management of the information system

and the management of risk for the system. They are techniques and concerns that are normally addressed by management.

– Operational Controls address security methods focusing on mechanisms primarily implemented and executed by people (as opposed to systems). They are put in place to improve the security of a particular system (or group of systems). They often require technical or specialized expertise and many times rely upon management activities, as well as technical controls.

– Technical Controls concentrate on security controls that the computer system executes. The controls can provide automated protection for unauthorized access or misuse, facilitate detection of security violations, and support security requirements for applications and data.

Page 3 of 5


Security Control Class


• IT Administrators most frequently utilize or interface with the following controls within the operational and technical classes:

• Operational: – Configuration Management– Contingency Planning– Incident Response– System and Information Integrity– Media Protection– Maintenance

• Technical:– Identification & Authentication– Access Control– Auditing– System Communication Protection

Page 4 of 5


Security Control Applicable to IT


• The following are best practices to be employed during the Development phase: – Segregate systems under development from

production and other development and test systems

– Ensure the environmental controls are in place prior to system installation

– Configure operating systems to the Department’s minimum security standards, located at: http://intranet.hhs.gov/it/cybersecurity/index.html

– Avoid establishing highly privileged user accounts (e.g., admin/root), where possible

Page 5 of 5


Security Practices for IT Administrators During Development


• The process of uniquely assigning information resources (IT systems, personnel, funding, equipment) to an information system defines the security boundary for that system. All IT resources at HHS must be included within some system boundary.

• System boundaries at HHS meet these general considerations:

– Elements have the same function or mission objective and essentially the same operating characteristics and security needs

– Resources are under the same direct management controls

– Elements reside in the same general operating environment (or in the case of a distributed information system, reside in various locations with similar operating environments)

Page 1 of 2

Identifying Boundaries

Importance, Impact and Purpose


• Systems are evaluated by HHS management and assigned a level (low, moderate, high) representing the risk to HHS if security were to be breached. This level is based on risks to confidentiality, integrity, and availability of information.

• Determining system characterization in this way gives an agency the ability to isolate the high impact systems which reduces the amount of resources required to secure less critical applications/systems. The objective is to be sure shared resources (i.e., networks, communications, and physical access within the whole general support system or major application) are protected adequately for the highest impact level. (NIST SP 800-18 Rev.1

Page 2 of 2

Identifying Boundaries

How to Determine Your System Boundaries


• Major Application (MA) - An MA performs clearly defined functions for which there are readily identifiable security considerations and needs (an electronic funds transfer system, for example). According to OMB Circular A-130, an MA requires special management attention for one of three reasons:

– Importance to an agency mission – High development, operating, or maintenance costs – Significant role in the administration of agency programs,

finances, property, or other resources

• General Support System (GSS) - A GSS is an interconnected set of information resources under the same direct management control that shares common functionality. It normally includes hardware, software, information, data, applications, communications, and people.

Page 1 of 3

Types of Systems

Major Application and General Support System


• Does an IT Administrator typically get involved in security for MAs? It depends. Each category - high, moderate, or low - dictates the different security controls that must be in place for every major application to meet the guidance of NIST SP 800-53 Rev. 3.

• Some SP 800-53 Rev. 3 controls are handled at the organization level (that is, HHS-wide, or even within an OPDIV). These controls are usually related to policy, guidance, personnel controls (such as background checks), or security training. Some controls are also handled by the GSS – such as intrusion detection, or virus protection. IT Administrators do not typically check the MA against the controls that are handled by the GSS or the organization.

• A local IT Administrator is likely to get involved when an MA requires additional protection above and beyond what theorganization or GSS provides. This occurs after an MA SystemOwner or ISSO determines additional security controls are needed.

Page 2 of 3

Types of Systems

Securing a Major Application


• A GSS provides support for HHS’ agency infrastructure and host major applications. Since a GSS provides such wide-scale support, it is usually categorized at the moderate level or higher. Controls for a GSS must comply with the appropriate baseline provided in NIST SP 800-53 Rev.3.

• Since a GSS supports other systems, its security level must support the security level of any of the systems it hosts. When a GSS is categorized lower than an MA, the MA's System Owner decides whether to place more stringent security controls on the MA.

• A GSS (especially a GSS that is a network) is the front door to the organization's IT assets. An open port of easy access onto the network can allow a potential hacker to “jump” privileges into a major application. Teams administering a GSS must properly assess the risk level of the GSS and adequately secure it.

Page 3 of 3

Types of Systems

Securing a General Support System


• System interconnection is the direct connection of two or more IT systems for the purpose of sharing information resources. (NIST SP 800-18 Rev.1)

• If not appropriately protected, system interconnection can result in a compromise of all connected systems and the data they store, process, or transmit. System Owners, information owners, and management need information from IT Administrators about vulnerabilities associated with system interconnections and information sharing to select appropriate security controls.

• NIST recommends a Joint Planning Team approach (including IT Administrators, Program Managers, ISSOs) for interconnection planning, and an approval process for the interconnection. With existing interconnections, the appropriate documentation should be created at the current point in the system's life cycle.

Page 1 of 5

Interconnecting Systems

Security Implications of Interconnections


• A Memorandum of Understanding/Agreement (MOU/A) documents the terms and conditions for sharing data and information resources in a secure manner. A MOU/A:

– Defines the purpose of the interconnection – Identifies relevant authorities – Specifies the responsibilities of both organizations – Defines the terms of agreement, including apportionment of costs and the timeline for

terminating or reauthorizing the interconnection

• The MOU/A should not include technical details on how the interconnection is established or maintained; that is the function of the ISA.

• An Interconnection Security Agreement: – Documents the requirements for connecting the IT systems– Describes the security controls that will be used to protect the systems and data – Contains a topological drawing of the interconnection – Assigns traceable responsibility for the agreement

Page 2 of 5


MOUs, MOAs, ISAs


• Two NIST special publications guide HHS security practices for interconnecting systems. NIST SP 800-18 Rev.1 requires a formal ISA, MOU, MOA between systems that share data when the data is owned or operated by different organizations.

• HHS uses a combination MOU/ISA. HHS also adheres to a highly structured Enterprise Performance Lifecycle (EPLC), similar but not identical to that recommended by NIST.

• NIST SP 800-47, Security Guide for Interconnecting Information Systems Technology, offers specific guidance and security ground rules for interconnections.

Page 3 of 5


Setting the Ground Rules with MOUs and MOAs


• MOUs or MOAs are not needed in these instances: – Between workstations or desktops, or

publicly accessed systems. – With internal agency systems if an agency

manages and enforces a rigid EPLC requiring approvals and sign-offs ensuring compliance with security requirements.

Page 4 of 5


Important Note


• As an IT Administrator, you may be specifically asked to assist with security issues for interconnecting systems in these ways:– Help explain the technical terms of a MOU/ISA

to non-technical business partners – Assist with writing technical portions of a

MOU/ISA – Review a MOU/ISA as a member of a Joint

Planning Team (particularly, review the system diagrams and system controls to verify that what is stated in a MOU/ISA is valid and advise the Team on feasibility of the requests/terms of the agreements)

• System Owners and IT Administrators keep a copy of a completed MOU/ISA to respond to OIG inquiries as needed.

• What key ideas do you want to remember from the focus on interconnecting systems?

Page 5 of 5


IT Specialists and System Interconnections


• To perform system development efficiently, most IT professionals follow an Enterprise Performance Lifecycle (EPLC) model. The HHS EPLC phases are:

– Initiation– Concept– Planning– Requirements Analysis– Design– Development– Test– Implementation– Operations and Maintenance– Disposition

Page 1 of 3

Your System and the EPLC

Phases of EPLC


• HHS's IT professionals use the HHS EPLC model which is very similar to the NIST model.

• NIST recommends a risk management approach aligned with security activities required during each phase. This approach gives IT Administrators the tools to ensure the security of systems from conception through operation.

Page 2 of 3


Security Implications at Each Phase


• Most systems at HHS are in the operations phase. While security controls, analysis, and testing should have been established earlier in the life cycle, this is often not the case and IT Administrators find themselves having to catch up. Even if these security measures—controls, analysis, testing—have been completed properly, security remains an ongoing assignment throughout all phases. Why?– To confirm that all security controls are still in place and

functioning as intended – To verify that any changes to the system or to the

environment which the system resides have not resulted in any compromise of security controls

• What key ideas do you want to remember from the focus on the EPLC?

Page 3 of 3


Critical Security Issues


• HHS’s IT Administrator security practices are grounded in agency policies and procedures and the professional standards offered by NIST. Clear system boundaries are the cornerstone of effective security practices. Other key ideas build on this foundation: – Types of Systems: MA or GSS – Interconnecting with other Systems: HHS’s

MOU/ISA – IT Administrators and the EPLC: Deployment

and Operation

Page 1 of 1

Recap

Recap


In this section, we will cover the following topics: •Security Implementation & Assessment Phase•Security Categorization•Security Control Selection•Using Security Controls

Page 1 of 1

Agenda

Security Controls and Your System


• During the Implementation & Assessment Phase of the EPLC, system and security documentation is finalized, security controls are tested, and the system receives an ATO.

• This lesson will cover the following topics: – Further Documenting System Security– Assessing Security Controls– Security Authorization

Page 1 of 9

Implementation & Assessment Phase

Lesson Introduction


• A CP for each system is required by law and includes the following sections: – System criticality;– Roles and responsibilities;– Business impact analysis;– Preventive controls;– Damage assessment;– Recovery and reconstitution; and– Backup requirements.

• IT Administrators may be involved in creating, updating, and testing the CP to ensure that it accurately captures what is possible, in terms of technical recovery.

Page 2 of 9


Contingency Plan (CP)


• Configuration management plans are documented for systems to ensure the technical integrity of data within the system. Key components of the configuration management plan include: – Roles and Responsibilities for personnel

involved in system configuration management. – Configuration Control Process that specifies

the initiation, approval, change, and acceptance activities for all change requests.

– Supplemental Configuration Management Information, such as examples of change requests, explanation, or user guidelines for automated configuration management tools, should also be included in the plan.

Page 3 of 9


Configuration Management Plan


• All Federal agencies must conduct a privacy impact assessment (PIA) for each system and monitor for changes, thereafter, for privacy impacts. A PIA:– Ensures that information handling conforms to

applicable legal, regulatory, and policy requirements regarding privacy;

– Determines the risks and effects of a system’s collection, maintenance, and dissemination of personally identifiable information (PII); and

– Examines and evaluates protections and alternative processes for handling information to mitigate potential privacy risks.

Page 4 of 9


Privacy Impact Assessment


• Since the connection of a system to a network or another system poses additional security risks, interconnection security agreements (ISAs) for each connection must be drafted. An ISA:

• Outlines the requirements and necessary security controls to secure the interconnection; and

• Defines the responsibilities of each party to the connection.

• As an IT Administrator, you may participate in the drafting of such agreements for the systems under your purview. Once completed, ISAs are useful for the administration of a system.

Page 5 of 9


Interconnection Security Agreements


• Security control assessments determine the extent to which security controls are implemented correctly, operating as intended, and producing the desired outcome, with respect to meeting security requirements. NIST SP 800-53A Revision 1: Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans, is designed to establish a set of standardized assessment techniques and procedures for each security control listed in NIST SP 800-53 Revision 3.

• For a new system, security controls are tested by way of an independent security controls assessment. Once a system is operational, a subset of its controls must be assessed, at least annually, in between independent security controls assessment efforts.

• IT Administrators may participate in the annual internal assessment of a system’s controls or may be responsible for refining controls, if an independent reviewer finds weaknesses.

Page 6 of 9


Security Controls Assessment


• Security Controls Assessment is the independent verification and validation of both technical and non-technical controls during the security authorization process. Technical controls include those system configurations and features designed within the system, such as identification and authorization, audit, and operating system security policies. An Security Controls Assessment Plan documents the management, operational, and technical components to be tested, and outlines the approach used throughout the test.

• The information in a ST&E verifies findings of the initial risk assessment and is documented in a Security Assessment Report (SAR). The purpose of the SAR is to document any identified vulnerabilities and outline security risks associated with each. Upon completion of the SAR, the system’s Risk Assessment is updated.

Page 7 of 9




• A plan of action and milestones (POA&M) is a tool used to identify, prioritize, and monitor the progress of system security weaknesses. POA&Ms outline corrective actions, required resources (i.e., funding, man-hours), and milestones for mitigating each outstanding weakness. This is initially compiled during the system’s first security authorization and maintained thereafter.

• IT Administrators often contribute to the POA&M by formulating corrective actions, estimating resource needs, and providing input on milestones for completion.

Page 8 of 9


Plan of Action & Milestones


• The Authorization Decision Document considers the following:

• Is the actual risk to agency operations, assets, or individuals consistent with the risk assessment? Can the selected security controls achieve the desired level of assurance? Have actions been taken or planned to correct any weaknesses in the security controls? How does the security control assessment translate into actual risk to HHS, and is the risk acceptable?

• At the completion of security authorization, a system is authorized to operate in a production environment.

Page 9 of 9


Security Authorization Document


• The objective of every security action is to protect the system, the application, or stored data by protecting each of the following: – Confidentiality is the prevention of intentional or

unintentional disclosure of private or confidential information to unauthorized persons

– Integrity is the assurance that information has not been changed accidentally or deliberately, and that it is accurate and complete

– Availability ensures the reliability of, and timely access to, data. System and information availability also assures that systems work promptly and service is not denied to authorized users

• (Sources: NIST SP 800-53 Rev. 3 and Federal Information Processing Standards (FIPS) 199)

Page 1 of 3

Security Categorization

Three Objectives


• FIPS 199 defines three categories of impact and assigns categories based on the high water mark: – Low: The potential impact is Low if the loss of

confidentiality, integrity, and availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

– Moderate: The potential impact is Moderate if the loss of confidentiality, integrity, and availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

– High: The potential impact is High if the loss of confidentiality, integrity, and availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Page 2 of 3


Three Categories


• According to FIPS 200 a High Watermark is the potential impact values assigned to the respective security objectives are the highest values (i.e., high watermark) from among the security categories that have been determined for each type of information resident on those information systems. For example, when a system has two moderate risk applications and one high risk application residing on it, the overall impact rating would be high.

• The high water mark concept is employed because there are significant dependencies among the security objectives of confidentiality, integrity, and availability. In most cases, a compromise in one security objective ultimately affects the other security objectives as well.

Page 3 of 3


High Water Mark


• The security controls outlined by NIST SP 800-53 Rev.3 are used in combination with the low/moderate/high risk management guidance in FIPS 199, Standards for Security Categorization of Federal Information and Information Systems and FIPS 200, Minimum Security Requirements for Federal Information and Information Systems. HHS security procedures and practices reflect the NIST and FIPS recommendations and requirements.

Page 1 of 12

Security Control Selection

Purpose of NIST SP 800-53 Revision 3


Page 2 of 12

• NIST SP 800-53 Rev 3. is divided into 18 control families comprising three classes – Management, Operational, and Technical.

• Management Controls: Focus on the management of the computer security system and the management of risk for a system. They are techniques and concerns that are normally addressed by management, through policy and documentation.

• Operational Controls: Address security issues related to mechanisms primarily implemented and executed by people (as opposed to systems). Often, they require technical or specialized expertise and rely upon management activities as well as technical controls.

• Technical Controls: Technical controls are security controls that are configured within the system. Technical controls can provide automated protection for unauthorized access or misuse, facilitate detection of security violations, and support security requirements for applications and data.


Three Classes of Controls


• Security Authorization and Security Control Assessments

• Planning • Risk Assessment • System Services and Acquisition• Program Management

Page 3 of 12


Management Controls


The control families within the Operational Controls are: •Awareness and Training•Configuration Management•Contingency Planning•Incident Response•Maintenance•Media Protection•Physical and Environmental Protection•Personnel Security•System and Information Integrity

Page 4 of 12


Operational Controls


• The four families of technical controls identified by NIST SP 800-53 Rev. 3 are listed below. The number in parenthesis indicates the number of controls in the family.

• All together there are 59 controls represented in these four families. Click each link to view the list of controls in each family.– Identification and Authentication (8) – Access Control (22) – Audit and Accountability (14)– System and Communications Protection (34)

• The NIST technical controls capture the array of subjects that IT Administrators frequently encounter when working with information systems. HHS policy and procedures further tailor these subjects to your role.

Page 5 of 12


Technical Controls


The control families within the Technical Controls are:

• IA-1 - Identification and Authentication Policy and Procedures• IA-2 - Identification and Authentication (Organizational Users)• IA-3 - Device Identification and Authentication • IA-4 - Identifier Management • IA-5 - Authenticator Management • IA-6 - Authenticator Feedback • IA-7 - Cryptographic Module Authentication• IA-8 – Identification and Authentication (Non-Organizational

Users)

Page 6 of 12


Identification and Authentication


The Access Control Family includes the following controls:• AC-1 - Access Control Policy and Procedures • AC-2 - Account Management • AC-3 - Access Enforcement • AC-4 - Information Flow Enforcement • AC-5 - Separation of Duties • AC-6 - Least Privilege • AC-7 - Unsuccessful Login Attempts • AC-8 - System Use Notification • AC-9 - Previous Logon (Access)

Notification • AC-10 - Concurrent Session Control

Page 7 of 12


Access Control


• AC-11 - Session Lock • AC-12 - Session Termination (Withdrawn)• AC-13 - Supervision and Review - Access Control (Withdrawn)• AC-14 - Permitted Actions without Identification or Authentication • AC-15 - Automated Marking (Withdrawn)• AC-16 - Security Attributes• AC-17 - Remote Access • AC-18 - Wireless Access• AC-19 - Access Control for Mobile Devices• AC-20 - Use of External Information Systems• AC-21 - User-Based Collaboration and Information Sharing• AC-22 - Publicly Accessible Content

Page 8 of 12


Access Control (Continued)


The Audit Control Family includes the following controls:• AU-1 - Audit and Accountability Policy and Procedures • AU-2 - Auditable Events • AU-3 - Content of Audit Records • AU-4 - Audit Storage Capacity • AU-5 - Response to Audit Processing Failures• AU-6 - Audit Review, Analysis, and Reporting • AU-7 - Audit Reduction and Report Generation • AU-8 - Time Stamps • AU-9 - Protection of Audit Information • AU-10 - Non-repudiation • AU-11 - Audit Record Retention• AU-12 - Audit Generation• AU-13 - Monitoring for Information Disclosure• AU-14 - Session Audi

Page 9 of 12


Audit and Accountability


The System and Communication Protection Control Family includes the following controls:

•SC-1 - System and Communications Protection Policy and Procedures •SC-2 - Application Partitioning •SC-3 - Security Function Isolation •SC-4 - Information in Shared Resources •SC-5 - Denial of Service Protection •SC-6 - Resource Priority•SC-7 - Boundary Protection •SC-8 - Transmission Integrity •SC-9 - Transmission Confidentiality •SC-10 - Network Disconnect

Page 10 of 12


System and Communications Protection


• SC-11 - Trusted Path • SC-12 - Cryptographic Key Establishment and Management • SC-13 - Use of Validated Cryptography • SC-14 - Public Access Protections • SC-15 - Collaborative Computing Devices• SC-16 - Transmission of Security Attributes • SC-17 - Public Key Infrastructure Certificates• SC-18 - Mobile Code • SC-19 - Voice Over Internet Protocol

Page 11 of 12


System and Communications Protection


• SC-20 - Secure Name / Address Resolution Service (Authoritative Source)

• SC-21 - Secure Name / Address Resolution Service (Recursive or Caching Resolver)

• SC-22 - Architecture and Provisioning for Name / Address Resolution Service

• SC-23 - Session Authenticity • SC-24 - Fail in Known State• SC-25 - Thin Nodes • SC-26 - Honeypots • SC-27 - Operating System – Independent Applications• SC-28 - Protection of Information at Rest• SC-29 - Heterogeneity• SC-30 - Virtualization Techniques• SC-31 - Covert Channel Analysis• SC-32 - Information System Partitioning • SC-33 - Transmission Preparation Integrity • SC-34 - Non-Modifiable Executable Programs


System and Communications ProtectionPage 12 of 12


• Common events should trigger administrators to recheck controls.

• NIST SP 800-53 is updated periodically, based on comments from the IT security community to ensure the document reflects the most current controls used in practice. System administrators should verify they are using the most recent list of NIST SP 800-53 controls and test the system against any new controls.

• Other triggers signal that it is time to review whether current controls meet security needs. These include routine changes in the immediate environment, such as:

– New or modified hardware – New or modified software (including applications and

operating systems) – New threats introduced to the environment

Page 1 of 5

Using Security Controls

Triggers for Updating Controls


• The controls found in NIST SP 800-53 Rev. 3 can be used as part of a risk assessment or security test and evaluation.

• The implementation (or planned implementation) of these controls should be documented in the SP.

• IT Administrators may be responsible for testing the controls, or implementing controls after an external/independent reviewer finds weaknesses.

Page 2 of 5


How Controls are Implemented and Tested


• Each family of controls has a group of standards that organizations must meet in order to ensure system security. These include standards for:

– Identification and Authorization – Access Control – Audit and Accountability – System and Communications Protection

• The controls found in NIST SP 800-53 Rev.3 can be used as part of a risk assessment or security test and evaluation.

• The implementation (or planned implementation) of these controls should be documented in the System Security Plan.

• IT Administrators may be responsible for testing the controls, or implementing controls after an external/independent reviewer finds weaknesses

Page 3 of 5


IT Specialists and Technical Controls


• Identification and Authorization - Organizations must identify information systems users, process acting on behalf of users, or devices and authenticate (or verify) the identities of those users, processes or devices, as a prerequisite to allowing access to organizational information systems.

• Access Control - Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems) and to the types of transactions and functions that authorized users are permitted to exercise.

Page 4 of 5


Standards


• Audit and Accountability - (1) Create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; (2) Ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions.

• System and Communications Protection - (1) Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems; and (2) Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational information systems.

Page 5 of 5


Standards


• HHS’s IT Administrator security practices are grounded in agency policies and procedures and the professional standards offered by NIST. Here are key ideas from this topic:

• There are three categories of potential impact: low, moderate, or high. – These three categories determine how secure a

system must be to ensure confidentiality, integrity, and availability

– NIST SP 800-53 Rev. 3 contains a catalog of 18 families of system controls for ensuring the appropriate degree of security. These controls are arranged in three classes (Management, Operational, Technical)

– IT Administrators are typically most concerned with the four families of technical controls.

Page 1 of 1

Recap

Recap


This section will introduce the following topics:

•Operations and Maintenance Phase Security•System Security Documentation•System Security Testing•System Security Authorization

Page 1 of 1

Agenda

Documentation, Testing, and Authorization


• The Operations and Maintenance (O&M) Phase of the EPLC encompasses the ongoing monitoring and maintenance of a system. These activities are performed with a focus on ensuring the adequacy and effectiveness of the system’s security controls.

• This lesson will cover the following topics:– Incident Management;

– Configuration Management;

– Patch Management;

– Continuous Monitoring; and

– Security Testing.

Page 1 of 12

Operations and Maintenance Phase

Lesson Introduction


• IT Administrators monitor systems and networks for events, or observable occurrences, which may evolve into an incident. HHS defines an incident as the violation, or an imminent threat of a violation, of an explicit or implied security policy, acceptable use policies, or standard security practices in a computing or telecommunications system or network.

• Per NIST SP 800-61 Rev. 1: Computer Security Incident Handling Guide, Incident Management entails:– Preparation;– Detection & Analysis;– Containment, Eradication, and Recovery; and– Post-Incident Activity.

Page 2 of 12


Incident Management


• Each OPDIV has an established Incident Management capability consisting of: – Policies and procedures;– System documentation;– Incident Response Team (IRT); and– Monitoring, communication, and mitigation tools.

• Securify™ is a network and security monitoring tool that has been implemented Department-wide. This tool evaluates traffic across the network against policies and configurations that have been defined to implement effective security controls across HHS.

Page 3 of 12


Preparing to Handle Incidents


• Detecting potential security incidents may be difficult since many initially evade recognition by the sole use of monitoring tools. Knowing how a system usually behaves and learning which symptoms can indicate potential incidents is a way to recognize when you should investigate.

• Correlation and analysis of events may help to identify potential incidents that may have been overlooked, which could become a more serious problem. Early awareness of potential incidents can stop damage, disclosure, and other harmful effects before they happen.

• Incident detection and analysis may take several individuals reviewing activity before it is realized that an incident has occurred.

• Within HHS, users should report all suspected computer security incidents to their local OPDIV Computer Security Incident Response Team (CSIRT) or Help Desk.

• For more information on incident reporting, please visit: http://intranet.hhs.gov/it/cybersecurity/hhs_csirc/index.html,

Page 4 of 12


Detecting and Analyzing Incidents


• There is a delicate balance between protecting evidence from an incident and containing an incident to prevent further impact. If evidence is destroyed, it may be difficult to determine the root cause and prosecute the attacker.

• Containment strategies vary based on the type of incident. Criteria for determining the appropriate strategy include:– Potential damage to and theft of resources;– Need for evidence preservation;– Service availability (e.g., network connectivity, services provided to external

parties);– Time and resources needed to implement the strategy;– Effectiveness of the strategy (e.g., partially contains the incident, fully

contains the incident); and– Duration of the solution (e.g., emergency workaround to be removed in four

hours, temporary workaround to be removed in two weeks, permanent solution).

Page 5 of 12


Incident Containment


• After an incident has been contained and evidence preserved, as appropriate, eradication may be necessary to eliminate components of the incident. Deleting malicious code and disabling breached user accounts are examples of eradication. For some incidents, eradication is either not necessary or is performed during recovery.

• During recovery, IT Administrators restore systems to normal operation and, as necessary, harden systems to prevent similar incidents. Recovery may involve such actions as restoring systems from clean backups, rebuilding systems from scratch, replacing compromised files with clean versions, installing patches, changing passwords, and adding or strengthening other security controls.

Page 6 of 12


Incident Eradication and Recovery


• Each OPDIV IRT should evolve to reflect new threats, improved technology, and lessons learned from the handling of previous incidents. As an IT Administrator, you may be asked to participate in such “lessons learned” exercises to discuss: – Exactly what happened, and at what times?– How well did staff and management perform in dealing with the incident?– Were the documented procedures followed?– Were they adequate? – What information was needed sooner? – Were any steps or actions taken that might have inhibited the recovery? – What would the staff and management do differently the next time a similar

incident occurs? – What corrective actions can prevent similar incidents in the future? – What additional tools or resources are needed to detect, analyze, and

mitigate future incidents?

Page 7 of 12


Post Incident Activity


• HHS Computer Security Incident Response Center (CSIRC)

United States Computer Emergency Readiness Team (US-CERT)

SANS Internet Storm Center

CERT® Coordination Center

Carnegie Mellon University Software Engineering Institute (SEI)

Page 8 of 12


Incident Management Resources

The helpful incident management resources include:


• Once operational, systems are typically in a constant state of modification and enhancement, such as upgrades to components. Any change can have a significant impact on the security posture of the system. Therefore, continually documenting system changes and assessing the potential impact on the security is an essential aspect of maintaining system accreditation.

• Adherence to your OPDIV’s configuration and change management procedures is necessary to maintain an accurate inventory of all changes to the system.

Page 9 of 12


Configuration Management


• Part of maintaining a system is to ensure system components are kept up-to-date with patches. Effective patch management entails maintaining an awareness of system vulnerabilities and available patches for mitigation. Patches are periodically released for operating systems, office suites, commercial software tools and applications, and commonly used utilities.

• Patches should be tested before deployment to a production environment to prevent adverse impacts to operational systems.

Page 10 of 12


Patch Management


• FISMA requires periodic and continuous testing and evaluation of the security controls in an information system to ensure that the controls remain effective in their application. Security control monitoring (i.e. verifying the continued effectiveness of those controls over time) and reporting are essential activities within an information security program. The ongoing monitoring of security controls can be accomplished by one or a combination of the following:– Security review;– Security testing; and– Evaluation or audit.

• Refer to NIST SP 800-53 Rev. 3 for security control assessment procedures.

Page 11 of 12


Continuous Monitoring


• Types of testing that an IT Administrator may conduct to test security controls periodically between security authorization cycles are vulnerability scanning and penetration testing.

• Vulnerability scanning is an automated process to identify vulnerabilities of computing systems in a network to determine if and where a system can be exploited and/or threatened. It seeks out security flaws based on a database of known flaws, tests systems for the occurrence of these flaws, and generates a report of the findings.

• Penetration testing is testing in which an evaluator attempts to circumvent the security features of a system based on their understanding of the system design and implementation. The purpose is to identify methods of gaining access to a system by using common tools and techniques used by attackers.

• For additional information, refer to the HHS IT Penetration Testing Guide located at http://intranet.hhs.gov/it/cybersecurity/index.html

Page 12 of 12


Security Testing


• The Security Plan (SP) for each system includes: – Appropriate security controls – An indication of low, moderate, or high level of

security – Essential information necessary for the Authorizing

Official to grant an authorization to operate– Stakeholder assistance in managing and identifying

risk to systems• The SP should be created during the

development phase of the EPLC. Once it is created, it should be reviewed and updated or verified at least annually. If the system has changed (system environment, software, hardware, user groups), the SSP should be documented as soon as the change is made. If no changes have occurred, the document should still be reviewed and verified.

Page 1 of 9

System Security Documentation

Security Plan


• A CP for each system is required by law and includes the following key sections:

– System criticality– Responsibilities– Business impact analysis – Preventive controls – Damage assessment – Recovery and reconstitution – Backup requirements (NIST SP 800-34 Rev. 1)

• IT Administrators may be involved in assisting with creating the CP to ensure that it accurately captures what is possible in terms of technical recovery. IT Administrators also may be required to document changes as soon as they are made.

• Even when no changes have occurred, the document should still be reviewed and verified by the IT Administrator or ISSO at least annually.

Page 2 of 9


Contingency Plan (CP)


• NIST SP 800-34, Revision 1, Contingency Planning Guide for Federal Information Systems, directly supports CP development. CPs are also developed in response to the following Federal and departmental policies and guidelines:

– Public Law 107-347, E-Government Act of 2002, Title III, Federal Information Security Management Act, December 2002

– Office of Management and Budget Circular A-130, Appendix III, Security of Federal Automated Information Resources, November 2000

– Federal Preparedness Circular 65, Federal Executive Branch Continuity of Operations, June 15, 2004

– Presidential Decision Directive 67, Enduring Constitutional Government and Continuity of Government Operations, October 1998

– Homeland Security Presidential Directive 7, Critical Infrastructure Identification, Prioritization, and Protection, December 2003

Page 3 of 9


Legal Requirements


• The CP provides essential resources, plans, and procedures to maintain system operations in the event of a system disruption or outage. It also includes training information and testing exercises and results. Training should occur at least annually for all IT Administrators and other individuals involved with contingency operations. The CP should be updated following any testing exercises to reflect lessons learned and updates.

Page 4 of 9


More About the Contingency Plan


• Incident response plans are documented for systems to ensure computer security incidents are handled efficiently and effectively. Knowing what to do enables you to ensure the confidentiality, integrity, and availability of the information contained within the system is not compromised.

• Each OPDIV is responsible for developing and documenting the process and responsibilities for incident response. IT Administrators are most likely to be involved in the Detection, Response, and Resolution phases of the typical five-phase incident response life cycle.

• Federal law requires Federal agencies to report incidents to the Federal Computer Incident Response Center (FedCIRC) office within the Department of Homeland Security.

Page 5 of 9


Incident Response Plan


• Immediate and effective reporting may help prepare for future incidents, and prevent incidents from recurring. Incident reporting shares knowledge across HHS OPDIVs and can reduce the likelihood of future occurrences. An incident is any disruption in the system due to manmade or natural causes.

• By knowing how to respond during an incident, you can help resolve the issue efficiently, minimize loss of information, and minimize disruption of services or breach of security. Be sure to follow incident reporting procedures while an incident is being handled and document each step toward resolution.

• For NIST's guidance on the benefits of having an incident response plan, please see NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response)

Page 6 of 9


Incident Handling/Reporting


• Responding to incidents systematically so that the appropriate steps are taken

• Helping personnel to recover quickly and efficiently from security incidents, minimizing loss or theft of information, and disruption of services

• Using information gained during incident handling to better prepare for handling future incidents and to provide stronger protection for systems and data

• Dealing properly with legal issues that may arise during incidents.

• (NIST SP 800-61 Revision 1: Computer Security Incident Handling Guide)

Page 7 of 9


Benefits of Incident Response Plan


• Configuration management plans are documented for systems to ensure technical integrity of data within the system. Key components of the configuration management plan include:

• Roles and Responsibilities - Roles for system configuration management personnel and specific responsibilities (e.g., Executives, System Owners, Developers) are documented in detail.

• Configuration Control Process - Procedures are documented that specify the initiation, approval, change, and acceptance processes for all change requests.

• Supplemental Configuration Management Information - Information such as examples of change requests, explanation or user guidelines for automated configuration management tools should also be included in the plan.

Page 8 of 9


Configuration Management Plan


• Before any system is made operational, it must be authorized by agency management to formally accept responsibility for the risks identified. A POA&M is developed as part of the security authorization process to address weaknesses reported in risk assessments and security testing for organizational systems.

• HHS uses a system to manage POA&Ms. A POA&M generally identifies a System Owner (who could be the CIO or Hospital Director, for example) as the responsible point of contact. How much IT Administrators assist with the POA&M depends on what your ISO needs. IT Administrators generally have responsibility to fix or mitigate findings that are in the technical realm.

Page 9 of 9


POA&M


• The source authority for security control self assessments is detailed in the NIST SP 800-53 Revision 1. It corresponds with the security controls in NIST SP 800-53 Revision 3.

Page 1 of 9

System Security Testing



• Risk assessment or risk analysis is a process of identifying risks to agency operations (including mission, functions, image, or reputation), agency assets, or individuals. The process incorporates threat and vulnerability analysis. It includes determining the probability that a security incident could occur, the resulting impact, and additional security controls that would mitigate this impact.

• A risk assessment is a required part of a security documentation for Security Authorization. Risk assessments should be conducted during the initiation and development stage of the EPLC. Once the system is implemented, a risk assessment should be performed at least every three years or in the event of a significant change.

Page 2 of 9


Risk Assessment


• A PIA is an assessment process for identifying and mitigating the privacy risks posed by an information system. At a minimum, PIAs must analyze and describe the following:

– What information is to be collected;

– Why the information is being collected (e.g., to determine eligibility);

– Intended use of the information (e.g., to verify existing data);

– With whom the information will be shared (e.g., another agency for a specified programmatic purpose);

– What opportunities individuals have to decline to provide information (i.e., where providing information is voluntary) or to consent to particular uses of the information (other than required or authorized uses), and how individuals can grant consent;

– How the information will be secured (i.e., management, operational, and technological controls); and

– Whether a system of records is being created under the Privacy Act, 5 U.S.C. 552a.

Page 3 of 9


Privacy Impact Assessment (PIA)


• Security Control Assessment is the formal evaluation of a system against a defined set of controls. The guidance for security control assessments is described in NIST SP 800-53 Revision 1. This source corresponds with the security controls in NIST SP 800-53 Revision 3. Other types of system tests include self-assessments, audits, security reviews, vulnerability scanning, and penetration testing.

Page 4 of 9




• Vulnerability scanning is an automated process to identify vulnerabilities of computing systems in a network to determine if and where a system can be exploited and/or threatened. It seeks out security flaws based on a database of known flaws, testing systems for the occurrence of these flaws and generating a report of the findings.

• Characteristics:– Uses authentication and permissions;

– Permits in-depth scanning;

– Identifies the underlying cause of the vulnerability;

– Safe to implement – uses legitimate network services rather than “attack” targets; and

– Enables faster, more accurate scans.

Page 5 of 9


Vulnerability Scanning


• Advantages of Vulnerability Scanning – A proactive, non-intrusive method for

discovering weaknesses

– Abundance of free vulnerability scanning tools i.e. Nessus, HFNetChk, Microsoft Baseline Security Analyzer (MBSA)

• Disadvantages of Vulnerability Scanning – Can be quite expensive (though tools are

available, software and updates can be costly)

– Can have adverse effects

– Tools can cause a degradation in performance

Page 6 of 9


Vulnerability Scanning



Penetration Testing

• Penetration testing is testing in which an evaluator attempts to circumvent the security features of a system based on their understanding of the system design and implementation. The purpose is to identify methods of gaining access to a system by using common tools and techniques used by attackers.

• Characteristics:‒ Searches for clues to potential threats

– Intrusive by nature

– Runs malicious attacks against targets

– Susceptible to false positive

– Cannot find all vulnerabilities

– Easy to implement

Page 7 of 9


• Advantages of Penetration Testing – Ideal for testing detection and response

capabilities

– Can be used to determine the current security posture of an organization

• Disadvantages of Penetration Testing – Not a comprehensive evaluation of security

– Only as good as the tester

– Penetration testing is more comprehensive than vulnerability testing, however, it does not look at a broad scope of security posture of the organization It takes a different skill set to run an exploit found during a vulnerability scan

Page 8 of 9


Penetration Testing


• HIPAA is the Health Insurance Portability and Accountability Act. IT Administrators working with medical records systems need to be very aware of HIPAA, as people conducting HIPAA reviews may ask them questions about system operations and functionality.

Page 9 of 9


Health Insurance Portability and Accountability Act (HIPAA)


• The RMF process includes categorizing the information system, selecting security controls, implementing security controls, assessing security controls, authorizing the information system, and continuous monitoring.

• IT Administrators are most likely to be involved in continuous monitoring after a system has been received an authorization to operate.

Page 1 of 8

System Security Authorization

The Purpose of Risk Management Framework (RMF)


• A security control assessment is a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security authorization, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The results of a security control assessment are used to reassess the risks and update the security plan, thus providing the factual basis for an authorizing official to render a security authorization decision.

Page 2 of 8




• Security authorization is the official management decision, conveyed through the authorization decision document, given by a senior organizational official or executive (i.e., authorizing official) to authorize operation of an information system and to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.

Page 3 of 8


Security Authorization


• Significant changes are changes in the IT system or software applications that:

– Alter mission – Alter operating environment – Alter basic vulnerabilities of the IT system – Change protection requirements – Produce the occurrence of a significant violation or incident – Produce audit/evaluation findings that identify significant unmitigated risks

• Many significant changes are driven by Agency and National Security policies and regulations such as FISMA and Department of Homeland Security. These changes tell us how we must conduct business such as acquisition, protection levels, and risk assessments.

• The change can occur to:– Threats (a new adversary or a new virus, for example);– Vulnerabilities (a recently discovered “hole” in the programming); or – Technological Environment (a new hardware/software, a new storage area

network (SAN)).

Page 4 of 8


Significant Change


Page 5 of 8


Activities Included Within RMF


• Authorization is required before a system may process, store, or transmit agency data. An authorizing official/authorizing official designated representative, reviews the security authorization package. The authorizing official/authorizing official designated representative, will then give a system either an ATO or Denial of Authorization to Operate.

• An ATO signifies completion of an objective third party system evaluation and acceptance of any residual risk of the system to the agency. This means that the DAA takes responsibility if a security incident related to a known risk were to occur.

• Denial of Authorization to Operate: System is not granted an authorization to operate. The information system is not authorized to operate and is not placed into operation. If the system is currently in operation, all activity is halted. Failure to receive an authorization to operate indicates that there are major weaknesses or deficiencies in the security controls employed within or inherited by the information system. The authorizing official or designated representative works with the information system owner or common control provider to revise the plan of action and milestones to ensure that appropriate measures are taken to correct the identified weaknesses or deficiencies.

Page 6 of 8


Authorization Decision


• Triggers for reauthorization include significant changes in the IT system or software applications that: – Alter mission – Alter operating environment – Alter basic vulnerabilities of the IT system – Change protection requirements – Produce the occurrence of a significant

violation or incident – Produce audit/evaluation findings that

identify significant unmitigated risks

Page 7 of 8


Reauthorization


• NIST recommends:– RMF should be completed throughout the EPLC

– All individuals involved with the management and security of the system should be involved with the RMF process – defined roles and responsibilities are important

– RMF is not just a paper drill

– RMF should be a manageable effort when it is repeated using a consistent process

– The Authorizing Official must understand what it means to “accept the residual risk” for the system

Page 8 of 8


RMF Best Practices and Pitfalls


• Routine documentation, testing, and authorization are critical to successfully ensuring secure systems. Here are some key ideas from this topic:– Do you routinely document and test

your system when minor changes occur?

– Would you be able to act quickly if an incident occurred?

Page 1 of 1

Recap

Recap


This section describes the role of IT Administrators in securing systems:

•Disposition Phase Security•Roles•Configuration Management•User Access•System Monitoring•Disposal

Page 1 of 1

Agenda

IT Administrators and Secure Systems


• The Disposition Phase of the EPLC is comprised of a series of steps to retire or transition a system when it is no longer needed, and to securely and properly archive or dispose of its information. Note that the Disposition phase applies any time an existing service receives upgraded hardware and disposes of existing hardware.

• This lesson will cover the following topics:– Proper Disposal of System Components

– Media Sanitation Options

Page 1 of 3

Disposition Phase Security

Lesson Introduction


• System disposal has five parts as stated in NIST SP 800-64 Rev. 2:

– Building and Executing a Disposal/Transition Plan ensures that all stakeholders are aware of the future plan for the system and its information. This plan should account for the disposal / transition status for all critical components, services, and information.

– Information Preservation ensures that information is retained, as necessary, to conform to current legal requirements and to accommodate future technology changes that may render the retrieval method obsolete

– Media Sanitization ensures that data is deleted, erased, and written over as necessary to retain confidentiality

– Hardware and Software Disposal ensures that hardware and software is disposed of as directed by the Information Systems Security Officer

– System Closure ensures that the information system is formally shut down and disassembled.

Page 2 of 3


Disposal of System Components

• Media sanitization is important either at the end of the system’s life cycle or at any point when new hardware or media is replacing existing hardware or media.


• Before a system component is disposed of, it must first be sanitized which destroys all data by either clearing or purging it. Cleared data cannot be reconstructed using normal system capabilities but can be reconstructed with commercial software. Purged data can also be reconstructed, but only by using expensive techniques.

• Purging techniques include overwriting, degaussing (demagnetizing), and destruction. The method you choose depends on the sensitivity level of the data:

– Overwriting is accomplished with special software used to overwrite every bit in every sector of memory.

– Degaussing is more destructive and involves physically destroying the magnetic image

– Destruction is the most reliable technique since the media is taken to an approved facility for incineration orapplication of an abrasive substance.

• For additional information, see NIST SP 800-88, Guidelines for Media Sanitization

Page 3 of 3


Media Sanitation Options


• Some of the areas of greatest concern to many IT Administrators at HHS include: – Separation of duties– Configuration management– User access – System monitoring– Securely disposing of your system

• Earlier in the course, some of these same topics were discussed as legal or general context for system security management principles. This topic re-emphasizes key concerns that relate most closely to your role and reviews some of the information provided earlier.

Page 1 of 2

Roles

IT Specialists Roles and Responsibilities


• Your job as an IT Administrator gives you a great deal of technical influence over the system. To comply with Federal policies and regulations, and good practices, it is important to observe separation of duties guidelines. In general, individuals that are administering the system should not be responsible for auditing or reviewing the system or its controls.

Page 2 of 2

Roles

Separation of Duties


• Be sure you know the configuration management routine in your department and follow it consistently. Here is the guidance from NIST SP 800-128 DRAFT:

• An information system is typically in a constant state of change in response to new or enhanced hardware and software capability, patches for correcting errors to existing components, new security threats, and changing business functions, etc. Implementing information system changes almost always results in some adjustment to the system baseline configuration. To ensure that the required adjustments to the system configuration do not adversely affect the information system security, a well-defined security configuration management process is needed.

•The security configuration management concepts and principles described in this publication provide supporting information for NIST SP 800-53, Revision 3, Recommended Security Controls for Federal Information Systems and Organizations that include the Configuration Management family of security controls and other security controls that draw upon configuration management activities in implementing those controls. This publication also provides important supporting information for the Monitor Step (Step 6) of the Risk Management Framework that is discussed in NIST SP 800-37, Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach.

Page 1 of 1




• Access controls exist to permit only authorized access to the system and restrict users to authorized transactions, functions, and data. These controls are automated and ensure that only authorized individuals gain access to information system resources, that they are assigned an appropriate level of privilege, and that they are individually accountable for their actions. All users accessing the system are required to sign the HHS Rules of Behavior.

• At HHS, system access administrators or designees process all internal requests for access. Access is granted according to the most restrictive set of rights or privileges needed. The data owner is responsible for specifying the type of user access which may be approved. Each facility ISSO reviews all requests for access by non-facility users.

Page 1 of 4

User Access

Level of Access


• Rules of behavior: The Rules of Behavior describes the user responsibilities and expected behavior with regard to information system usage. The user should sign this document indicating that they have read, understand, and agree to abide by the rules of behavior, before they receive access to the information system.

• Access: IT Administrators monitor system access to ensure that there is not an excessive or unusual number of individuals receiving high level or administrator–level access to the system. This could indicate a lack of controls–including least privilege and “need to know” controls.

• Some positions may require a background check to be complete prior to obtaining access. The IT Administrator should have reasonable assurance that a check was conducted.

Page 2 of 4

User Access

Rules of Behavior and User Access


• Ongoing recertification of user access ensures system access is limited to those who have a current business purpose. Although the terms may sound similar, this is a different process than system recertification and reaccreditation.

• System user account status is reviewed by IT Administrators on a defined recurrence and reported to the ISSO and to supervisors/managers. Inactive accounts are terminated within an OPDIV-defined timeframe unless the user's supervisor provides written certification of the need for continuation of access. Accounts for separated employees, contractors, volunteers, or others no longer requiring access are terminated immediately.

Page 3 of 4

User Access

Monitoring User Access/Recertification


• It is important to terminate user access promptly when an individual has separated from HHS. Separations can be due to termination of employment, retirement, or transfer. Terminations can potentially be hostile situations.

• In general at HHS, for routine separations, termination of user access occurs within 24 hours of the separation. For potentially hostile terminations, access is terminated at the exact time of employee notification.

• Take time to discuss termination of access procedures with your supervisor if you do not know how this is handled for your system.

Page 4 of 4

User Access

Terminating User Access


• Continuously monitoring systems to detect or prevent intrusion is a role performed by most IT Administrators assigned to a system. Although it can be routine, it is vital to system security. Often, the intrusion detection and prevention function is built into the system.

• There are three types of automated tools:– An Intrusion Detection System (IDS) monitors

network traffic and local system activity for indications of attack and misuse.

– An Intrusion Prevention System (IPS) adds protection capability to the monitoring capability of traditional IDSs.

– An Intrusion Detection Prevention System (IDPS) is a critical part of any information security architecture and complements firewalls and vulnerability assessments.

Page 1 of 3

System Monitoring

Intrusion Detection and Prevention


• An Intrusion Detection Prevention System can monitor (and block as appropriate):– Traffic that firewalls cannot block, for example specific HTTP

traffic– Internal traffic for suspicious and malicious activity from

compromised internal computers – Traffic outside your external firewall to detect intrusion

attempts

Page 2 of 3

System Monitoring

Intrusion Detection and Prevention System


• Patching a system is important to maintaining security as the environment or the threat environment changes. When patches become available, it is wise to test the patch first on a test or development version of the system. This ensures that the patch doesn’t create a new issue while trying to solve the original issue.

Page 3 of 3

System Monitoring

Patching a System


• System disposal has three parts: – Information Preservation ensures that information is

retained, as necessary, to conform to current legal requirements and to accommodate future technology changes that may render the retrieval method obsolete

– Media Sanitization ensures that data is deleted, erased, and written over as necessary to retain confidentiality

– Hardware and Software Disposal ensures that hardware and software is disposed of as directed by the information system security officer

• (NIST SP 800-64 Rev.2: Security Considerations in the System Development Life Cycle)

• Media sanitization is important either at the end of the system’s life cycle or at any point when new hardware or media is replacing existing hardware or media.

Page 1 of 5

Disposal

System Disposal


• Take the following steps when disposing of a system:– Follow a consistent, standards-based

policy for the sanitization of HHS data processing media

– Follow procedures to ensure that all data processing media are appropriately sanitized and the operation is documented

– Consult your ISSO for guidance with IT Administrator responsibilities in the sanitization process

Page 2 of 5

Disposal

HHS Policy for Disposal


• HHS regulations are very clear and specific for procedures to securely dispose of systems and the data which has resided on them. Whether you are retiring a single magnetic disk, a typewriter ribbon, or an entire database, you and others charged with sanitization must take precautions to purge, incinerate, or otherwise destroy all traces of protected data.

• IT, biomedical, research staff, and others who are designated by local management to sanitize media, keep four requirements in mind. These four requirements are described in detail on the next slide.

Page 3 of 5

Disposal

Data Storage and Erasure


• Use the least destructive method for sanitizing IT equipment to foster re-utilization and minimize the generation of hazardous waste, including removing the entire recording surfaces by sanding or applying acid

• Ensure and certify in writing that only software and/or procedures approved by HHS policy are used to remove sensitive data from IT equipment

• Complete training in proper sanitization/disposal procedures• Ensure coordination with supervisors and the ISSO prior to IT

equipment leaving the facility for any reason when sanitization is required

Disposal

Requirements for SanitizationPage 4 of 5


• Disposing of systems is a predictable occurrence. Planning ahead for integrating security steps into the replacement process helps you securely and conscientiously manage both disposal and introduction of new hardware or software.

• Often, new hardware is purchased and required for immediate use. IT Administrators who are responsible for both installing new equipment and disposing of the old equipment can be caught in a time bind.

• Stories of media being disposed of without properly erasing all data have appeared in the news to the great embarrassment of business and government organizations, and have made individuals unnecessarily vulnerable.

• The lesson is clear: With all of the patient personal identifying information and medical information HHS collects, it is absolutely necessary to take special precautions in this area. Always take time to dispose of systems hardware and media properly!

Page 5 of 5

Disposal

Planning Time, Resources and Cost for Disposal


• In this topic we looked at aspects of the security roles played by IT Administrators that seem to cause the most discussion or difficulty. These responsibilities include:– Reporting and documenting incidents

– Controlling user access

– Configuration management

– Intrusion detection and prevention

– Patching system software

– Disposing of information systems (hardware and software) that are no longer needed.

Page 1 of 1

Recap

Recap


• At one time, IT Administrators were only responsible for traditional administrative tasks for systems they supported. The role of securing systems belonged to someone else. However, due to the ever-changing risk environment brought about by the interconnection of systems, all parties involved with systems during the EPLC have a role in securing them.

• This raises new challenges to IT Administrators who are the first line of defense once systems are operational. As illustrated in this course, IT Administrators play a significant role in systems protection throughout the EPLC. Upon learning about your security responsibilities, you are now better prepared to assist in securing HHS’ systems.

Page 1 of 1

Conclusion

Conclusion


• You have completed the Information Security for IT Administrators course.

Page 1 of 1

Course Completion

Congratulations


Glossary• Authority to Operate (ATO) - Permission given by a Designated Approving Authority to operate a

system; in a production environment.• Authorization — The official management decision given by a senior organizational official to

authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.

• Authorizing Official — A senior (Federal) official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

• Availability - The timely and reliable access to and use of information and an information system.• Confidentiality - The restrictions on information access and disclosure, including the protection of

personal privacy and proprietary information. • Configuration Management - A discipline applying technical and administrative direction and

surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

149


Glossary• Configuration Management Plan - A plan that describes the management controls involved in all

changes and updates made to a system that affects security. The plan includes all documentation supporting these changes and updates. This plan is maintained throughout the certification and accreditation process and updated according to system development life cycle activities.

• Contingency Plan - A plan developed and maintained by the business manager to ensure continued business operations. The plan is maintained for emergency response, back-up operations, and post-disaster recovery for an IT system, to ensure the availability of critical resources and to facilitate continuity of operations in an emergency situation.

• Controls - Controls are policies, procedures, and practices designed to provide a level of assurance that business objectives will be achieved and that undesired events will be prevented or detected and corrected.

• Disaster Recovery Plan - A plan that identifies recovery procedures in the event of natural or man-made disasters or catastrophes affecting the availability of a system. This plan is tested annually to ensure the continued effectiveness and adequacy of the plan.

• Federal Information Security Management Act (FISMA) - A 2002 act that mandates yearly audits of government IT security efforts to bolster computer and network security.

• Health Insurance Portability And Accountability Act (HIPAA) - Requires national standards for electronic health care transactions and includes privacy and security provisions to ensure information is used appropriately.

• Incident - A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard computer security practices.


Glossary• Independent Validation and Verification - Testing of a system performed by a third party outside the

original development team.

• Independent Assessor- Any individual or group capable of conducting an impartial assessment of security controls employed within or inherited by an information system.

• Information Security - The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

• Information System Security Officer (ISSO) - Monitors the implementation of security standards and policy.

• Integrity - Guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity.

• Interconnection Security Agreement (ISA) - An agreement established between the organizations that own and operate connected information systems to document the technical requirements of the interconnection. The ISA also supports a Memorandum of Understanding or Agreement (MOU/A) between the organizations.

• Management Controls - System security safeguards that focus on policy, guidelines, and standards for using and managing the system.

• Operational Controls - System security safeguards that primarily are implemented and executed by people (as opposed to the system).

151


Glossary• Personally Identifiable Information (PII) - Information which can be used to distinguish or trace an

individual's identity, such as their name, Social Security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.

• Plan of Action and Milestones (POA&M) - A document that identifies tasks needing to be accomplished, and details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.

• Privacy Impact Assessment (PIA) -An analysis of how information is handled: 1) to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy; 2) to determine the risks and effects of collecting, maintaining and disseminating information in identifiable form in an electronic information system; and 3) to examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.

• Risk - A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.

• Risk Assessment - The process of identifying risks to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. This term is synonymous with risk analysis.

152


Glossary• Risk Management Framework - The new six-step process established in NIST SP 800-37 Rev.1, which

is the transformation of the previous certification and accreditation (C&A) process. The RMF changes the traditional focus of C&A as a static, procedural activity to a more dynamic approach that provides the capability to more effectively manage information system-related security risks in highly diverse environments of complex and sophisticated cyber threats, ever-increasing system vulnerabilities, and rapidly changing missions.

• Sanitization - A general term referring to the actions taken to render data written on media unrecoverable by both ordinary and, for some forms of sanitization, extraordinary means.

• Security Category - The characterization of information or an information system that is based on an assessment of the potential impact that a loss of confidentiality, integrity, or availability would have on organizational operations, organizational assets, or individuals.

• Security Control Assessment– The testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.

• Security Objectives - Confidentiality, integrity, and availability.

• System Development Life Cycle (SDLC) - The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation.

153


Glossary• System Owner - An individual responsible for the proper technical and business functioning of an IT

system. System owners have ultimate authority over the operation and maintenance of an IT system. System owners work with system managers and business managers to ensure that the system is providing the automation support required to perform their functions.

• Security Plan – Formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements.

• Technical Controls - System security safeguards that are primarily implemented and executed by the system through mechanisms contained in the hardware, software, or firmware components of the system.

• Threat - Any circumstance, event, or act that could cause harm by destroying, disclosing, modifying, or denying service to information resources.

• Vulnerability - A weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

• Security Controls - The management, operational, and technical safeguards and countermeasures prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.

• Senior Official for Privacy (SOP) – The senior official within HHS responsible for Department-wide Adherence to the Privacy Act of 1974.

154


References• HHS Information Security Guidance

– The HHS-OCIO Policy for Information Systems Security and Privacy is available on the HHS Cybersecurity Program web portal at http://intranet.hhs.gov/it/cybersecurity/policies_by_document_type/index.html. (Note: You must be inside the HHS firewall to access).

• Security Resources from the National Institute of Standards and Technology (NIST)

• There are three types of publications most commonly used:

– Federal Information Processing Standards (FIPS) are mandatory standards developed by NIST that apply to all non-military government agencies and government contractors.

– Special Publications (SPs) provide industry best practice guidance on implementing information security.

– ITL Bulletins are issued prior to the release of a SP and provide summaries of the key concepts in the SP.

155


ReferencesReference these NIST documents for more information:

– FIPS 199, “Standards for Security Categorization of Federal Information and Information Systems” (February 2004)

– FIPS 200, “Minimum Security Requirements for Federal Information and Information Systems” (March 2006)

– SP 800-88 , “Guidelines for Media Sanitization” (September 2006)– SP 800-65, “Integrating Security into the Capital Planning and Investment Control

Process” (January 2005)– SP 800-64 Rev. 2, “Security Considerations in the System Development Life Cycle”

(October 2008)– SP 800-61 Rev. 1, “Computer Security Incident Handling Guide” (March 2008) – SP 800-60 Rev. 1, “Guide for Mapping Types of Information and Information Systems to

Security Categories: (2 Volumes) - Volume 1: Guide; and Volume 2: Appendices” (August 2008)

– SP 800-53A Rev. 1, “Guide for Assessing the Security Controls in Federal Information Systems and Organizations” (June 2010)

156


ReferencesNIST Documents (continued)

– SP 800-53, “Recommended Security Controls for Federal Information Systems” (ITL Bulletin May 2005)

– SP 800-47, “Security Guide for Interconnecting Information Technology Systems” (ITL Bulletin February 2003)

– SP 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems” (ITL Bulletin May 2004)

– SP 800-34, “Contingency Planning Guide for Information Technology Systems” (ITL Bulletin June 2002)

– SP 800-30, “Risk Management Guide for Information Technology Systems” (ITL Bulletin February 2002)

– SP 800-26, “Security Self-Assessment Guide for Information Technology Systems,” November 2001 (ITL Bulletin September 2001)

– SP 800-18, Rev. 1, “Guide for Developing Security Plans for Information Technology Systems,” February 2006 (ITL Bulletin April 1999)

157


ReferencesAdditional NIST publications provide additional insight on implementing

information security:

– Information Security in the SDLC – Brochure that encapsulates the security activities throughout the NIST Systems Development Life Cycle in a full-color chart showing the SDLC, security activities, and NIST documents.

158