Elamb Cybersecurity

Category: DoD RMF

  • ISC2 CAP Domain Changes

    Got this message today on CAP domain changes.. Not much changed:

    On September 1, 2013, (ISC)²® will implement certain domain-related changes for the Certified Authorization Professional (CAP®) credential exam.  These will be the new domains you will need to select when submitting CPE credits for your CAP certification.

    These domain changes are being implemented based on the outcome of the Job Task Analysis (JTA) completed in late 2012. The JTA provides the essential foundation for all of (ISC)²’s credential exams. Under general circumstances, changes due to a new JTA study are incremental, so addition or deletion of Domains does not occur normally.

    isc2-cap-domain-changes
    courtesy of gabfirethemes

    Current CAP Domains:

    1.      Understand the Security Authorization of Information Systems

    2.      Categorize Information Systems

    3.      Establish the Security Control Baseline

    4.      Apply Security Controls

    5.      Assess Security Controls

    6.      Authorize Information System

    7.      Monitor Security Controls

    Effective September 1, 2013 CAP Domains:

    1.      Risk Management Framework (RMF)

    2.      Categorization of Information Systems

    3.      Selection of Security Controls

    4.      Security Control Implementation

    5.      Security Control Assessment

    6.      Information System Authorization

    7.      Monitoring of Security Controls

  • Roles & Responsibilities

    2014 Update:  DIACAP has been replaced by RMF for DoD IT.  The RMF for DoD IT is almost completely derived from the NIST SP 800-37.

    NIST roles and responsibilities are addressed throughout the special publication 800 series. The definition of the roles & responsibilities are as follows:

    Head of Agency
    The Head of Agency is also known as the Chief Executive Officer. This role is the highest level executive senior officer within an organization. They have ultimate responsible for the providing information security protection. The level of protection must be at the same level as the importance of the information. The Department of Defense equivanent is a DoD Head of component (i.e. Secretary of the Army).

    image of secretary army john mchugh

    Risk Executive Function
    The Risk Executive Function’s main focus is the overall risk to the entire organization. They create a risk strategy for the organization that guides mission/business process and system-level risk assessments. The Risk Executive Function is and important role for Tier 1 activities of managing risk of information systems IAW NIST SP 800-39.

    CIO
    Chief Information Officer is an organizational official responsible for (1) designating a senior information security officer; (2) developing and maintaining information security policies; (3) ensure that those with responsibilities in system security have proper training.

    Information Owner/Steward
    “The information owner/steward is an organizational official with statutory, management, or operational authority for specified information and the responsibility for establishing the policies and procedures governing its generation, collection, processing, dissemination, and disposal.” NIST SP 800-37 The Information Owner must coodinate with the Information System Owner (DoD PM equivalent) for decisions involving the overall system.

    Senior Information Security Officer
    The SISO is directly responsible to the CIO. They’re focus is the information security of the organization’s data. They act as a liaison between CIO and the Authorizing Official. The DoD equivalent (circa 2010) is known as the Senior Information Assurance Officer (SIAO).

    Authorizing Official
    AO formally accepts the risk of a system in the Implementation/Assessment phase of the System Development Lifecycle and Step 5, Authorization step of the Risk Management Framework.

    Common Control Provider

    “The common control provider is an individual, group, or organization responsible for the development, implementation, assessment, and monitoring of common controls.” NIST SP 800-37. A common control is a security controls that covers multiple information systems within and organization. Examples of common controls: Incident Response, Network boundary protection (firewalls, IDS/IPS).

    Information System Owner
    “The information system owner is an organizational official responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of an information system.” NIST SP 800-37

    Information System Security Engineer
    “The information system security engineer is an individual, group, or organization responsible for conducting information system security engineering activities.” NIST SP 800-37 The ISSE implements security into the design of systems. The ISSE is often a consultant or Subject Matter Expert who focus is applying information assurance frameworks and regulations in an information system.

    Information System Security Officer
    This role is initiated at the Initial phase of the System Development Lifecycle (SDLC). “The information system security officer
    is an individual responsible for ensuring that the appropriate operational security posture is maintained for an information system and as such, works in close collaboration with the information system owner” NIST SP 800-37. This role has been called and Information Assurance Officer (IAO) within the Department of Defense. Within the DoD this role is appointed by the Information Assurance Manager (IAM). Also known as the Information System Security Manager (ISSM). The ISSM is often responsible to over site and being a supervisor of ISSO positions.

    Security Control Assessor
    “The security control assessor is an individual, group, or organization responsible for conducting a comprehensive assessment of the management, operational, and technical security controls employed within or inherited by an information system to determine the overall effectiveness of the controls” NIST SP 800-37.

    The NIST & DoD have very similar roles with different names:

     

    DoDI 8510.01 DIACAP NIST SP 800-37 Security Authorization
    Heads of the DoD Components Head of Agency (CEO)
    Designated Accrediting Authority (DAA)/ Authorizing Official
    Program Manager (PM)/ Systems Manager (SM) Information System Owner
    Information Assurance Manager (IAM) Information System Security Officer
    Information Assurance Officer (IAO) Information System Security Officer/ Information System
    Security Engineer
    Certifying Authority (CA) Security Control Assessor
    Validator

     

     

  • Training & Certification: Risk Management Approach to Security Authorization

    Understand the Risk Management Approach to Security Authorization

    The concept of management of information security risks across an enterprise is discussed in 800-39. An organization takes a multitier approach to the risk management at the organizational, mission, and system levels. Risk management framework is a process that is broken down in NIST 800-37, Risk Management Framework. The CAP addresses the following:

      Distinguish between applying risk management principles and satisfying compliance requirements
      Identify and maintain information systems inventory
      Understand the criticality of securing information
      Understand organizational operations

    Distinguish between applying risk management principles and satisfying compliance
    Risk management includes satisfying compliance. Even though some controls may not be able to be made fully compliant due to limited resources, residual risk to the organization can still be mitigated and managed. – Concepts of NIST SP 800-37, Guide of RMF

    Identifying and maintaining information system (IS) inventory is addressed in NIST 800-37, Risk Management Framework, 800-18, System Security Plan & 800-64, System Development Life Cycle. 800-37 addresses inventory of the IS in RMF Step 1 – Categorization of IS. Of the tasks of categorization includes information system registration which begins with by identifying the information system in the system inventory. This is documented in the security plan. NIST SP 800-18 discusses how the inventory is documents, and logically separates the system authorization boundary. That inventory is maintained and monitored throughout the life cycle of the IS (from imitation to disposal and from categorization to monitoring of the system).

    A CAP candidate can understand the criticality of security information from reading FIPS 199, categorization of federal information systems.

    Understanding the organizational operations of the system is imperative to a CAP candidate for the purpose of scope guidance described in NIST SP 800-53.

  • Risk Management in IT: NSS

    Risk Management of IT: National Security Systems

    Risk Assessments and Risk Management will apply to National Security Systems (NSS).

    What is a Risk Assessment?

    A risk assessment is the results/process to determine the likelihood that a threat will exploit a weakness. Risk assessment is a part of the risk management.

    What is risk management?

    Risk Management is the on-going process of determining assessing, identifying and prioritizing of risks.

    Is My System a National Security System?

    NIST SP 800-59, Guidance for Identifying an information system as an NSS. 800-39 is a 17 page document developed in conjunction with the Department of Defense, including the National Security Agency, for identifying an information system as a national security system. It is basised on the Federal Information Security Management Act of 2002 (FISMA).

    Who determines if you have an NSS?

    The head of each agency is responsible for designating an agency information security official to determine which, if any, agency systems are national security systems.

    Tools to determine if you have a NSS system:

    National Security System Identification Checklist (NIST SP 800-59, Appendix A). The NSS ID Checklist asks (6) questions. Answering yes to any of these questions qualifies your system as an NSS:
    • Does the function, operation, or use of the system involve intelligence activities?
    • Does the function, operation, or use of the system involve cryptologic activities related to national security?
    • Does the function, operation, or use of the system involve command and control of military forces?
    • Does the function, operation, or use of the system involve equipment that is an integral part of a weapon or weapons system?
    • Is the system critical to the direct fulfillment of military or intelligence missions?
    • Does the system store, process, or communicate classified information?

    NSS RMF
    The guidance of CNSSI 1253 is the result of NIST collaborated with the Intelligence Community (IC), Department of Defense (DoD), and the Committee on National Security Systems (CNSS) to ensure NIST SP 800-53 contains security controls to meet the requirements of National Security Systems (NSS).

    KEY DIFFERENCES BETWEEN CNSS INSTRUCTION NO. 1253 AND NIST PUBLICATIONS

    The key differences between CNSSI 1253 and the rest of the NIST publications is that NSS systems do not follow “high-water mark”, NSS maybe tailored through risk-based adjustment, control profiles, and a method that allows organization to practice reciprocity.

    NSS and High Water Mark
    Both FIPS 200 and NIST 800-53 apply the concept of a high-water mark (HWM) when categorizing information systems according to the worst-case potential impact of a loss of confidentiality, integrity, or availability of information or an information system. This Instruction does not adopt this HWM usage. In the National Security Community, the potential impact levels determined for confidentiality, integrity, and availability are retained, meaning there are 27 possible three-value combinations for NSI or NSS, as opposed to the three possible single-value categorizations obtained using the guidelines in FIPS 200. – CNSSI 1253

    Risk-Based Adjustment
    Potential impact-based security categorizations for NSS may be tailored through the use of a risk-based adjustment. This adjustment takes into consideration the physical and personnel security measures already employed throughout the National Security Community and factors such as aggregation of information.

    Control Profile
    Method by which organizations may designate sets of controls for NSS based on their enterprise-wide risk assessment and taking into account business objectives, system risks, and mission needs.

    NSS Reciprocity
    It is the policy of the National Security Community that member organizations practice reciprocity with respect to the certification of systems and system components to the greatest extent practicable. Reciprocity of certification reduces the cost and time to implement systems and system components.

  • Risk Management in IT: Risk Assessment Methodology

  • Risk Management in IT: SDLC

    Risk Management Guide for IT: SDLC

    NIST 800-30, risk management guide for IT discusses how risk management framework matches to the system development life cycle (SDLC) , risk assessment methodology, risk mitigation, and good practice of ongoing risk assessment.

    A system and its information must be protected from cradle to grave. That is why risk management applies to the entire system development life cycle. The level of risk to the system and its data depends on the criticality or importance of the system to the business and/or mission it supports.
    The system development life cycle consists of: Initiation, Development/Acquisition, Implementation, Maintenance/Operations, and Disposal.

    How Risk Management Framework matches to the System Development Life Cycle

    SDLC
    Phases

    Phase
    Characteristics

    Support
    from Risk Management Activities

    Phase
    1—Initiation

    The need
    for an IT system is

    expressed
    and the purpose and

    scope of
    the IT system is

    documented

    Identified
    risks are used to

    support
    the development of the

    system
    requirements, including

    security
    requirements, and a

    security
    concept of operations

    (strategy)

    Phase
    2—Development or

    Acquisition

    The IT
    system is designed,

    purchased,
    programmed,

    developed,
    or otherwise

    constructed

    The risks
    identified during this

    phase can
    be used to support

    the
    security analyses of the IT

    system
    that may lead to

    architecture
    and design tradeoffs

    during
    system

    development

    Phase
    3—Implementation

    The system
    security features

    should be
    configured, enabled,

    tested,
    and verified

    The risk
    management process

    supports
    the assessment of the

    system
    implementation against

    its
    requirements and within its

    modeled
    operational

    environment.
    Decisions

    regarding
    risks identified must

    be made
    prior to system

    operation

    Phase
    4—Operation or

    Maintenance

    The system
    performs its

    functions.
    Typically the system is

    being
    modified on an ongoing

    basis
    through the addition of

    hardware
    and software and by

    changes to
    organizational

    processes,
    policies, and

    procedures

    Risk
    management activities are

    performed
    for periodic system

    reauthorization
    (or

    reaccreditation)
    or whenever

    major
    changes are made to an

    IT system
    in its operational,

    production
    environment (e.g.,

    new system
    interfaces)

    Phase
    5—Disposal

    This phase
    may involve the

    disposition
    of information,

    hardware,
    and software.

    Activities
    may include moving,

    archiving,
    discarding, or

    destroying
    information and

    sanitizing
    the hardware and

    software

    Risk
    management activities

    are
    performed for system

    components
    that will be

    disposed
    of or replaced to

    ensure
    that the hardware and

    software
    are properly disposed

    of, that
    residual data is

    appropriately
    handled, and that

    system
    migration is conducted

    in a
    secure and systematic

    manner

  • Training and Certification: 800-66 – HIPPA

    Guidance for Health Insurance Portability and Accountability Act (HIPPA)

    NIST Special Publication 800-66 offers guidance for HIPPA. HIPPA is broken up into (5) different Titles:
    Title 1) Healthcare accessibility, portability and renewability
    Title 2) Healthcare Fraud and abuse prevention; Healthcare Liability; Administrative Simplicity
    Title 3) Tax-related healthcare provisions
    Title 4) Group Health plan
    Title 5) Revenue Offset

    The focus of NIST SP 800-66 is Title 2 Administrative Simplification, HIPPA Security Rule. The HIPPA Security Rule is broken into Electronic Data Interchange (code set, identifiers, transactions), Privacy, Security.
    Security includes all efforts to protect the confidentiality, integrity & availability of electronic protected health information (EPHI). HIPPA Security is applicable to covered entities. Covered entities include: Covered Healthcare providers, health plans, Healthcare Clearinghouses, and Medicare prescription drug card sponsors.

    This involves physical, administrative, technical safeguards, organizational requirements, policy, procedure and documentation requirements. The controls are used to meet these controls are required or addressable.

    Physical security safeguards: all security controls needed to physically protect electronic protection health information (EPHI) and resources. These controls reduce physical access to the EPHI systems and their resources by isolating and limiting and locking areas in which the resources housing EPHI is located.
    Administrative safeguards: administrative controls include documentation, procedures that reflect the security of systems containing EPHI.
    Technical safeguards: technical security features that protect EPHI. This includes access control lists, least functionality on ports, protocols & services and other logical protection mechanisms over a network.
    Organizational requirements: organizational requirements include policies, standards and guidelines that the organization must adhere to. This may include federal, state law and healthcare best practice.
    Policy, procedure and documentation requirements: physical, administrative, technical controls are captured in documentation to establish a baseline, have consistency and act as a blueprint for future employees and/or managers.

  • Training and Certification: NIST SP 800-39 Manage Information Security Risk

    NIST SP 800-39, Manage Information Security Risk

    NIST 800-39 is a federal document that talks about risk management of information system and their security. It is cited as one of the sources for the ISC2 Certified Authorization Professional (CAP) certification. For study of the document go to Chapters 2 and 3 of 800-39. Chapter 2 talks about the fundamentals of risk management & chapter 3 breaks down the process of applying risk management across and organization.

    The Fundamentals of Risk Management (Chapter 2, 800-39)
    800-39 goes into the philosophy (or “the why”) and the how of managing information security at multiple levels (or multitier risk management approach). The three layers (or tiers) of risk management addressed in the 800-39 are:
    Tier 1: Organization level
    Tier 2: Mission/Business Process level
    Tier 3: Information System level

    Tier 1: Organization Level risk management
    Tier one addresses security from the organizations perspective. The activities include the implementation of the first component of risk management, risk framing. Risk framing provides context of all the risk activities within an organization, which affects the risk activities of tier 1 & 2. The output of risk framing is Risk Management Strategy. In tier 1 the organization establishes and implements governance structure that are in compliance with laws, regulations and policies. Tier 1 activities include establishment of the Risk Executive Function, establishment of the risk management strategy and determination of the risk tolerance.

    Tier 2: Mission/Business Process Level risk management

    Tier 2 risk management activities include: 1) defining the mission/business processes to support the organization. 2) Prioritize the mission/business process with respect to the long term goals of the organization. 3) Define the type of information needed to successfully execute the mission/business processes, criticality/sensitivity of the information and the information flows both internal and external of the information.

    Having a risk-aware process is an important part of tier 2. To be risk-aware senior leaders/executives need to know: 1) types of threat sources and threat events that could have an adverse affect the ability of the organizations 2) the potential adverse impacts on the organizational operations and assets, individuals, the Nation if confidentiality, integrity, availability is compromised 3) the organization’s resilience to such an attack that can be achieved with a given mission/business process

    Tier 3: Information System risk management

    From the information system perspective, tier 3 addresses the following tasks:
    1) Categorization of the information system
    2) Allocating the organizational security control
    3) Selection, implementation, assessment, authorization, and ongoing

    Chapter 3 focuses on the step to have a comprehensive risk management program. The tasks discussed include:
    Risk Framing
    Risk Assessing
    Risk Response
    Risk Monitoring

    Risk Framing
    Risk framing are the assumptions, constraints, risk tolerance and priorities that shape an organization’s managing risk. Risk framing is created based on organizational governance structure, how much money is available, regulations imposed, environment, culture and trust relationships.
    In order to “frame” risk (or get an organizational context of the risk) the organization must determine: Risk assumptions, risk constraints, risk tolerance and priorities/trade-offs

    Risk Assumptions
    Risk assumption has to do determining how to risk will be assessed for an organization. Assumptions are based on identification of threats, vulnerabilities, the impact to the organization if attacks are successful and likelihood of attacks.

    Risk Constraints
    Risk constraints have to do with accepted limits of risk assessments, risk monitoring & risk response. Those limitation might be financial, cultural, the need to rely on legacy systems, or regulations imposed on the organization.

    Risk Tolerance
    Risk tolerance is how much risk the organization is willing to take.
    Priorities/Tradeoffs
    Risk is experienced at different levels, in different forms, and in different time frames. At Tier
    1, organizations make trade-offs among and establish priorities for responding to such risks. Organizations tend to have multiple priorities that at times conflict, which generates potential risk. Approaches employed by organizations for managing portfolios of risks reflect organizational culture, risk tolerance, as well as risk-related assumptions and constraints. These approaches are typically embodied in the strategic plans, policies, and roadmaps of organizations which may indicate preferences for different forms of risk response. For example, organizations may be willing to accept short-term risk of slightly degraded operations to achieve long-term reduction in information security risk.
    However, this trade-off could be unacceptable for one particularly critical mission/business function (e.g., real-time requirements in many industrial/process control systems). For that high-priority area, a different approach to improving security may be required including the application of compensating security controls.

    Risk Assessment
    Risk assessment is threat & vulnerability identification and risk determination. Organizaitonal risk framing is a prerequisite to risk assessments, because methods of risk assessment must be established by the contexts of the organizations risk.

    Risk Response
    Risk response identifies, evaluates, decides on, and implements appropriate courses of action to
    accept, avoid, mitigate, share, or transfer risk to organizational operations and assets, individuals,
    other organizations, and the Nation, resulting from the operation and use of information systems.
    Risk identification is key to risk response. Risk types include:
    Risk accept- is the appropriate risk response when the identified risk is within the organizational risk tolerance. Organizations can accept risk deemed to be low, moderate, or high depending on particular situations or conditions.

    Risk avoidance– Organizations may conduct certain types of activities or employ certain types of information technologies that result in risk that is unacceptable. In such situations, risk avoidance involves taking specific actions to eliminate the activities or technologies that are the basis for the risk or to revise or reposition these activities or technologies in the organizational mission/business processes to avoid the potential for unacceptable risk.

    Risk mitigation-adding management, technical, administrative safeguards to minimize identified risks to the system.
    Risk share & transfer- Risk sharing or risk transfer is the appropriate risk response when organizations desire and have the means to shift risk liability and responsibility to other organizations. Risk transfer shifts the entire risk responsibility or liability from one organization to another organization (e.g., using insurance to transfer risk from particular organizations to insurance
    companies).

    Risk Monitoring – Risk changes with each modification of the system. It’s important to monitor the changes of the risk of a system. Changes to threats can also change risk.

  • DoD Risk Management FrameWork (Part 1): Look Ahead


    The DoD is working on using the National Institute of Standards and Technology (NIST) Certification & Accreditation method of assessing & authorizing systems. The NIST system of C&A is actually known as Risk Management Framework (RMF). This would require the the Assistant Secretary of Defense Networks & Information Integration ASD(NII) office to move the DoDI 8500.2, Information Assurance (IA) controls to be mapped to the NIST SP 800-53, Recommended Security Controls. I am not certain yet whether they will eliminate the 8500.2 or just have all departments move to the NIST SP 800-53. They will also need to switch the DoD Information Assurance Certification & Accreditation Process (DIACAP) to the NIST SP 800-37 rev 1, Risk Management Framework or something similar.

    If the transition is anything like their move to from DoD Information Technology Security Certification & Accreditation Process (DITSCAP) to the DIACAP then they will give about 2 years for the DoD to transition. As of Mar. 2011, there is no policy on this. It is serious because its on the DIACAP KS and the Department of Navy CIO has been releasing information on it since 2009. The DON CIO & the ASD (NII) have been working on the project to transition from DIACAP to some sort of DoD Risk Management Framework. So far, they have mapped the DoDI 8500.2 IA controls to the NIST SP 800-53 Controls: Certification and Accreditation Transformation: Security Control Mapping. Here is a May 2010 update to the NIST to DIACAP mapping. 800-53 to DoD IA contols map also includes the Director of Central Intelligence Directive (DCID) 6/3 controls. This is very telling. The plan seems to be to have one standard for all Federal Information System.

    Since DoD 8510.01, DIACAP & NIST SP 800-37, Risk Management Framework (RMF) cover so much of the same ground, I think the only real benefit is that reciprocity between Federal agency will be easier if all departments have one standard of risk management and one security control set.

    The DON uses the certification and accreditation (C&A) process to assess and understand the residual risk associated with operating information systems (IS) and information technology (IT). The DON is participating with the DoD, the IC, and the rest of the Federal government in C&A transformation. One goal of transformation is to achieve common security controls enabling the DON, the DoD, the IC, and the rest of the Federal government to develop systems to the same protection standards.

    The recently released National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, revision 3 provides recommended consolidated security controls in an effort to achieve common security controls across the Federal government.

    The DON will continue to use the DoDI 8500.2 as the authoritative source for security controls until otherwise specified. However, understanding the changes represented in NIST SP 800-53r3 will be essential as DoD and the DON begin transitioning to this new set of security controls. To support the transition, the DON CIO developed this security control mapping document to demonstrate how existing DoD and IC security controls map to the security controls recommended by the NIST SP 800-53r3 publication.

    —Security Control Mapping Document Aids Transition, DON CIO Site

  • EITDR – enterprise information technology data repository

    EITDR

    30 Aug 11 – Update *USAF Recently changed the functionality of EITDR

    To all System Security Engineers and Information Assurance Officers,

    Here is something you might need to know. The Air Force is conducting all MANY of its certification & accreditation through the EITDR database none of its C&A (soon Risk Management Framework) through EITDR. The USAF is moving to the eMASS. As of Aug 2011, the USAF is still using EITDR to do IT portfolio management (to remain compliant with FISMA). EITDR feeds into the DoD IT Portfolio Registry (DITPR) database. Each branch has its own methods IT registry: the Army’s has the Portfolio Management System (APMS), Navy/Marines have the DITPR-DON. All of these system are used to “record investment review and certification submission information, FISMA assessments, E-Authentication status, and Privacy Impact Assessment status” (office of the assistance sec of the navy).

    Each branch has an agency that controls these databases for example, the Air Force has the Air Force Communincations Agency (AFCA) AFNIC, the Army has the Installation Management Agency. These agencies moderate the certification & accreditation process. The IT Lean (aquisitions process) and the SISSU (security, interoperability, supportability, sustainability and usability) processes are integrated into the EITDR/DITPR-DON/APMS. Once you complete all the questions for you registered system, you will have accomplised complete SSAA, DIACAP, and even ISP packages.

    For more information search the public.afca.af.mil (USAF). Everything you need to know is there. Also call or email AFCA/EV to learn more.
    Army can go –>https://www.us.army.mil/suite/folder/4920492