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