NIST – Compliance Guru

02 Oct 2012

Hot Topics Tom Hinkel 0 comment

BYOD Redux – The Policy Solution (Part 2)

In the previous post, I suggested that because mobile devices (smart phones and PDA’s) were not that functionally different in how they process, transmit, and store information than other mobile computing devices like laptops, a separate policy wasn’t necessary. Since data security, confidentiality and integrity concerns were the same as other devices, you should be able to simply extend your existing policy to include them. But in fact the risks are greater, and often more difficult to control, resulting in substantially higher residual risk (risk remaining after the application of controls) than other computing devices. Because of this, employee-owned mobile devices really represent an exception to your policies as opposed to an extension of them. And because all policy exceptions must be approved by your Board, perhaps separate policies and procedures are appropriate.

The FFIEC is fairly silent on this topic, but fortunately the NIST is in the process of formulating several pieces of guidance on risk managing BYOD, and it is always useful to see where they are on this issue as very often we’ve seen NIST guidelines make their way into other federal regulations.

NIST Special Publication 800-124 entitled “Guidelines for Managing and Securing Mobile Devices in the Enterprise” is currently in draft status, and is an update to a 2008 document “Guidelines on Cell Phone and PDA Security”. The updated guidance recognizes the evolution of the technology over the past few years, as well as the unique security challenges inherent in both corporation and employee-owned mobile computing devices. They advise institutions to implement the following guidelines to improve the security of their mobile devices:

Develop system threat models for mobile devices and the resources that are accessed through the mobile devices. Recognize that these devices are not the same as your other computing devices. The threats are not the same and the available controls are not the same, therefore both the probability and the impact of an attack on these devices is likely greater. Make sure your threat model understands how the device will connect to your network, and what data it will transmit and store. Data-flow diagrams can be very helpful in this modeling process.
Once the threat is understood, deploy only those devices that offer the minimum threat required given the job requirements of the employee. This will be one of the biggest challenges for institutions, as many employees will want the latest devices with all the bells and whistles. Prior to deploying, make sure you have centralized mobile device management that offers the following minimum capabilities:

• Ability to enforce enterprise security policies, such as user rights and permissions, as well as the ability to report policy violations.
• Data communication and storage should be encrypted, with the ability to remotely wipe the device.
• User authentication should be required before the device can access enterprise resources, with incorrect password lockout periods consistent with your other computing devices.
• Restrict which applications may be installed, and have procedures in place for updating the applications and the operating system.

Have a separate mobile device policy. The policy should define which types of mobile devices are permitted to access the institution’s resources, the degree of access that mobile devices may have, and how they will be managed. It should differentiate between institution-owned and employee-owned devices, and be as consistent as possible with your policy for non-mobile devices.
Test the policy initially, and periodically thereafter, to verify management capabilities. Perform either passive (log review) or active (PEN testing) assessments to confirm that the mobile device policies, procedures and practices are being followed properly.
Secure each device prior to deployment. This is slightly easier for institution-owned devices, much harder (but arguably more important) for already deployed, employee-owned devices.

I’m sure you can already hear the howls of protest for this last one, but the guidance actually states that for employee-owned (BYOD) devices organizations should recover them, restore them to a known good state, and fully secure them before returning them to their users.

So when it comes to BYOD you basically have two choices; you can properly manage the devices and the risks consistent with your other computing devices, or you can recognize that they represent a deviation from your risk management policies and get Board approval for the exception. And if you choose to classify them as policy exceptions, you should be prepared to explain the potential impact of the higher risk to the organization, and exactly how the higher risk is justified.

21 Aug 2012

Hot Topics Tom Hinkel 0 comment

NIST Incident Response Guidance released

UPDATE – The National Institute of Standards and Technology (NIST) has just released an update to their Computer Security Incident Handling Guide (SP 800-61). The guide contains very prescriptive guidance that can be used to frame, or enhance, your incident response plan. It also contains a very useful incident response checklist on page 42. I’ve taken the liberty of modifying it slightly to conform to the FFIEC guidance. It is form-fillable and available for download here. I hope you find it useful for testing purposes as well as actual incidents. I originally posted on this back in May 2012, here is the rest of the original post:

Although adherence to NIST standards is strictly required for Federal agencies, it is not binding for financial institutions. However NIST publications are referred to 10 times in the FFIEC IT Handbooks, 8 times in the Information Security Handbook alone. They are considered a best-practice metric by which you can measure your efforts. So because of…

The importance of properly managing an information security event,
The increasing frequency, complexity, and severity of security incidents,
The scarcity of recent regulatory guidance in this area, and
The relevance of NIST to future financial industry regulatory guidance,

…it should be required reading for all financial institutions.

Incident response is actually addressed in 4 FFIEC Handbooks; Information Security, Operations, BCP and E-Banking. It’s important to distinguish here between a security incident and a recovery, or business continuity, incident. This post will only address security incidents, but guidance states that the two areas intersect in this way:

“In the event of a security incident, management must decide how to properly protect information systems and confidential data while also maintaining business continuity.”

Security incidents and recovery incidents also share this in common…both require an impact analysis to prioritize the recovery effort.

So although there are several regulatory references to security incident management, none have been updated since 2008 even though the threat environment has certainly changed since then. Perhaps SP 800-61 will form the basis for this update just as SP 800-33 informed the FFIEC Information Security Handbook a few years after its release. But until it does, proactive Information Security Officers and Network Administrators would do well to familiarize (or re-familiarize) themselves with the basic concepts.

NIST defines the incident life-cycle this way:

Each section is detailed in the guide, and worth reading in its entirety, but to summarize:

Preparation – Establish an incident response capability by defining a policy (typically part of your Information Security Program), and an incident response team (referred to in the FFIEC IT Handbook as the Computer Security Incident Response Team, or CSIRT). Smaller institutions may want to have the IT Steering Committee manage this. Assess the adequacy of your preventive capabilities in the current threat environment, including patch management, Anti-virus/Anti-malware, firewalls, network intrusion prevention and server intrusion prevention. Don’t forget employee awareness training…perhaps the most important preventive control.
Detection & Analysis – Determine exactly what constitutes an incident, and under what circumstances you will activate your incident response team and initiate procedures. Signs of an incident fall into one of two categories: precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. Many of the controls listed in the preparation phase (firewalls, IPS/IDS devices, etc.) can also alert to both precursors and indicators. The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident (steps 3 & 4).
Containment, Eradication & Recovery – Most incidents require containment to control and minimize the damage. An essential part of containment is decision-making i.e., shutting down a system, disconnecting it from a network, disabling certain functions, etc. Although you may be tempted to start the eradication and recovery phase immediately, bear in mind that you’ll need to collect as much forensic evidence as possible to facilitate the post-incident analysis.
Post-Incident Activity – Simply put, lessons learned. It’s easy to ignore this step as you try to get back to the business of banking, but don’t. Some important questions to answer are:

Exactly what happened, and at what times?
How well did staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate?
Were any steps or actions taken that might have inhibited the recovery?
What could we do differently the next time a similar incident occurs?
What corrective actions can prevent similar incidents in the future?
What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

The FFIEC addresses intrusion response here, and recommends that “institutions should assess the adequacy of their preparations through testing.” Use the checklist, and recent security incidents to train your key CSIRT personnel, and then use the full guide to fine-tune and enhance your incident response capabilities.

20 Aug 2012

Hot Topics Tom Hinkel 0 comment

Incident Response guidance – UPDATE

The importance of properly managing an information security event,
The increasing frequency, complexity, and severity of security incidents,
The scarcity of recent regulatory guidance in this area, and
The relevance of NIST to future financial industry regulatory guidance,

…it should be required reading for all financial institutions.

“In the event of a security incident, management must decide how to properly protect information systems and confidential data while also maintaining business continuity.”

Security incidents and recovery incidents also share this in common…both require an impact analysis to prioritize the recovery effort.

NIST defines the incident life-cycle this way:

Each section is detailed in the guide, and worth reading in its entirety, but to summarize:

Preparation – Establish an incident response capability by defining a policy (typically part of your Information Security Program), and an incident response team (referred to in the FFIEC IT Handbook as the Computer Security Incident Response Team, or CSIRT). Smaller institutions may want to have the IT Steering Committee manage this. Assess the adequacy of your preventive capabilities in the current threat environment, including patch management, Anti-virus/Anti-malware, firewalls, network intrusion prevention and server intrusion prevention. Don’t forget employee awareness training…perhaps the most important preventive control.
Detection & Analysis – Determine exactly what constitutes an incident, and under what circumstances you will activate your incident response team and initiate procedures. Signs of an incident fall into one of two categories: precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. Many of the controls listed in the preparation phase (firewalls, IPS/IDS devices, etc.) can also alert to both precursors and indicators. The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident (steps 3 & 4).
Containment, Eradication & Recovery – Most incidents require containment to control and minimize the damage. An essential part of containment is decision-making i.e., shutting down a system, disconnecting it from a network, disabling certain functions, etc. Although you may be tempted to start the eradication and recovery phase immediately, bear in mind that you’ll need to collect as much forensic evidence as possible to facilitate the post-incident analysis.
Post-Incident Activity – Simply put, lessons learned. It’s easy to ignore this step as you try to get back to the business of banking, but don’t. Some important questions to answer are:

Exactly what happened, and at what times?
How well did staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate?
Were any steps or actions taken that might have inhibited the recovery?
What could we do differently the next time a similar incident occurs?
What corrective actions can prevent similar incidents in the future?
What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

06 Feb 2012

Hot Topics Tom Hinkel 0 comment

NIST releases new Cloud Computing Guidelines

Although not specific to the financial industry, the new guidelines provide a comprehensive overview of the privacy and security challenges of this increasingly popular computing model. It’s worth a look by both financial institutions considering cloud-based services, as well as service providers, because NIST guidelines often wind up as the basis for new or updated regulatory guidance.

They start by defining the concept of cloud computing as characterized by the “…displacement of data and services from inside to outside the organization” and by correctly observing that “…many of the features that make cloud computing attractive, however, can also be at odds with traditional security models and controls.” This pretty accurately summarizes the challenges faced by financial institutions as they consider, and try to manage, the risks of cloud computing…data and services are out of their direct control, but risks of privacy, security, confidentiality, data integrity and availability must be controlled.

NIST offers the following guidelines for overseeing cloud services and service providers:

Carefully plan the security and privacy aspects of cloud computing solutions before engaging them.
Understand the public cloud computing environment offered by the cloud provider.
Ensure that a cloud computing solution satisfies organizational security and privacy requirements.
Ensure that the client-side computing environment meets organizational security and privacy requirements for cloud computing.
Maintain accountability over the privacy and security of data and applications implemented and deployed in public cloud computing environments.

For financial institutions, all these guidelines should be addressed in your existing policies. The privacy and security elements are mandated by GLBA, and should already be present in your information security program. One of the required, but often overlooked, elements of your vendor management program is the requirement to strategically justify your decision to engage a cloud services provider, and periodically review and reaffirm that decision. Understanding the cloud provider environment is indeed a challenge for financial institutions, and I have already addressed this, and some possible solutions, here. I’ve also discussed why increased adoption of cloud-based services will likely make vendor management a topic of increased regulatory scrutiny in 2012 here. Additionally I think that the new SOC 2 report will directly address many of the concerns facing institutions employing cloud-based services.

As for the FFIEC, I was surprised to see that a search of the word “cloud” on the IT Examination InfoBase turned up not one single mention. The Handbooks are getting a bit dated…perhaps, given the importance of managing outsourced relationships, plus the increased challenges of cloud computing, they should address this next? Or do you think the existing guidance on managing outsourced technology and vendors is sufficiently broad?