DIACAP is transitioning from a Certification and Accreditation to a Risk Management Framework. Most of the new Risk Manager Framework is in the NIST Special Publication 800-37. The old NIST SP 800-37 was also based on Certification and Accreditation. After FISMA 2002, it adjusted to a Risk Management Framework in NIST SP 800-37 Rev 1, Guide for Applying the Risk Management Framework to Federal Information Systems.
diacap-to-diarmf-ca-vs-rmf
NIST SP 800-37 to SP 800-37 rev 1 transformed from a Certification and Accreditation (C&A) process into the six-step Risk Management Framework (RMF). The changes included:
Revised process emphasizes
Building information security capabilities into federal information systems through the application of state-of-the-practice management, operational, and technical security controls
Maintaining awareness of the security state of information systems on an ongoing basis though enhanced monitoring processes
Providing essential information to senior leaders to facilitate decisions regarding the acceptance of risk to organizational operations and assets, individuals, other organizations, and the Nation arising from the operation and use of information systems
The Federal Information Security Amendments Act, H.R. 1163, Amends the Federal Information Security Management Act of 2002 (FISMA).
Main Points of FISMA 2002:
Cost-effectively reduce information technology security risks
Vulnerability Database System
Maintain an inventory of major information systems
Security Categorization of Federal IS by risk levels
Minimum security requirements
System Security planning process
Annual review of assigned IS compliance
Risk Management
The amendment has a few big changes to the previous 2002 version that will affect federal agencies. But two main ones the stood out for me is the emphasis on automation and the CISO position.
The FISMA Amendment was passed by the House of Representatives (4 April 2013) but must still pass the Senate and be signed into law by the President.
1 – Continuous monitoring / automation of Everything -FISMA 2013, requires continuous monitoring (automation) and regular cyberthreat assessments for better oversight to federal organizations.
Security Incidents - Security incidents are automatically detected with tools like McAfee Network Security Platform (IPS), Source Fire SNORT (IDS), McAfee ePO and Cisco IDS. With the right people to manage the signatures and the configuration, theses are great products. Once they are detected you can then do incident handling with something like Remedy. FISMA 2013: “with a frequency sufficient to support risk-based security decisions, automated and continuous monitoring, when possible, for detecting, reporting, and responding to security incidents, consistent with standards and guidelines issued by the National Institute of Standards and Technology”
Information Systems Security – Vulnerability scanners such as Retina and Tenable’s Nessuss are great with automatically detecting security controls and policies within an agency. Change Auditor and other tools can detect changes the GPO’s within a domain. FISMA 2013: “with a frequency sufficient to support risk-based security decisions, automated and continuous monitoring, when possible, for testing and evaluation of the effectiveness and compliance of information security policies, procedures, and practices, including…” Security controls
Risk Level & Impact of Harm – McAfee ESM and ArcSight are good and pulling in the data from security tools that detect security events, evaluating the risk level and giving an measurement of the possible harm of and asset. FISMA 2013: “automated and continuous monitoring, when possible, of the risk and magnitude of the harm that could result from the disruption or unauthorized access, use, disclosure, modification, or destruction of information and information systems that support the operations and assets of the agency;
Detection/Correlation – this one could be grouped in with Security Incident, but Security Incident gets more into incident handling. Also, ArcSight, McAfee, LogRythm, LogLogic, AlienVault and other Security Incident Event Managers do Correlation automatically. FISMA 2013: “efficiently detect, correlate, respond to, contain, mitigate, and remediate incidents that impair the adequate security of the information systems of more than one agency. To the extent practicable, the capability shall be continuous and technically automated.”
2 – CISO positions and responsibilities backed by Law – The amendment requires each department head to be held accountable for IT. In DoD Information Assurance Risk Management Framework (DIARMF) this department director is known as the Authorizing Official (aka Designated Authorizing Authority in DIACAP). FISMA 2013 require the AO to have an Chief Information Security Officer. This is a position that is already assigned under Risk Management Framework. The DoD has referred to this position as Senior Information Assurance Officer in DIACAP. Under FISMA 2013, CISO/SIAO must have must have qualifications to implement agency-wide security programs for which they are responsible
and report directly to the AO.
The CISCO/SIAO will also have responsibility of Automated Security systems. The CISO will be responsible for development, maintaining and overseeing these automated systems.
FISMA 2013 is targeted to minimize the risk of cyberattacks by conducting pentesting.
Overall, they made automation a requirement, which is the direction the field of information security has already been following and put some more emphasis on the CISO. The amendments highlight the changes from DIACAP to DIARMF as many of the changes are already in the NIST 800 series that DIARMF is based on.
Information Assurance is based on obtaining a high level of confidence on information’s confidentiality, integrity, and availability. Â Some organizations that deal with “critical information”. Â Critical information included things like banking transactions, classified data, information that is evidence in an ongoing investigation. Â Companies, unions and government that handle this kind of information usually have a lot of exposure because they are handling public data, share holder data, employee data and are doing a lot of translation across the un-trusted networks such as the Internet. Â With critical information and high exposure these organizations MUST have “approved processes” for vetting, testing and validating “approved software” and “approved systems”.
For example, in the Department of Defense there are many lists that have approved software. Â These lists are per command within larger organizations. Â One over arching process/list is the Common Criteria:
Common Criteria is an international standard for validating technical security built in to security feature of information systems. Â The international standard is known as ISO/IEC 15408.
This standard is used by many large organizations all over the world that serve the public:
www.commoncriteriaportal.org
www.commoncriteria.com
Each organization has there own specific security needs so most of the time they have many levels of application approval and process:
NSA / DOD / US Gov - www.niap-ccevs.org - National Information Assurance Partnership (NIAP) uses Common Criteria Evaluation and Validation Scheme (CCEVS) to ensure that only approved Information Assurance (IA)  and IA-Enabled Information Technology (IT) products are used
Canadian Trusted Computer Product Evaluation Criteria UK – www.cesg.gov.uk/servicecatalogue/ccitsec‎
Commercial organizations that want their products used by organization processing and storing critical information must submit to common criteria as well:
Apple – https://ssl.apple.com/support/security/commoncriteria/‎
Microsoft – www.microsoft.com/en-us/sqlserver/common-criteria.aspx‎
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.
courtesy of gabfirethemes
Current CAP Domains:
1.     Understand the Security Authorization of Information Systems
2.     Categorize Information Systems
3.     Establish the Security Control Baseline
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
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 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.
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
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.
