•

» NIST

Information Security : Keeping up with the government sector – changes to FISMA and the NIST guidelines

Posted on October 17, 2010 by John Reno in Main | Leave a comment

Often the government sector is viewed as unwieldy and cumbersome when it comes to moving rapidly to take advantage of new technology. When it comes to information security this is often the case as well. Since 2002, the U.S. Federal Information Security Management Act (FISMA) has been used to help government agencies manage their information security programs. For many years FISMA has driven a compliance orientation to information security. However, new and more sophisticated threats are causing a shift in focus from compliance to risk-based protection.

FISMA 2010 will result in new requirements for system security, business continuity plans, continuous monitoring and incident response. The new FISMA requirements are supported by significant enhancements and updates to the National Institute of Standards and Technology (NIST) guidelines and Federal Information Processing Standards (FIPS). Specifically FIPS 199 and 200 as well as the NIST SP 800 series are evolving to help cope with the evolving threat landscape. While commercial organizations are not required to take any action with respect to FISMA, there is still significant influence on information security programs in the commercial sector simply because the FIPS standards and NIST guidelines are so influential in the information security community.

I would recommend that customers in both the government and commercial sectors take a close look at some of the NIST guidelines. In particular, I would call out the following:

• NIST SP 800-53: Updates to the security controls catalog and baselines.

• NIST SP 800-37: Updates to the certification and accreditation process.

• NIST SP 800-39: New enterprise risk management guidance.

• NIST SP 800-30: Revisions to provide improved guidance for risk assessments.

It’s always useful to leverage the work that the government is doing. We may as well take advantage of our tax dollars at work.

Electronic prescriptions of controlled substances – a key area where information security is paramount

Posted on June 27, 2010 by John Reno in Main | 1 Comment

Earlier this month the Drug Enforcement Administration (DEA) revised their regulations surrounding the writing of prescriptions for controlled substances electronically. The rule had been published in March on the Federal Register and is now effective. Streamlining the process associated with the e-prescribing of controlled substances has many benefits including cost reduction and improvement in the quality of care. At a recent conference some of the challenges in this area were discussed by Leisa Jenkins, executive director of CareSpark. In the region that the CareSpark RHIO serves, fraud associated with the use of controlled substances is rampant. Patients routinely take advantage of the lack of consistent medical record and cross-state jurisdictional issues to gain fraudulent access to controlled substances. Solving this problem requires that provider organizations invest in information systems and processes that address the issue. Security, privacy and compliance requirements are significant.

This area is a clear example where information security is a business enabler, a topic that I have discussed in earlier posts. It is also an area where the provider organization must ensure that they have thought through the legal defensibility associated with their information security programs.

Let’s now look at some of the security guidelines and requirements necessary for a provider organization to take advantage of e-prescribing. These recommendations apply generally to e-prescribing overall, but look closely at the problem in the context of controlled substances.
One of the critical security issues in this area is authentication. In order to meet the requirements mandated by the DEA an e-prescribing application must comply with security needs on several levels. At the heart of these requirements is two factor authentication. This is necessary for creating a controlled substance prescription, signing the prescription and obtaining the necessary credential. As usual, the National Institute of Standards and Technology (NIST) have provided guidance in this area. Specifically, the guidelines put forward in NIST special publication 800-63-1 provide recommendations. The important take-away is that authentication in the area of e-prescribing for controlled substances requires two factor authentication at NIST assurance level 3. There are several ways to meet this requirement but some technical approaches are rather advanced. Product/service combinations that I would recommend are the solutions from Anakam. In evaluating an authentication solution for this area it is not only a matter of strong security, but also dealing efficiently with the ease of use and workflow considerations in a medical environment.

Beyond authentication there are many additional challenges to deploying and sustaining a secure environment for a mission critical application such as e-prescribing. A useful point of reference is provided by Center for International and Strategic Studies (CSIS). In this report they describe the 20 critical controls necessary for effective cyber defense. Much of the work has been drawn from the experience of blue team members inside the Department of Defense. A conclusion of this report is consistent with our own experience at Redspin that application security is an area where significant investment is required. Information security teams that are charged with supporting mission critical applications such as e-prescribing need to focus not only on perimeter controls, but also on additional areas such as log monitoring, vulnerability remediation process and malware defense.

In subsequent posts I will delve further into some of the application security specifics, as well as discuss the aspects of legal defensibility associated with an information security program in this area.

Guidelines for Securing Personally Identifiable Information (PII) Data

Posted on April 15, 2010 by John Reno in Main | Leave a comment

Customers in industry segments from financial services to healthcare have struggled to protect personally identifiable information. Now the National Institute of Standards and Technology have released guidelines to help manage the process of securing PII data. Special publication 800-122, titled “Guide to Protecting the Confidentiality of Personally Identifiable Information”, helps customers to identify, classify and provide appropriate levels of protection for PII data.

The document suggests a risk based approach where resources and controls are focused on the most critical information. It also suggests controls for a given level of protection and provides guidance for developing incident response plans in the case of a breach.

To make such a risk based approach work a key step is identifying PII and classifying the data appropriately. NIST recommends the following steps for organizations:

o Identify all PII residing in their environments. Examples of PII include full names; identification numbers such as Social Security numbers, driver’s license numbers or account numbers; addresses; and personal characteristics such as photographs or biometric data.

o Limit the collection and retention of PII to what is necessary for the mission. Only the information that is necessary to meet business requirements should be collected, and that should be purged when not needed. Disposal should be done in accordance with retention schedules approved by the National Archives and Records Administration, as well as with any litigation holds placed on information.

o Data Classification -categorize PII by its impact level. The guidelines define impact as low, moderate or high, depending on the potential harm posed to the individual or agency by its loss. Factors to consider include how distinguishable personal information is, how it is organized and used, and how accessible it is.

o Apply the appropriate safeguards based on the impact level. Some PII, such as public directories, is not considered confidential and does not need to be protected. Customers should create policies and procedures for protecting PII that is confidential, conduct training on these policies, remove data from PII when possible to make it less identifiable, use access controls and encryption to protect the data, and audit events.

o Develop an incident response plan for PII breaches, including how and when individuals affected are to be notified, when a breach should be reported publicly and what remedial services such as credit monitoring should be offered to potential victims.

o Encourage close coordination between privacy officers, chief information officers, information security officers and legal counsel in addressing PII issues.

We have helped many customers successfully implement such risk based information security plans. This new work from NIST will hopefully raise the awareness and increase visibility as well as help illustrate the payback associated with carrying out an information protection plan.