Articles for February 2014

Let’s Talk Information System Security

Date: February 28, 2014 Author: Jeff Comments: 4 Replies

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

Safeguard Processes

Date: February 12, 2014 Author: Jeff Comments: Leave a reply

Safeguard processes protect the Factory Process to ensure it is not being abused.  These activities ensure that you are doing the “right” things right. The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems. This can lead to all manner of problems. Let’s use the following example to illustrate various safeguards to a factory process.

This is tax season in the United States. Taxpayers are voluntarily computing their final tax bulls for the preceding year and are squaring their accounts with the IRS. Some people owe a little more and some people paid too much during the year and are due a refund. The IRS has implemented an electronic filing system that relies on independent software developers and web hosters to help taxpayers through the process.  This results in a system (the Factory Process) that allows the IRS to process a very large number of tax returns very quickly with little human intervention.

The IRS spot checks taxpayer accounts using the dreaded tax audit.  The IRS will select a taxpayer and ask him to visit them and bring his tax returns and records for for a designated number of past filings.  The IRS will comb through those records and determine whether the taxpayer’s filing present an honest account of reality.  This is a Safeguard process for the IRS.  The threat and execution of these audits protect the Factory Process by encouraging the taxpayers to provide honest accounting of their tax years.

Unfortunately, tax audits only protect the system from real, honest taxpayers who can be located once the IRS decides to audit them.  There is an increasing business of defrauding the IRS by filing returns for non-existent taxpayers or for taxpayers whose identities have been stolen and having the IRS deposit a refund amount in a bank account from which the money can be immediately swept beyond their reach.  This scheme depends on forged documentation that is processed before its veracity is checked.  The IRS is now using more prospective methods of identity verification and cross checking employer records against employee claims.  These too are Safeguard processes because they help prevent the processing of fraudulent transactions.

So you see, Safeguard processes can be placed anywhere within the Factory Process.  Edits and cross checks are prospective or in-line Safeguards.  Audits are retrospective Safeguards.  Both types help the IRS collect and retain the maximum amount of revenue owed by taxpayers.  It is very important to find and utilize every means to protect the Factory Process from abuse.