HHS Cybersecurity Program Training Information Security for Information Technology (IT) Administrators - PowerPoint PPT Presentation

Loading...

PPT – HHS Cybersecurity Program Training Information Security for Information Technology (IT) Administrators PowerPoint presentation | free to download - id: 42dfc5-MjkxY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

HHS Cybersecurity Program Training Information Security for Information Technology (IT) Administrators

Description:

HHS Cybersecurity Program Training Information Security for Information Technology (IT) Administrators May 2011 * – PowerPoint PPT presentation

Number of Views:501
Avg rating:5.0/5.0
Slides: 159
Provided by: Danielle174
Learn more at: http://www.hhs.gov
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: HHS Cybersecurity Program Training Information Security for Information Technology (IT) Administrators


1
HHS Cybersecurity Program Training Information
Security for Information Technology (IT)
Administrators
May 2011
2
Welcome
Page 1 OF 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 Divisions (OPDIV)
    security policies and procedures, since they may
    provide further specificity, and in certain
    cases, may be more stringent than the
    Departments.

3
Course overview
Page 2 of 2
  • 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.

4
AgendaSecurity compliance of your system
  • Page 1 of 1
  • Safeguarding the HHS Mission
  • Information Security Program Management
  • Information Security and the EPLC
  • HHS Policy for Information Systems Security and
    Privacy

5
Safeguarding the HHS missionThe Challenge of
Information Security
  • Page 1 of 11
  • 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.

6
Safeguarding the HHS missionVulnerabilities,
Threats and Risks
Page 2 of 11
  • 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.

7
Safeguarding the HHS missionSecurity is an
Integrated Solution
  • Page 3 of 11
  • 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.

8
Safeguarding the HHS missionPolicy
  • page 4 of 11
  • 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
    agencys 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.

9
Safeguarding the HHS missionPeople
  • Page 5 of 11
  • 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-201
    0-0006-html.html_Toc272306722

10
Safeguarding the HHS missionPeople
Page 5 of 11
  • 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 Officers 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.

11
Safeguarding the HHS missionProcedure
  • Page 7 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.

12
Safeguarding the HHS missionProducts
  • Page 8 of 11
  • 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 softwareor a hardware peripheral like a
    printerto an enterprise-wide web-based
    application that is used daily by thousands of
    employees. All componentshardware, software,
    interconnections, facilities, infrastructure
    (e.g., power, temperature), etc.are all part of
    the information system product.

13
Safeguarding the HHS missionInformation Security
at HHS
  • Page 9 of 11
  • HHSs 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.

14
Safeguarding the HHS missionIT Administrators at
HHS
  • Page 10 of 11
  • 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.

15
Safeguarding the HHS missionIT Administrator
Roles
  • Page 11 of 11
  • IT Administrators Network Administrators
  • System Administrators
  • Database Administrators
  • Software Engineers/Developers
  • System Engineers and Integrators

16
Information Security Program ManagementLesson
Introduction
  • Page 1 of 6
  • 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

17
Information Security Program ManagementInformatio
n Security Program Objectives
  • Page 2 of 6
  • 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

18
Information Security Program ManagementInformatio
n Security Programs at HHS
  • Page 3 of 6
  • 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 Programs intranet site at
    http//intranet.hhs.gov/it/cybersecurity/index.htm
    l
  • OPDIV Information Security Programs OPDIV
    programs are responsible for implementing a
    security baseline aligned with the OPDIV mission
    and the HHS Cybersecurity Program.

19
Information Security Program ManagementInformatio
n Security Program Elements
  • Page 4 of 6
  • 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 (CA)) and Periodic Security
    Assessments
  • Security Awareness and Training
  • IT Contingency Planning (CP)
  • Incident Response
  • Configuration Management and
  • Program Performance Measurement.

20
Information Security Program ManagementIT
Administrator Role Within the Program
  • Page 5 of 6
  • 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

21
Information Security Program ManagementInformatio
n Security and the EPLC
  • Page 6 of 6
  • 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.

22
Information Security and the EPLCHHS Controls
  • Page 1 of 8
  • 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.

23
Information Security and the EPLCFISMA
  • Page 2 of 8
  • FISMA creates a tie between an agencys
    implementation of their security program and the
    agencys budget for IT. The annual FISMA report
    includes input from HHSs Chief Information
    Officer, the Office Inspector General, and HHSs
    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.

24
Information Security and the EPLCAnnual FISMA
Report
  • Page 3 of 8
  • 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

25
Information Security and the EPLCIndependent
Evaluation
  • Page 4 of 8
  • 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.

26
Information Security and the EPLCNIST
  • Page 5 of 8
  • 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.

27
Information Security and the EPLCCompulsory
Standards
  • Page 6 of 8
  • 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/PubsSP
    s.html

28
Information Security and the EPLCFIPS
  • Page 7 of 8
  • 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.

29
Information Security and the EPLCFIPS
  • Page 8 of 8
  • 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.

30
HHS PolicyHHS Policy and Practices
  • Page 1 of 5
  • 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.

31
HHS PolicyFISMA and the POAM
  • Page 2 of 5
  • 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 (POAM)
    for each system. The POAM tracks significant
    deficiencies in HHS security.
  • The POAM is a management tool to focus attention
    on improving the security posture of IT resources
    used within HHS. HHS tracks the POAM in the
    SPORT system.
  • As an IT Administrator, you may be asked to
    provide input to the POAM. For reporting
    purposes, the data from each system is rolled up
    into one report which represents the entire HHS.

32
HHS PolicySignificant Deficiency
  • Page 3 of 5
  • A significant deficiency is defined as a weakness
    in HHSs 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 POAM 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 POAM. When there is a change in
    status of the weaknesses, that change must be
    reflected in the next POAM quarterly update. The
    POAM identifies who is responsible for
    mitigating the weakness as well as milestone
    dates for completion.

33
HHS PolicyLearning Check
  • Page 4 of 5
  • 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

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

35
RecapRecap
  • Page 1 of 1
  • 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 POAM
    submissions. Metrics, provided by HHS in the
    annual FISMA report, are used to help measure
    compliance.

36
AgendaSystems Analysis and Boundaries
  • Page 1 of 1
  • Development Phase Security
  • Identifying Boundaries
  • Types of Systems
  • Interconnecting Systems
  • Your System and the EPLC

37
Development Phase Security Lesson Introduction
  • Page 1 of 5
  • 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 systems
    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.

38
Development Phase Security Security Control
Selection Refinement
  • Page 2 of 5
  • A systems 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 systems 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 systems security risk and
    provides the rationale for any supplemental
    controls necessary.

39
Development Phase Security Security Control Class
  • Page 3 of 5
  • 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.

40
Development Phase Security Security Control
Applicable to IT
  • Page 4 of 5
  • 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

41
Development Phase Security Security Practices for
IT Administrators During Development
  • Page 5 of 5
  • 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 Departments
    minimum security standards, located at
    http//intranet.hhs.gov/it/cybersecurity/index.htm
    l
  • Avoid establishing highly privileged user
    accounts (e.g., admin/root), where possible

42
Identifying Boundaries Importance, Impact and
Purpose
  • Page 1 of 2
  • 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)

43
Identifying Boundaries How to Determine Your
System Boundaries
  • Page 2 of 2
  • 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

44
Types of Systems Major Application and General
Support System
  • Page 1 of 3
  • 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.

45
Types of Systems Securing a Major Application
  • Page 2 of 3
  • 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.

46
Types of Systems Securing a General Support System
  • Page 3 of 3
  • 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.

47
Interconnecting Systems Security Implications of
Interconnections
  • Page 1 of 5
  • 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.

48
Interconnecting Systems MOUs, MOAs, ISAs
  • Page 2 of 5
  • 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

49
Interconnecting Systems Setting the Ground Rules
with MOUs and MOAs
  • Page 3 of 5
  • 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.

50
Interconnecting Systems Important Note
  • Page 4 of 5
  • 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.

51
Interconnecting Systems IT Specialists and System
Interconnections
  • Page 5 of 5
  • 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?

52
Your System and the EPLC Phases of EPLC
  • Page 1 of 3
  • 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

53
Your System and the EPLC Security Implications at
Each Phase
  • Page 2 of 3
  • 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.

54
Your System and the EPLC Critical Security Issues
  • Page 3 of 3
  • 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 measurescontrols,
    analysis, testinghave 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?

55
Recap Recap
  • HHSs 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 HHSs MOU/ISA
  • IT Administrators and the EPLC Deployment and
    Operation
  • Page 1 of 1

56
Agenda Security Controls and Your System
  • Page 1 of 1
  • In this section, we will cover the following
    topics
  • Security Implementation Assessment Phase
  • Security Categorization
  • Security Control Selection
  • Using Security Controls

57
Implementation Assessment Phase Lesson
Introduction
  • Page 1 of 9
  • 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

58
Implementation Assessment Phase Contingency
Plan (CP)
  • Page 2 of 9
  • 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.

59
Implementation Assessment Phase Configuration
Management Plan
  • 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

60
Implementation Assessment Phase Privacy Impact
Assessment
  • Page 4 of 9
  • 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 systems
    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.

61
Implementation Assessment Phase Interconnection
Security Agreements
  • Page 5 of 9
  • 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.

62
Implementation Assessment Phase Security
Controls Assessment
  • Page 6 of 9
  • 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 systems controls or may
    be responsible for refining controls, if an
    independent reviewer finds weaknesses.

63
Implementation Assessment Phase Security
Controls Assessment
  • Page 7 of 9
  • 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 STE 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 systems Risk Assessment is updated.

64
Implementation Assessment Phase Plan of Action
Milestones
  • Page 8 of 9
  • A plan of action and milestones (POAM) is a tool
    used to identify, prioritize, and monitor the
    progress of system security weaknesses. POAMs
    outline corrective actions, required resources
    (i.e., funding, man-hours), and milestones for
    mitigating each outstanding weakness. This is
    initially compiled during the systems first
    security authorization and maintained thereafter.
  • IT Administrators often contribute to the POAM
    by formulating corrective actions, estimating
    resource needs, and providing input on milestones
    for completion.

65
Implementation Assessment Phase Security
Authorization Document
  • Page 9 of 9
  • 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.

66
Security Categorization Three Objectives
  • Page 1 of 3
  • 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)

67
Security Categorization Three Categories
  • Page 2 of 3
  • 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.

68
Security Categorization High Water Mark
  • Page 3 of 3
  • 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.

69
Security Control Selection Purpose of NIST SP
800-53 Revision 3
  • Page 1 of 12
  • 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.

70
Security Control Selection Three Classes of
Controls
  • 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.

71
Security Control Selection Management Controls
  • Page 3 of 12
  • Security Authorization and Security Control
    Assessments
  • Planning
  • Risk Assessment
  • System Services and Acquisition
  • Program Management

72
Security Control Selection Operational Controls
  • Page 4 of 12
  • 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

73
Security Control Selection Technical Controls
  • Page 5 of 12
  • 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.

74
Security Control Selection Identification and
Authentication
  • Page 6 of 12
  • 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)

75
Security Control Selection Access Control
  • Page 7 of 12
  • 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

76
Security Control Selection Access Control
(Continued)
  • Page 8 of 12
  • 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

77
Security Control Selection Audit and
Accountability
  • 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

78
Security Control Selection System and
Communications Protection
  • Page 10 of 12
  • 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

79
Security Control Selection System and
Communications Protection
  • Page 11 of 12
  • 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

80
Security Control Selection 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

Page 12 of 12
81
Using Security Controls Triggers for Updating
Controls
  • Page 1 of 5
  • 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

82
Using Security Controls How Controls are
Implemented and Tested
  • Page 2 of 5
  • 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.

83
Using Security Controls IT Specialists and
Technical Controls
  • Page 3 of 5
  • 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

84
Using Security Controls Standards
  • Page 4 of 5
  • 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.

85
Using Security Controls Standards
  • Page 5 of 5
  • Audit and Accountability - (1) Create, protect,
    and retain information system audit records to
    the extent needed to enable the monitoring,
    analysis, investigation, and r
About PowerShow.com