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

Risk is the possibility of suffering harm or loss.  The definition in the Free Dictionary also references danger.  Harm or loss for most enterprises either comes from opportunity lost or regulatory sanction.  Either way, the situation is bad for the enterprise.

Some risks can be eliminated but most can only be mitigated by exploiting your advantages and shielding your deficiencies.  This is the essence of risk management.

I think the easiest way for an enterprise to mitigate risk is to know what it is supposed to do and then do it.  In order to understand what it is supposed to do, an enterprise must completely understand its entire set of requirements and then implement processes that satisfy those requirements.  This is not something that just happens.  It must be planned, executed, and implemented.  It must then be constantly evaluated as requirements change.

Another opportunity for risk can be found in those processes between what we do and what we’re supposed to do.  Most exception processes are ad hoc and not well designed. They arise from a crisis situation where workers have a very specific problem to solve and so they solve it.  The problem is that they don’t have or take the time to evaluate their solution against the enterprise’s entire set of requirements.  This opens the possibilities that the new process allows people to do things they shouldn’t or doesn’t make them do things they should. Both of these are risky situations.

So, the first part of managing risk is to identify those processes where the enterprise is not doing what it is supposed to be doing.  This requires that the enterprise evaluate everything it does against its entire set of requirements.  I’ll discuss remediation next time.