u.s. department of health and human services may 2011 information security for managers 1

U.S. Department of Health and Human Services

May 2011

Information Security for Managers

1


Table of Contents

2

• Welcome• Introduction • Safeguarding the HHS Mission• Planning for Security Throughout the EPLC• Initiation• Acquisition/Development• Implementation/Assessment• Operations/Maintenance & Disposition


Welcome

Welcome to "Information Security for Managers“

As a Manager at the Department of Health and Human Services (HHS), you play a vital role in assuring the protection of HHS systems and information assets. To aid you in carrying out your role, this course will address a risk-based approach to the planning, implementation, and management of information security within the Enterprise Performance Life Cycle (EPLC).

3


Introduction

Your role in securing systems

• The following are managerial roles, which have significant security responsibilities (SSR) with respect to the protection of systems. As you read through the role descriptions, you will determine your security responsibilities during the EPLC:

– Program Manager/Project Manager

– System Owner

– Data Owner/Business Owner

– Other Information Technology Manager

• The description of your responsibilities will help you identify the security activities for which you are responsible or which require your involvement.

4


Introduction

Managerial Roles• Program Manager/Project Manager

– Evaluating proposals, if requested, to determine whether proposed security solutions effectively address agency requirements as detailed in acquisition documents.

– Ensuring that security-related documentation at each phase of the EPLC meets all identified security needs.

– Notifying the OPDIV CISO of actual or suspected computer-security incidents, including personally identifiable information (PII) and protected health information (PHI breaches).

• System Owner– Ensure that security is planned for, documented, and integrated into the EPLC from the

initiation phase to the disposal phase. – Determine, in coordination with the Program Executive and Data Owner/Business Owner,

the appropriate security controls and identifying resources to implement those controls. – Ensuring provision of adequate funding to implement the security requirements in the

EPLC for systems that fall within the management authority of the Program Executive.– Accepting accountability for the operation of a system(s) in support of the overall Program

mission.

5


Introduction

Managerial Roles

• Data Owner/Business Owner

– Gathering, processing, storing, or transmitting Department data in support of the Program’s mission;

– Ensuring that system owners are aware of the sensitivity of data to be handled, and ensuring that data is not processed on a system with security controls that are not commensurate with the sensitivity of the data.

– Notifying the OPDIV Chief Information Security Officer (CISO) of actual or suspected computer-security incidents, including PII and PHI breaches.

• Other Information Technology Manager

– Supervise, lead, administer, develop, deliver, and/or support information systems and services, inclusive of the security of systems and services.

• Significant Security Responsibilities

– Responsibilities associated with a given role or position, which, upon execution, could have the potential to adversely impact the security or privacy posture of one or more HHS systems.

6


Safeguarding the HHS Mission

The Challenge of Information Security• The American people depend on HHS to keep information

appropriately confidential, with integrity, and reliably available. You help promote HHS’ commitment to better health and well-being by ensuring our information is kept secure.

• As an HHS Manager, you play a pivotal role in ensuring information security throughout the Enterprise Performance Life Cycle (EPLC). Once you understand the risks HHS systems are exposed to and take steps during each phase of system development to ensure security, you will be a model for others to follow.

• Remember, you are part of a network of professionals who are all facing similar challenges. Reach out to your colleagues in HHS, in the Federal Government, and throughout the information security industry. With this wealth of experience, you can ensure information security at HHS is just businessas usual.

7



Vulnerabilities and Threats• 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.

8



Threats• A threat is the potential to cause unauthorized disclosure, changes, or destruction

of an asset. Unauthorized disclosure can cause a breach of confidentiality. Unauthorized changes can cause an integrity failure. Unauthorized destruction can cause a loss of availability.

• Two types of threats exist:

– Natural threats are those initiated by the environment. They generally cause destruction of information resources. Threats of this type include earthquakes, storms and floods, tornados, lightening, and blizzards.

– Man-made threats are those initiated by people. Threats of this type include unauthorized intrusions, denial of service (DoS), accidents and omissions, and criminal activity.

9



Vulnerability• A vulnerability is any flaw or weakness that can be exploited and could result in a

breach or a violation of a system’s security policy.

• Some examples of vulnerabilities include:

– Poorly communicated or implemented policy

– Inadequately trained personnel

– Improperly configured systems or controls

10



Identifying Risk• Risk is the likelihood that threat will exploit a

vulnerability. For example, a system vulnerability may be to not have a backup power source. A threat, such as a thunderstorm, could create an unexpected power surge causing a system outage.

• As you assess risk, look at vulnerabilities that could arise due to:

– System architecture;

– Behavior of unauthorized users;

– Behavior of authorized users (misuse and mismanagement);

– Interconnection with, and manipulation by, other systems

11



Risk Management• Risk management is a principle for addressing the

possibility that future events may cause adverse effects. Identifying the need to minimize risk in the early stage of a project helps reduce the likelihood that something catastrophic may happen in the future to bring down the system.

• The strategies for mitigating risks must be chosen and implemented carefully. After all, you and HHS have a set amount of resources—time, people, and money—and the decisions you make impact the agency throughout the life of the system.

12



Security Controls• Security controls are chosen and implemented according

to the likelihood that a threat will exploit a vulnerability, and how much damage would result. The National Institute of Standards and Technology (NIST) guidance, Special Publication (SP) 800-53 Rev. 3, Recommended Security Controls for Federal Information Systems and Organizations, requires groups controls into three classes:

– Management controls involve policy or procedure to plan and assess risks

– Operational controls rely on people to perform certain actions to ensure security

– Technical controls are hardware and software functions that govern access to the system

• Controls are not implemented in isolation, but interconnect to form a security strategy that protects HHS information assets.

13



NIST SP 800-53 Rev. 3• Within the three security classes defined in NIST SP 800-53, security controls are

further organized into 18 security families.

• Management Control Families include:

– Security Assessments and Authorization

– Planning

– Risk Assessment

– System and Services Acquisition

– Program Management

14



NIST SP 800-53 Rev. 3• Operational Control Families include:

– Awareness and Training– Configuration Management– Contingency Planning– Incident Response– Maintenance– Media Protection– Physical and Environmental Protection– Personnel Security– System and Information Integrity

• Technical Control Families include: – Access Control– Audit and Accountability– Identification and Authentication– System and Communications Protection

15



Security is an Integrated Solution 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.

16



Policy

• To ensure that the Federal Government develops its technological infrastructure and stewards its information assets wisely, various policies govern how HHS handles information security.

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

17



Policy

Other policies you should familiarize yourself with include:– The President’s Management Agenda (PMA) “report card” – Previous

Administration's initiative to make government more "citizen-centered, market-based, and results-oriented". The Office of Management and Budget (OMB) scores federal agencies on five areas, among which are financial accountability and e-government.

– Clinger-Cohen Act – Common name for the Information Technology Management Reform Act (ITMRA) that requires Federal agencies to use performance-based management principles for acquiring IT investments. It mandates the use of a Federal Enterprise Architecture (FEA), which is a common methodology for IT acquisition that helps measure the performance of major investments, describes the data and information used, and categorizes the type of technology implemented.

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

– Exhibit 300 – HHS submits an “Exhibit 300” to the OMB each year and they use it to assess investments and make funding decisions. The Exhibit 300 must provide a complete assessment of IT and security investments and justify funding to support annual and life-cycle initiatives.

18



People

• You are part of a network at HHS which ensures information is secured. Knowing the responsibilities to address your information security concerns and the concerns of others helps maximize communication and accountability.

• 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 system planning, budgeting, investment, performance, and acquisition.

– Chief Information Security Officers (CISOs) develop enterprise or Operating Division (OPDIV) standards for information security.

– Contracting Officers provide the authority to enter into, administer, and terminate contracts and make related determinations and findings.

19



People

– 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.

20



Procedures

• Proper procedures should be developed in order to address information security issues and incidents. Each OPDIV provides guidance to ensure that staff/personnel is able to locate the policies/procedures when needed.

• Complying with the best practices and procedures provided by senior management helps prevent costly mistakes that can harm an organization’s financials, classified information systems and security procedures.

21



Products

• You must consider security when dealing with all systems that manage information. A system can involve products from a broad spectrum—as simple as off-the-shelf software packages or as complex as an enterprise-wide web-based application.

• All components — hardware, software, interconnections, facilities, infrastructure (e.g., power, temperature), etc.— are all part of the “product” and must be considered when thinking about security.

22



The Path to Information Security Starts Now

• Information security is vital to HHS and our customers, the American people. Success depends on how you approach project management. The remaining topics in this course provide guidance and resources to help you on your journey through the EPLC:

• Security & the EPLC - Plan for security activities during the life of a system

• Initiation - Identify system and security requirements

• Acquisition/Development - Define how to implement selected controls and develop the system

• Implementation/Assessment - Inspect and approve a system through Security Authorization

• Operations/Maintenance & Disposition - Monitor the system and manage updates and disposal

23


Planning for Security Throughout the EPLC

Managing Risk from the Beginning

• Imagine that you are building a new house. You trust the builder to include all the necessary components, such as the foundation, framing, wiring, plumbing, and walls. What if a couple of days before you moved in, the builder told you that he had forgotten to install the plumbing? Obviously, the time and effort involved at this point is substantial and will considerably delay your move-in date.

• Security is as important to HHS systems as plumbing is for your house. And building security into a system early in its design is less expensive and time-consuming than trying to remediate a system that isn’t secure. Planning for security enables your project’s success by dedicating sufficient time, money, and people. Policy, documentation, and a review of requirements help you ensure that all functions required by a system are implemented correctly.

24



Overview of Security Activities

To manage system development efficiently, project managers follow a SDLC model. The HHS EPLC mirrors the life cycle used by NIST. NIST's model incorporates a risk management framework with security activities for each phase.

25



Security and Project Management

• Integrating security activities into the EPLC works to your advantage. Such a model benefits you and HHS by ensuring the most cost-effective security controls are chosen and implemented. It also increases the consistency and standardization of controls implemented throughout the agency, reducing operational costs.

• Thinking of security early in the EPLC ensures vulnerabilities are addressed before they can disrupt business and helps risk management become part of the HHS culture.

26



Planning Guarantees Success

• Before you can begin building a system, you need to look at the system requirements, regulatory compliance requirements, and the enterprise environment.

• The system you develop will have a sensitivity level depending on these factors. For instance, service, benefit, and medical information systems have different acceptable risk exposure and sensitivity levels. An analysis provides the backbone of your planning efforts.

• Understanding how information in your system will affect and be affected by the enterprise governs the security strategy. It also affects the allocation of the resources you need to offset and mitigate risks.

27



Sensitive Information

At HHS, sensitive information is information that has a degree of confidentiality such that its loss, misuse, unauthorized access, or modification could compromise the element of confidentiality and thereby adversely affect national health interests, the conduct of HHS programs, or the privacy of individuals entitled under The Privacy Act or the Health Insurance Portability and Accountability Act (HIPAA).

28



Project Milestones & Timelines

• With the many possible risks that HHS systems are subject to, the earlier that security is implemented in a project’s schedule, the better the system will be protected. With the early and continued incorporation of security during a project’s EPLC, surprises affecting system deployment are minimized.

• Unexpected work can potentially add thousands of hours of labor, which takes away from improving and maintaining the enterprise. Careful planning in the early stages of system development optimizes the budget and human resources needed to keep the system running as intended.

29



Capital Planning• The HHS Capital Plan (hereafter “the Plan”) maps out

how the HHS budget will be spent in the next five years. The Plan is developed in accordance with the NIST process summarized in the image shown here. In addition to the IT vision and investments, the Plan identifies and prioritizes remediation for current security weaknesses. The Plan also provides justification for individual assets and details security functions that are supported. As you identify security requirements for a system, verify that these map to the current plan.

• While forecasting new IT needs and security requirements, include these as the next IT Capital Plan is drafted. Remember to account for and document all costs throughout the EPLC. This will help prioritize and steer IT capital spending toward achieving HHS’ assurance goals.

30



Data and Reporting• Measuring the performance of IT security efforts helps

HHS improve its customer service and accountability to stakeholders and ensure the appropriate level of mission support. Essentially, the results of your data collection form the baseline for the capital planning process.

• Continuous performance measurement also meets regulatory and financial reporting requirements. By quantifying program results and collecting data incrementally, you will be prepared to respond quickly to these needs.

• You’ll need to identify data that can be realistically obtained from existing processes and data repositories. Individual IT investment assessments should then be aggregated across HHS to show which are proving most and least effective. This will reveal the gap between the actual versus the desired security state and help determine where to prioritize resources.

31



Reporting Requirements The following laws require Federal agencies to report on IT security performance

(refer to the References listing for more information):

– Clinger-Cohen Act

– Government Performance Results Act (GPRA)

– Federal Information Security Management Act (FISMA)

32



Quantify Program Results Using data to show the effectiveness of security efforts helps improve program

efficiency and effectiveness. For instance, the timeliness of security service delivery and operational results experienced by security program implementation both demonstrate in real terms how security impacts HHS business goals.

33



Data Sources• Collecting data on security metrics should be as automated and non-intrusive as

possible. A mature metrics program will provide useful and relevant data such as:– Incident handling reports

– Testing results

– Network management logs and records

– Audit logs

– Network and system billing records

– Configuration management

– Contingency planning

– Training records

– Security Control Assessments and Security Authorization

• If these types of data are not available, consider using some of these alternatives:– Plan of Action and Milestones (POA&M)

– Incident statistics

– Internal security reviews

– General Accounting Office (GAO) and Inspector General (IG) audit findings

– Risk assessments

34


RECAP

Security in the EPLC• Information security and risk management start from

the beginning of the EPLC and are continual processes throughout a system's life cycle. Careful and methodical planning for security activities will reduce surprises in later and more costly stages of development.

• Inclusion of security requirements in the capital planning process ensures that sufficient resources will be available for every IT project required by HHS.

• Now that you have learned about overall planning for security within the EPLC, we will examine the key security activities and considerations for each phase composing the EPLC.

35


Overview

The need to minimize Risk• Risks are not all equally dangerous. Some need to be

eliminated while others may be minimized to an acceptable level of residual risk. For instance, you should restrict which users will have access to the system and establish consequences for misusing information. Obviously, you cannot bar all users from the system. You must ensure the minimum level of security controls are implemented to reduce the residual risk to an acceptable level.

• Understanding the risks to system development, maintenance, and management helps you develop a strategy to allocate resources for security. It is more cost-effective to catch and correct system vulnerabilities before the system is fully developed than to need costly reworking and testing. This leaves more money available for HHS to pursue its mission.

36


Overview

Residual RiskThe risk remaining after the implementation of new or enhanced controls is residual risk. Practically no IT system is risk-free, and not all implemented controls can eliminate the risk they are intended to address.

37


System Requirements

Preliminary Risk Assessment• During the Initiation Phase, identified risks are used to

support the development of system and security requirements. The security requirements identified by the security categorization process (Federal Information Processing Standard (FIPS) 199 and NIST SP 800-60) are used to design and develop security controls.

• Risk management is defined by NIST SP 800-30 Rev. 1, Risk Management Guide for Information Technology Systems, as an habitual and continuous process that is performed throughout the EPLC. Risk assessments are used to determine the extent of the potential threat and the risk associated with a system. A risk assessment should be performed in each phase of the EPLC and is vital to develop the Security Plan. It helps determine whether appropriate security controls have been identified and implemented to sufficiently mitigate system risk.

38


System Requirements

System Functionality• To properly secure a system, you must understand the

functionality it will enable and support. As a system is further conceptualized, consider the security impacts. This will help you identify both sources of risk and ways to mitigate that risk.

• Early analysis may also lead you to discuss possible changes in functionality, if some risk cannot be eliminated or accepted.

39


System Requirements

System Boundaries and Components• As you design a system, you need to establish and define

what the “system” is; that is, which components you are going to consider as part of the system and which are outside the scope of your development effort. This will help you determine the security risks and solutions.

• Consider the needs of the enterprise when developing a new system. For example, the system should not create vulnerabilities or unintended interdependencies in other systems, nor should it decrease the availability of other systems. Also, the security specifications for the new system should match the current state of the enterprise, maintain the security posture of the enterprise, and be documented and communicated clearly to the entire team.

• Finally, consider if your system will interface with external systems. If so, additional security measures must be implemented.

40


System Requirements

System Security Functional Requirements• While functional requirements describe what a system is

expected to do, system security requirements (SSR) describe protective measures that must be implemented to ensure proper execution of the services, tasks, or functions the system is required to perform. SSR are derived from the combination of system functionality, the protection required to secure these functions, and laws, and regulations that govern HHS systems. The environment in which the system will reside, as well as the types of users that are expected to interact with the system play a large part in determining which security requirements are relevant to the system.

• Determining the security functional requirements involves identifying appropriate controls to mitigate the risks associated with providing the desired functionality. Documenting this process will provide assurance that the security functions will work correctly and effectively.

41


Categorizing System Security

Security Categorization• How much do HHS and American citizens rely on this

system? Will HHS be able to accomplish its mission and meet its objectives if this information is compromised?

• These questions should be asked during the Initiation Phase to help drive selection of the security categories. The answers will determine the impact on HHS in the event data is lost or inappropriately accessed or changed. Assuming the system is not a national security system, a security category for the system must be assigned using FIPS publication 199 and NIST SP 800-60.

• Based on the results of the security categorization, youassign a Low, Moderate, or High level of security to the three security objectives: Confidentiality, Availability, and Integrity.

42



Security Categorization• National Security System

– Use NIST SP 800-59, Guideline for Identifying an Information System as a National Security System, to determine if a system qualifies as a national security system.

• FIPS 199

– FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, provides the standardized approach for establishing security categories. FIPS 199 requires HHS to categorize their information systems as low, moderate, or high-impact for the security objectives of confidentiality, integrity, and availability. NIST SP 800-60, Guide for Mapping types of Information and Information Systems to Security Categories, is essential to the security categorization process.

43



Security Categorization• FIPS 200

– FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, specifies minimum-security requirements for Federal information and information systems that are not national security systems. FIPS 200 also includes a risk-based process for selecting security controls necessary to satisfy these requirements. The security controls that FIPS 200 references are located in the NIST SP 800-53 Rev. 3.

• NIST SP 800-53

– Used in conjunction with FIPS 199 and FIPS 200, NIST SP 800-53 Rev. 3, Recommended Security Controls for Federal Information Systems and Organizations defines the exact controls to be used in securing a system. There are Low, Moderate, and High impact baselines associated with NIST SP 800-53 Rev. 3.

44



Security CategorizationNIST SP 800-60 Rev. 1

– NIST SP 800-60 Rev. 1, Guide for Mapping types of Information and Information Systems to Security Categories, provides guidelines for mapping information to security categories.

• Volume I specifies the basic guidelines for mapping types of information and information systems to security categories.

• Volume II contains the appendixes, including security categorization recommendations for mission-based information types and rationale for security categorization recommendations.

• The SP 800-60 Rev. 1information types and security impact levels are based on the OMB Federal Enterprise Architecture Program Management Office’s Business Reference Model 2.0, inputs from participants in NIST SP 800-60 workshops, and FIPS 199. The prerequisite role played by security categorization in selection of SP 800-53 Rev. 3 security controls, and the importance of security controls in the protection of Federal information systems make this an important resource.

45



The High Water Mark• Based on FIPS 200, you choose the security controls in

NIST SP 800-53 Rev. 3 that correspond to the “high water mark”— the highest score assigned to any of the objectives . For example, if the system has a Low confidentiality, a High integrity, and a Moderate availability categorization, the system will use the High control guidance.

• The new system may also affect the existing infrastructure. For example, adding a system with High security categorization into an existing network environment that is currently certified for Low impact systems will require an upgrade to the network controls. Carefully consider how this system will be deployed to ensure it does not adversely impact the environment in which it will operate.

46



Security Controls• Based on the Low, Moderate, or High security

categorization of your system, you must implement the corresponding prescribed minimum baseline security controls. This set of controls represents a starting point for determining the appropriate safeguards and controls required for HHS systems. The desired level of protection may require additional controls beyond these minimum requirements. Baseline security controls are initially documented in the preliminary risk assessment and are meant to be expanded as additional risks are identified.

• Security controls commensurate with FIPS 199 and 200 as well as laws and regulations must be selected and employed for every system. Such requirements, along with HHS’ commitment to protecting the confidentiality, integrity, and availability of its information and systems, drive the development of security controls across all IT programs.

47


Assuring System Security

Security Plan• The Security Plan is a critical document that describes the

system’s overall security posture and the specific controls that are or will be implemented for the system. Like many agencies, HHS uses NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems, which has a sample Security Plan for reference. The Security Plan describes where and how each security requirement is met.

• A Security Plan should be created during the system design stage. At this time, it will identify the controls that will be implemented as the system is built. The Security Plan should be refined in each phase of the EPLC.

48



Security PlanThe Security Plan includes:

– System characterization and boundary definition

– The system’s overall security categorization and sensitivity

– Management, Operation and Technical security controls implemented or planned

49



Contingency Plans• You can’t prevent every risk. Therefore, you need to

ensure HHS business operations continue unhampered in the event the system is negatively affected. This effort is called business assurance or continuity of operations planning (COOP). A key aspect of COOP is contingency and disaster planning.

• Contingency planning helps ensure that information handled by the system will continue to be available even if the system is out of service. It involves examining the business impact if the system goes offline, identifying preventive controls, and documenting a recovery approach to rapidly return the system to full service. Disaster planning involves preparing for a major system outage or catastrophic failure that lasts more than 72 hours.

50



Preventive ControlsPreventive controls depend on system type and configuration and could include:

– Uninterruptible power source (UPS) to provide short-term backup power

– Generator to provide long-term backup power

– Air conditioning system that provides sufficient cooling

– Fire detection and suppression system

– Moisture sensors

51



Privacy Impact Assessment• Many HHS systems collect personally identifiable

information (PII), data that can be used to uniquely identify an individual. If a system collects PII, HHS and all Federal agencies are required to perform a Privacy Impact Assessment (PIA).

• A PIA identifies the PII collected by the system, describes the impact that the system has on personal privacy, and plans for how privacy will be ensured.

• In addition, PIAs confirm that HHS only collects enough PII to administer a program, uses the information for the purpose intended, collects the information in a timely and accurate manner, and protects and retains the information only as long as necessary. Once the information is no longer needed, it will be securely removed from the system.

52



Security Control Assessments• FISMA requires HHS to assess the security controls of

each system at a minimum frequency of yearly. Each security control within a system is not required to be tested annually. As a result, a subset of security controls should be incorporated into the annual assessment.

• Such annual security control assessments (SCAs) take the form of an independent security control assessment the year of a system's initial authorization . Afterwards, a SCA can draw upon continuous monitoring activities (i.e., vulnerability assessments, self-assessment) to test a portion of a system's security controls.

• HHS must follow NIST SP 800-53A Rev. 1 , Guide for Assessing Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans, when conducting annual and continuous monitoring SCAs.

53



Plan of Actions and Milestones (POA&M)All system security weaknesses identified during a SCA must be included and tracked in a plan of action and milestones (POA&M). The POA&M helps you report on and prioritize security needs so that they may be corrected. SPORT is the tool used by HHS to complete and track POA&Ms that are submitted quarterly to OMB. OMB guidance also requires POA&Ms to be addressed as part of the OMB Exhibit 300 preparation process.

54


RECAP

Risk Management Using Security Controls• Starting out on the right foot involves assessing the

potential system risk as you gather information about the system and the environment in which it will function.

• Also within the Initiation Phase, FIPS 199 and NIST SP 800-60 are used to determine the system's security categorization. This allows for identification of the baseline security controls requisite for the system, as specified by FIPS 200 and NIST SP 800-53 Rev. 3.

• Identification of potential risks and security requirements and controls at this time supports incorporation of security early in the EPLC.

55


Overview

Refine and Develop the Security Controls• Within the Acquisition and Development Phase, the

security controls are ready to be designed, alongside design of the system. Following design, security controls are procured and/or developed as system elements are developed.

• Complete these activities to design, acquire, and develop the security controls:

– Refine the security controls– Perform a cost-benefit analysis of selected controls– Develop the Security Assessment Plan– Document and obtain the appropriate signatures for any

needed Interconnection Security Agreements (ISAs)– Refine the Security Plan, Risk Assessment, and

Contingency Plan

56


Refine the Security Controls

Security Control Refinement• While there may be several different ways to

implement a control, you must decide which way is best based on the risk assessment and cost benefit analysis. The control that is implemented must be able to prevent or minimize the risk to an acceptable level.

• NIST SP 800-53 Rev. 3 specifies which controls must be implemented based on the system’s security category. However, you must determine how each control will be developed for the system. Security control selection is derived from the risk assessment and is commensurate with the potential impact to HHS, if security is breached.

• You must consider many aspects as you weigh the pros and cons of various solutions.

57



ConsiderationsSome of the many issues you need to consider are:

– Effectiveness of each solution in protecting the system and network

– Legislation and regulation

– HHS and OPDIV policy

– Operational impact

– Effect of the controls on the operation of the system

– Feasibility of introducing the control into the system and network safety and reliability

58



Cost-Benefit Analysis of Controls• Resource allocation cannot happen until a cost-benefit

analysis (CBA) for the proposed controls is completed. A CBA indicates which controls provide the required level of security for the best value. Life cycle costs, such as the resources needed to provide upgrades, patches, and training for personnel, must be considered. Sometimes, one solution will reduce many risks and although it may be more expensive than other options, it may provide more value.

• Often, the cost of implementing a control is more obvious than the cost of not implementing it. The complete analysis provides a cost justification for implementing the selected controls. You may find that the cost to implement some controls results in the need to revise or eliminate some of the desired features of the system. Involve senior management if there is a conflict between critical features and security controls or if implementing a control impacts agency-wide policy or procedure.

59


Developing and Assessing the System

System and Security Control Development• As development of the system now proceeds, identified security controls are

included in the system architecture.

• During this time, the development team will work to ensure that the system meets its desired level of risk mitigation.

60



Configuration Management and Security• Systems are always in a state of change, from initial

development to post-deployment upgrades to changes in the enterprise and new threats posed to the environment. These changes can all impact the security of the system. A Configuration Management (CM) Plan establishes a baseline of the system hardware, software, and firmware components. In addition, it helps you plan how to maintain security as these changes occur – beginning in the Development Phase of the EPLC.

• CM helps you avoid or quickly correct common problems with system changes. CM also supports Security Authorization since you will have documented system changes and an assessment of potential impacts on the security of the system. Significant system changes may even require you to revise the security assessments and documentation for the system.

61



Common Configuration ProblemsCommon problems with system maintenance include:

– Failed changes: The production environment is used as a test environment, and the customer is the quality assurance team.

– Unauthorized changes: Engineers do not follow change management process, making mistakes harder to track and fix.

– No preventive work, making repeated failures inevitable: Average time to repair may be improving, but without root-cause analysis, the organization is doomed to fix the same problems over and over.

– Configuration inconsistency: Inconsistencies in user applications, platforms, and configurations make appropriate training and configuration mastery difficult.

– Security-related patching and updating: Understanding the configuration ensures applying patches does not compromise the system.

– Too much access: Too many people have too much access to too many IT assets, causing too many preventable issues and incidents.

62



Significant Security ChangesSignificant changes may require a reevaluation of:

– Risks

– System Security Plan

– FISMA survey

– Security controls assessment

– Security Authorization package

63



SCA Plan and Interconnection Agreements• Preparing a SCA Plan and Interconnection Service

Agreements (ISAs) further define safeguards that will ensure the system operates securely.

• An ISA specifies the need, security requirements, and technical safeguards for connecting two systems. It is adjudicated and signed by the respective Authorizing Official/Authorizing Official Designated Representatives from both systems.

• The SCA Plan will validate that the security controls are implemented correctly, operating as intended, and providing the desired outcome. The SCA Plan should be developed to test all security controls of the system. NIST SP 800-53A Rev. 1, Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans, provides guidance for creating security assessment plans, performing the tests, and documenting the results.

64


RECAP

Development of a Secure System• HHS must select and employ security controls for its

systems that comply with stated laws and regulations. These requirements drive the selection of security controls to protect the confidentiality, integrity, and availability of HHS information.

• Baseline controls associated with a system's security categorization provide a foundation for additional controls that may be necessary to ensure adequate protection. A Cost Benefits Analysis (CBA) identifies the best mix of controls. A Security Assessment Plan outlines the methodology for testing and evaluating system controls.

• Upon completion of the Acquisition and Development Phase, the system is fully developed with a cost-effective blend of security controls that are ready to be tested for effectiveness.

65


Overview

Security Controls Testing and Implementation

• At this point, the system and its security controls have been developed. Next, the controls must be tested to determine their effectiveness to protect the system and the HHS enterprise.

• Afterwards, the system will enter the Risk Management Framework stage where the controls will be assessed and affirmed and a decision will be made whether the system can be operated in the risk environment.

• If the system is authorized, the system and its operation will transfer from the Project Manager to the System Owner.

66


Overview

Control Testing and Evaluation• Security controls must be tested using the Security

Assessment Plan prior to deploying the system to make sure the controls implemented are effective and that they provide the necessary level of assurance.

• To ensure objectivity, use Independent Validation and Verification (IV&V). IV&V is a method of using a testing team independent of the system development team to perform the Security Assessment. The results of the independent testing should be carefully reviewed by your team. Additional risk mitigation may be designed and implemented into the final system architecture if warranted by the results of the security testing.

67


Security Assessment and Security Authorization

Control Testing and Evaluation• Security controls must be tested using the Security

Assessment Plan prior to deploying the system. This ensures the controls implemented are effective and that they provide the necessary level of assurance.

• To ensure objectivity, use Independent Validation and Verification (IV&V). IV&V is a method of using a testing team independent of the system development team to perform the Security Assessment. The results of the independent testing should be carefully reviewed by your team. Additional risk mitigation may be designed and implemented into the final system architecture, if warranted by the results of the security testing.

68



The goal of Security Authorization• Security Assessment and Authorization are two sides of

the same coin. The process verifies and documents that risks to the system are mitigated using controls and that residual risk is at a level acceptable to HHS.

• At the completion of the Security Authorization process, you should be able to answer 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 deficiencies in the security controls?

– How does the security control assessment translate into actual risk to HHS and is the risk acceptable?

69



Certification & AccreditationCertification & Accreditation (C&A), also known as security authorization, of Federal systems is mandated by OMB Circular 130-A. Every new system must be assessed and authorized before it is implemented. Additionally, a system in operation must be recertified and reaccredited at least every three years. A significant change to mission, system functionality, or security requirements may also trigger a assessment and authorization. NIST SP 800-37 Rev. 1, Guide for the Security Certification and Accreditation of Federal Information Systems and Organizations, provides guidance for the Risk Management Framework which includes the security assessment and authorization of Federal information systems.

70



Certification• Before a system is deployed within HHS, a Security

Control Assessment must be performed to ensure the security requirements are addressed by the implemented security controls. If documentation resulting from the key security tasks has been developed over the EPLC, preparing the Security Authorization package will be a relatively easy task.

• Once in operation, regular testing and evaluation of security controls will be required throughout the remainder of the EPLC to ensure controls remain effective in their application. Documenting the results of the continuous monitoring will provide readily available data to streamline reporting requirements.

71



Preparing the C&A PackageAt a minimum, a security authorization package contains:

– Privacy Impact Assessment

– E-Authentication Threshold Analysis/ E-Authentication Risk Assessment

– Risk Assessment/Security Assessment Report

– Contingency Plan

– POA&M

– Memorandum of Understanding/Interconnection Security Agreement

– Authorization Decision Document

72



Authorization• 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 Authorization to Operate (ATO) or Denial of Authorization to Operate.

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

• If a Denial of Authorization to Operate is issued, the controls require strengthening and the security authorization package needs to be revised and resubmitted to show the residual risk has been reduced to an acceptable level. If security has been addressed appropriately throughout the EPLC, there will not be any surprises at this point.

73


System Integration

Security Control Integration• As a system is moved from the test environment to the

production environment, integration of the final technical and operational security controls must be completed. The control settings should be enabled according to the security implementation documentation.

• Operational procedures, which include security practices, should also be activated to provide guidance to users and administrators.

• Once the security settings for the controls are enabled in the production environment, the level of security for the system will meet that of its security categorization.

74


System Integration

Transfer of Ownership• Once a system is authorized and operating in the

production environment, the baton passes from the Program Manager/Project Manager to the System Owner. The System Owner assumes responsibility for day-to-day system operation and maintenance.

• During the transfer of ownership, the project team completes its final tasks, gathers all documentation, and transfers the documentation and technology to the operations group.

75


RECAP

The Finished Product• After receiving an ATO, the system can be operated in a

production environment. If the security controls have been developed throughout the EPLC they will be well integrated, and the rollout of the live system should be smooth and without incident.

• Once the system is implemented, it enters into the daily operational stage or the Operations and Maintenance Phase of the EPLC.

76


Overview

Security is a Continual Process• Once the system is implemented and functioning

properly and securely, it can still be affected by changes in policy, procedures, and people. Throughout the Operations and Maintenance (O&M) Phase individuals are responsible for continuously monitoring the system to ensure that security controls are still operating effectively by performing periodic:

– Tests

– Reviews

– Audits

– Security control assessments

• During the Disposition Phase, there are specific actions to take to securely dispose of a system. These include preserving data, securely destroying data, and securely handling the various system components as they are removed from service.

77


Continuous Monitoring, Change, and Evaluation

Intrusion Monitoring and Detection Systems at HHS that handle sensitive information - like

Medicare and Medicaid records or financial information - are prime targets for malicious behavior. Intrusion detection and prevention software is one technological resource that mitigates this type of risk. It monitors network traffic and local system activity for indications of attack and misuse. This complements the protection offered by firewalls and vulnerability assessments.

78



Incident Handling and Disaster Recovery• You know by now that while you can mitigate the majority of

security risks using management, operational, and technical controls, it is impossible to completely eliminate risk. An incident is any disruption of service in the system due to manmade or natural causes. Knowing how to respond during an incident will help you resolve the issue efficiently, thereby minimizing loss of information and disruption of services.

• FISMA requires HHS to have a formal incident response capability. HHS satisfies this requirement by virtue of each OPDIV Incident Response Team (IRT). IRTs are responsible for preparing for, identifying, containing, eradicating, recovering from, and reporting security incidents on systems under their OPDIV's purview.

• Additionally, in compliance with an OMB mandate, HHS has a Privacy Incident Response Team (PIRT), a cross-organizational team to handle incidents in which a breach of PII is suspected or realized.

79



Updates and Patches• Providing software patches and software and hardware

updates is one of the simplest and most effective methods of continuous risk mitigation. The CM plan for the system outlines a process for implementing patches. System bugs can typically be corrected with periodic updates. If the vulnerability creates an unreasonable level of risk, it needs to be resolved immediately. For example, if an attacker announces a vulnerability on the Internet, HHS could be susceptible to the attack in a matter of minutes.

• Continuously monitoring the system security controls includes keeping an eye on publicly announced vulnerabilities, knowing how HHS and your OPDIV is impacted, and acting quickly to implement the best solution to preserve the integrity of the system. The CM testing plan provides a guide to ensure the patch does not create new problems as it fixes the original issue.

• Update the CM Plan each time the system is changed tocreate a current baseline of the system in case it ever needsto be rebuilt or restored to a previous state.

80



Periodic Assessment and Authorization• Before the system could become operational, it had to

undergo the Security Authorization process and receive an ATO. The ATO is good for up to three years or when significant changes have taken place that cause an unacceptable increase in operating risks, whichever comes first. Therefore, regular assessment and authorization is necessary to ensure the system continues to operate as securely as when it first came online.

• An annual security control assessment is a management tool that helps prepare for these check-ups. By completing it each year, security weaknesses are identified, tracked, and fixed. The System Owner also monitors risks in order to mitigate them. This data feeds back into the POA&M, which identifies and prioritizes the security remediation activities of the system.

81



System Changes that Impact SecurityAny of the following actions can impact the security of a system:

– A new functional need that requires an additional system feature

– Upgrades are made to existing functions

– Patches are distributed to address a new risk

– New or revised Federal policy and agency procedures are written that impact who can access the system

– Modifications are made to external systems with which your system interacts

– The system is taken offline

82


Security During Disposal

Planning for Disposal• When part or all of a system is no longer needed

by HHS or a CBA demonstrates that replacing it is more cost effective, one or more components need to be disposed. During this transition, you have three options for addressing the data stored and handled by the system: move it to another system, archive it, or destroy it. Each of these must be done carefully to ensure the confidentiality, integrity, and possibly the availability of the information.

• Planning during this last phase of the EPLC is as important as any other. You have probably seen headlines about public and private organizations that discarded computers improperly, which allowed unauthorized individuals to recover sensitive data.

83



The Disposal Process• Once a decision is made about system information, the

system disposal process consists of three stages:– Information Preservation – ensuring that

information is retained in a usable format – Media Sanitization – ensuring that data is

irretrievable – Hardware and Software Disposal – ensuring that

the hardware and software is disposed of as directed by the system's Information System Security Officer (ISSO).

• Regardless of what happens to the various system components, update system documentation, such as the Security Risk Assessment and Security Plan, and archive them in an easily accessible location. This information will undoubtedly be helpful if a system is being designed to replace the current one.

84



Preserving Information• If a system is being replaced, all data must be

migrated to the new system. As the data is pulled from the old system, stored, and transferred to the new system, security controls should continue to protect it according to its sensitivity level.

• Other times, the data won’t be used in a new system, but may be required at some point in the future. Archiving data requires similar controls as you transfer the data to an archived state. In addition, you must plan for how someone could retrieve the data, taking into account changes in technology that could render the retrieval method obsolete. Consider archiving the software and documentation used to create the data.

85



Media Storage• Magnetic disks, like hard drives are initially

formatted with a “table of contents” (or index), that allows the drive to store data and find it again. When you delete a file, you do not destroy it. Instead, the system merely erases the entry from the table of contents, marking that disk space as free and allowing other data to be written there.

• Data contained in full or partial files can include potentially sensitive information. Since it is still physically on the drive, it can be recovered using commercially available software. In addition, various types of temporary files created by the system can contain passwords to websites and old emails, which can easily be recovered.

86



Sanitizing Data• 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 or application of an abrasive substance.

87



Software and Hardware Disposal• It is essential that sanitization is performed on the

system components prior to hardware and software disposal to protect the confidentiality of the information.

• Rarely is there a need to physically destroy the hardware once the data has been properly secured. However, a high level of information sensitivity may require that the components be destroyed.

88


RECAP

Always on Guard• Once the system is implemented, it still has two

phases of its EPLC to go through: O&M and Disposal.

• During the O&M phase, ISSOs and System Administrators continuously:

– Monitor the effectiveness of the security controls

– Watch for new threats and vulnerabilities

– Apply patches and upgrades, as needed

– Prepare to respond to any incidents

• When system components are to be disposed of, follow HHS and OPDIV policy and procedures for preserving and archiving important data, sanitizing media of all other data, and disposing of the hardware and software securely.

89


A Protected Enterprise

Managing Risk Effectively• Millions of Americans trust HHS to provide them with

high-quality services. HHS can only accomplish its mission with a secure and reliable IT infrastructure.

• To maintain information security, you use a risk management framework. This includes assessing the risks HHS systems are exposed to and ensuring residual risk is reduced to an acceptable level by completing security activities throughout the EPLC.

• The process begins by assigning a system security categorization of low, moderate, or high and selecting baseline security controls. Building on this foundation, you select and implement controls based on a CBA. Testing controls to verify they are effective is necessary before authorizing the system to enter daily operation. Thereafter, system controls are monitored and maintained to ensure that they continue to protect the system and its resources.

90



Planning Maximized Results• Thinking of security as part of the foundation of a

system will help you plan for the resources you need to design, develop, implement, and test the security features of the system. You need more people, money, and time to build a secure system than one that isn’t secure. However, building security into a system early in the design process is far more efficient than trying to add it on during or after development.

• Don’t forget to provide feedback into the IT capital planning process. Since you are on the front line of systems development, you have a unique perspective on current security weaknesses, as well as security needs affected by technological and environmental changes.

91



Monitoring Success• Once in use, operational controls ensure that the

system is monitored continuously. Patches are developed, tested, and implemented to enhance the system functionality. Security performance and incidents are handled following the incident response procedures.

• Also, information will need to be collected and provided to help HHS prepare various Federal reports. Two of the most high-profile are the annual FISMA report and the quarterly OMB report submissions.

• Preparing for these reports is simplified if you maintain documentation like the Security Plan and the CM Plan. These provide a record of system changes, the impact on security to the agency, and plans to address security deficiencies.

92



Providing Assurance• One key goal of information security is to provide

the assurance that the information assets handled by systems meet their confidentiality, availability, and integrity security objectives.

• By completing and documenting the steps in the risk management framework, there will be a record proving the system is designed to securely manage data. Also, documentation will exist to support Security Authorization.

93


Course Completion

CongratulationsYou have completed the Information Security for Managers course.

94


Glossary• Authority to Operate (ATO) - Permission given by a Designated Approving Authority (DAA) 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.

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

95


Glossary• 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 - An attempted or actual compromise of the confidentiality, integrity, or availability of a computer system or its information, or a disruption or denial of availability.

96


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

original development team.

• 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) - Monitor the implementation of security standards and policy.

• Integrity - The principle of guarding a system against improper information modification or destruction, including ensuring information non-repudiation and authenticity.

• Interconnectivity Security Agreement (ISA) - A document that outlines and formalizes the interconnection between two systems by specifying the need, security requirements, and technical safeguards. The ISA is adjudicated and signed by the respective Designated Accrediting Authorities (DAAs) from both systems.

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

• Personally Identifiable Information (PII) - Any piece of information which can potentially be used to uniquely identify, contact, or locate a single person.

97


Glossary• Plan of Action and Milestones (POA&M) - A report submitted to the Office of Management and Budget (OMB)

that identifies IT security-related tasks that need to be accomplished to address system security weaknesses. The report details resources required to accomplish the elements of the plan, any milestones in meeting the task, and scheduled completion dates for the milestones. It is designed to assist agencies in identifying, assessing, prioritizing, and monitoring the progress of corrective efforts for security weaknesses found in programs and systems.

• Privacy Impact Assessment (PIA) - A document that identifies the personally identifiable information (PII) collected by a system, describes the impact the system has on personal privacy and the plans for how it will be addressed. A PIA also confirms that HHS only collects enough PII to administer a program, only uses the information for the intended purpose, that the information collected is timely and accurate, and that the information is protected and retained only as long as necessary. See also: “Personally Identifiable Information,” “HIPAA.”

• Risk - The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals, resulting from the operation of an information system, given the potential impact of a threat and the likelihood of that threat occurring.

• Risk Assessment - The process of analyzing threats to and vulnerabilities of an information system, determining the risks (potential for losses), and using the analysis as a basis for identifying appropriate and cost-effective measures.

• Risk Management - The ongoing process of assessing the risk to automated information resources and information, as part of a risk-based approach, used to determine adequate security for a system by analyzing the threats and vulnerabilities and by selecting appropriate cost-effective controls to achieve and maintain an acceptable level of risk.

• Sanitization - Process to remove information from media such that information recovery is not possible. It includes removing all labels, markings, and activity logs.

98


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

• Security Objectives - Confidentiality, integrity, and availability. • Senior Official for Privacy (SOP) – The senior official within HHS responsible for Department-wide Adherence to

the Privacy Act of 1974. • Security Test and Evaluation (ST&E) – A formal evaluation of a system’s effectiveness of security controls.• Enterprise Performance Life Cycle (EPLC) - A structured approach for systems development from planning and

support to disposal of the system. A proven series of steps and tasks used to build and maintain quality systems faster, at lower costs, and with less risk.

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

99


Glossary• 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 condition that has potential to be exploited by a threat; a weakness in an information system or component that could be exploited by a threat.

100


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.

101


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)

102


References

103


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.

104

u.s. department of health and human services may 2011 information security for managers 1

Documents

security requirements

security activities

department of health

appropriate security

proposed security solutions

securityrelated documentation

identified security

human services hhs