Target Corporation is still reeling from the discovery that they had been hacked and made vulnerable the financial information of millions of their customers. Other retailers have made or will make similar discoveries. Those will be announced on an on-going basis.
Information system security should be an integral part of any Enterprise Architecture program. Information system security is built in to Business-driven Enterprise Architecture because BDEA is a safeguard process as is security.
The US Federal government is under a law called the Federal Information Security Management Act of 2002, or FISMA. FISMA is the basis for various government security standards such as HIPAA and IRS Publication 1075. Frankly, these standards should be used by everyone, public and private sector, because they are rigorous and comprehensive. I would imagine that Target is thinking about them right now.
Implementing FISMA is not cheap but you can consider the cost as paying an insurance premium rather than paying an insurance claim after your system has been invaded. At that point, your organization will have no choice but to implement a similarly rigorous security program and absorb those costs in addition to all the costs of the government fines and customer compensation that will be required. Like the old FRAM oil filer commercial said, “You can pay me now, or pay me later”. Paying now is far less expensive. The cost of the negative publicity and its effect on ongoing sales will dwarf the cost of implementing the program proactively. Implementing a FISMA-level security program does not make your enterprise instantly immune to intrusions and loss. It does help you prove that you took all due diligence to protect data while testifying in one of the myriad lawsuits that will occur after you have been hacked.
FISMA does allow some flexibility in implementation. Once you have identified a risk, you have the opportunity to develop controls ($$) or to document acceptance of the risk with sign-off by the assuming officer. Acceptance is much less expensive out-of-pocket but the assuming officer might very well have to later justify his actions in a court of law. Another strategy is to develop a POA&M (see below) and develop the security control as the milestone.
The reference materials for these standards are quite decentralized. I have created a short primer for navigating them below. Please keep in mind that I am an Enterprise Architect and not an Information Security professional. Ask an Information Security pro to interpret these documents for you.
FIPS 200 documents the Minimum Requirements for Federal Information Systems Security. These are the minimum security requirements for US Government agency business systems; not black ops systems.
The security model is based upon a system criticality measure for confidentiality, integrity, and availability. FIPS 199 provides the guidance to determine System Criticality.
FIPS 200 also references a Risk Management Framework. That is defined in NIST 800-37. The framework with external references is:
- Categorize Information System (FIPS 199)
- Select Security Controls (NIST 800-53)
- Implement Security Controls
- Assess Security Controls (NIST 800-53a)
- Authorize Information System
- Monitor Security Controls (NIST 800-53a)
FIPS 200 also specifies 17 security-related areas that must be addressed in a comprehensive security plan. The function points (Security Controls) required to address each area are defined by the system criticality measurement. Security Controls are the management, operational, and technical safeguards or countermeasures prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. The actual definition for each security control for each criticality level is found in NIST Special Publication 800-53. There are specifications that go beyond those mandated by the standard which are deemed optional based on the environmental situation of a given system. Criteria for auditing and evaluating these controls are found in the companion publication NIST Special Publication 800-53a.
A Security Technology Implementation Guideline (STIG) is a specific configuration for a specific technology specified by the Defense Information Systems Administration (DISA). These guidelines can also be found in the National Vulnerability Database. The DISA versions are generally used because they are concise and well-formatted.
DIACAP is a standardized methodology for evaluating the security posture of Department of Defense (DoD) Information Systems for certification and accreditation.
A Security Finding is a specific situation where a system security control is not met. It must be classified (Category) and have a POA&M developed. A Plan of Action and Milestones (POA&M) is required whenever a current state of a Security Control does not meet the future state need.
Vulnerability Security Code Definitions
- Category I – Vulnerabilities that will directly and immediately result in loss of Confidentiality, Integrity, or Access
- Category II – Vulnerabilities that have a potential to result in loss of Confidentiality, Integrity, or Access
- Category III – Vulnerabilities whose existence degrades measures to protect Confidentiality, Integrity, and Access
There are many hyperlinks in this document that refer to sites beyond our control. If you come across a broken link, please leave a comment here and we’ll get it fixed as soon as possible.
Added link to first line of post showing just how bad things have become at Target
This article appeared on March 14, 2014. It’s getting worse.
The problem with DIACAP imtpomenlatien results from all the additional processes introduced by the people that are charged with the imtpomenlatien. DIACAP is outlined within DoDI 8510.01 and utilizes the security controls contained within DoDI 8500.2 which are further explained within the DIACAP Knowledge Service. DIACAP is fundamentally simple.In the simplest form DIACAP should work as such;- Collect the data required to identify the resource and populate the attributes that comprise the System Identification Profile (SIP)- Use the Mission Assurance Category (MAC) and Confidentiality Level (CL) to identify the security controls required for resource protection and list them on the DIACAP Implementation Plan (DIP) – Track the imtpomenlatien of required security controls using the DIP- Perform a controls validation test (CVT) to verify and validate (V&V) that the controls have been implemented correctly – Use the results from the CVT interviews, documentation/demonstrations, observations, and tests (IDOT) to assign a compliance rating to each of the required security controls- Indicate the compliance rating for each control on the Scorecard- Transfer all non-compliant (NC) and not applicable (NA) controls to the Plan of Action and Milestones (POA&M)- Assign a severity category to all non-compliant security controls on the POA&M- Work the POA&M items with the highest severity category and impact code first- Meet with the Certifying Authority (CA) to review the DIACAP Artifacts (SIP, DIP, Scorecard, and POA&M) and receive an accreditation determination- CA recommends that an accreditation decision be made by the Designated Approval Authority (DAA) and/or may require additional POA&M items to be mitigated- DAA annotates the accreditation decision on the Scorecard- Maintain compliance posture through periodic CVTs and annual reviewsThe introduction of processes that deviate or attempt to modify DIACAP is what causes the complication. For instance, DIACAP recognizes that a control may be inherited from another source but there are organizations that attempt to introduce the inheritance of a portion of a control – the validation step. Understandably this is to report to managers the actual validation step of the control that is non-compliant and subsequently the organization responsible; ideally so it can be properly funded and fixed and not to shift blame. However, one can argue that if any portion of a security control is inherited, the control is inherited. After all, if any portion of a security control is non-compliant, the whole security control is non-compliant. DIACAP was introduced to manage the level of risk associated with interconnecting systems. Unfortunately, it has been twisted into something that is in some extreme cases crippling to the organization. The problems that are present in DIACAP will be present in DIARMF unless the imtpomenlatien is handled more delicately. The people that are responsible need to be properly trained and excessive modification/deviation from the process should be restricted. For instance consider a high school report card for a child. The report card lists all the courses that the child is taking and the present condition of the child’s performance in each of those courses. Whether the child’s parents realizes it or not they either accept the performance and the associated risk or put into action a plan to improve the performance and consequently the grade. Periodic assessments can help reassure that the plan is working but the true performance gauge is the next report card. I hope the similarities to the DIACAP DIP, Scorecard, and POA&M are obvious. RG
Updated broken links to externally referenced documents.