Category: Hot Topics

13 Sep 2012
Hot Topics Tom Hinkel 0 comment

BYOD Redux – The Policy Dilemma (Part 1)

Employee-owned mobile devices are everywhere, and they’re being used for everything from email to document storage and editing.  Proper risk management procedures are defined in your policies, but do you need a separate mobile device policy, or can you simply mention them in the same policy sections that address other portable devices?  Or is there another option you need to consider?  Let’s follow the same risk management process for mobile device deployment as you would to deploy any other new technology:

    1. First, before mobile devices are deployed, a decision is made that they should be considered for implementation because they will somehow further the goals and objectives of the strategic plan.
    2. Next, a cost-benefit analysis is done, and the results should reinforce the decision to implement.
    3. Finally, a risk assessment is conducted that identifies potential risk exposure due to unauthorized disclosure of customer, confidential, or sensitive information.

Since most mobile devices can process, store, and transmit information, this looks very similar to your risk assessment for other portable computing devices like laptops.  (Indeed the FFIEC mentions “…laptops and other mobile devices…” together  in their Information Security Handbook, suggesting the risks are similar.)  Except in this case the risk is magnified by the extreme portability of the devices, the “always-on” and “always-remote” nature of them, and the fact that many more people will use mobile devices than will use laptops.

Once the inherent risk is assessed (most likely higher than your other computing devices), controls are identified to reduce the risk.  Again, since the capabilities are similar, the list of potential administrative and technical controls looks very similar to those on your other computing devices.  Your existing policy probably mandates that there first be a legitimate business reason for the employee to use a portable device.  Once need is established, the employee agrees to a “proper use” policy, i.e.  what is allowed and what isn’t.  Finally, technical controls are applied; 8-10 character complex passwords, encrypted storage, patch management, Anti-virus/Anti-malware software, user rights and permissions restrictions, Active Directory integration, etc.  But even if you’ve followed your risk management procedures to the letter so far, this is where the real challenges begin, because mobile devices simply don’t have the same controls available to them that other portable devices like laptops do.  There are some additional controls available (like remote-wipe capability), but the end result of your risk assessment would most likely be that you have a higher inherent risk and insufficient controls, leading to a higher residual risk.  Under “normal” conditions, this would lead to a decision to NOT deploy mobile devices until risks can be reduced within acceptable levels, right?

And yet they are ubiquitous.

So back to the original question.  I’m not a big believer of writing a new policy to accommodate every new piece of technology you decide to implement unless the technology cannot be accommodated within your existing policy framework.  It is far easier to make a simple policy change by mentioning the new technology, thereby acknowledging that it exists and that it fits within your current policy framework.  But in this case you are not really making a change, you are actually making a policy exception.  You are admitting that the residual risk of BYOD is unacceptably high, but that you are willing to accept the additional risk in return for potential productivity gains.  Since the Board of Directors is responsible for providing “…clear guidance regarding acceptable risk exposure levels…”, and for ensuring that “…appropriate policies, procedures, and practices have been established”, policy exceptions must be approved by the Board as well.   It is your responsibility to make sure they understand exactly what the risks are, and why you feel they are risks worth taking.

Hopefully risk management controls for mobile devices will continue to evolve and mature to the point where they match controls for the other portable devices you currently manage.  But until they do, until they are capable of being risk managed consistent with your existing policies, they (and all policy exceptions) represent an net reduction in your existing security profile.  And you cannot rationalize or justify taking short-cuts just because “everyone else is doing it”…or even worse, “we can’t stop it”.

Next, I’ll discuss possible solutions to this risk management challenge.

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…

  1.  The importance of properly managing an information security event,
  2. The increasing frequency, complexity, and severity of security incidents,
  3.  The scarcity of recent regulatory guidance in this area, and
  4.  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:

  1. 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.
  2.  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).
  3. 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.
  4. 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

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.  Here is 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…

  1.  The importance of properly managing an information security event,
  2. The increasing frequency, complexity, and severity of security incidents,
  3.  The scarcity of recent regulatory guidance in this area, and
  4.  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:

  1. 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.
  2.  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).
  3. 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.
  4. 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.

08 Aug 2012
Hot Topics Tom Hinkel 0 comment

7 Cloud Vendor Deal Breakers for Financial Institutions

With all the recent focus on vendor management in general, and cloud vendors in particular, there has been a lot of discussion about changing regulatory requirements and best practices.  For the most part, cloud vendors must adhere to the same due diligence, contract, and monitoring guidelines as any other vendor  However there are a few (often overlooked) elements that must be considered prior to engaging any cloud-based vendor.  Elements important enough to be deal breakers if you (and they) can’t answer “yes”.

  1. Do they contractually hold themselves to the same high data privacy, security, confidentiality, integrity and availability standards required of financial institutions?   It used to be understood that anyone offering services to financial institutions had to contractually adhere to GLBA guidelines, but with all the relatively new vendors competing for your business, it can’t be assumed or taken for granted any more.  Make sure the contract stipulates it.
  2. If so, can they document adherence to that standard by producing a third-party report, like the SOC 2?  Even if the contract stipulates adherence, you must determine the adequacy and effectiveness of a servicer’s internal controls by requesting, receiving and reviewing the appropriate third-party report prior to engaging…and then periodically throughout the relationship.
  3. Do you know exactly where your data will be physically stored?  Both the biggest strength and the biggest weakness for cloud vendors is in the redundant and distributed nature of the data.  Having data stored multiple times in multiple locations throughout the country is great for high availability, but makes it almost impossible to ensure compliance with your policies for proper handling and storing of information.  You must know where you data is located at all times, and how it gets there.  And if your data is transmitted or stored outside the U.S., you’ll need to understand the rules and regulations of the hosting country.
  4. Will they retain and destroy information consistent with your internal data retention policies?  Internal retention and destruction policies must be observed regardless of how or where the data is stored.  If the data is stored in multiple locations, are all occurrences destroyed?  There may be additional regulatory and legal exposure if data is either destroyed too early, or retained too long.
  5. What happens to your data once your relationship with the vendor is terminated?  The vendor disengagement process is particularly challenging with cloud vendors because you can’t simply walk away any more than you can just throw out a hard drive.  Is the data irretrievably wiped, or simply deleted?  What about the encryption keys?
  6. Do they have a broad and deep familiarity with the regulatory requirements of the financial industry?  According to the most recent statement from the FFIEC on managing cloud vendors, because of the increased legal and regulatory risks, “managing a cloud computing service provider may require additional controls if the servicer is unfamiliar with the financial industry”.
  7. If so, are they willing and able to make changes to their service offerings necessitated by those requirements? Even if the vendor demonstrates adequate familiarity with the financial industry, are they willing to make the necessary changes in their services if and when regulations change?  Unless financial companies make up the majority of their clientele, they may not be, and “under such circumstances, management may determine that the institution cannot employ the servicer.”
03 Aug 2012
Hot Topics Tom Hinkel 0 comment

Risk Assessing iCloud (and other online backups) – UPDATE 2, DropBox

Update 2 (8/2012) – Cloud-based storage vendor DropBox confirmed recently that a stolen employee password led to the theft of a “project document” that contained user e-mail addresses. Those addresses were then used to SPAM DropBox users.  The password itself was not stolen directly from the DropBox site, but from another site the employee used.  This reinforces the point I made in a previous post about LinkedIn.  If you have a “go-to” password that you use frequently (and most people do) you should assume that it’s out there in the wild, and you should also assume it is now being used in dictionary attacks.  So change your DropBox password, but also change all other occurrences of that password.

But passwords (and password change policies!) aside, serious questions remain about this, and other, on-line storage vendors:

  1. Do they hold themselves to the same high information confidentiality, integrity and availability standards required of financial institutions?
  2. If so, can they document adherence to that standard by producing a third-party report, like the SOC 2?
  3. Will they retain and destroy information consistent with your internal data retention policies?
  4. What happens to your data once your relationship with the vendor is terminated?
  5. Do they have a broad and deep familiarity with the regulatory requirements of the financial industry, and are they willing and able to make changes in their service offerings necessitated by those requirements?

Any vendor that can not address these questions to your satisfaction should not be considered as a service provider for data classified any higher then “low”.

________________________________________________________

Update 1 (3/2012) – A recent article in Data Center Knowledge  estimates that Amazon is using at least 454,400 servers in seven data center hubs around the globe.  This emphasizes my point that large cloud providers with widely distributed data storage make it very difficult for financial institutions to satisfy the requirement to secure data in transit and storage if they don’t know exactly where the data is stored.

________________________________________________________

Apple recently introduced the iCloud service for Apple devices such as the iPhone and iPad.  The free version offers 5GB of storage, and additional storage up to 50GB can be purchased.  The storage can be used for anything from music to documents to email.

Since iPhones and iPads (and other mobile devices) have become ubiquitous among financial institution users, and since it is reasonable to assume that email and other documents stored on these devices (and replicated in iCloud) could contain non-public customer information, the use of this technology must be properly risk managed.  But iCloud is no different than any of the other on-line backup services such as Microsoft SkyDrive, Google Docs, Carbonite, DropBox, Amazon Web Services (AWS) or our own C-Vault…if customer data is transmitted or stored anywhere outside of your protected network, the risk assessment process is always the same.

The FFIEC requires financial institutions to:

  • Establish and ensure compliance with policies for handling and storing information,
  • Ensure safe and secure disposal of sensitive media, and
  • Secure information in transit or transmission to third parties.

These responsibilities don’t go away when all or part of a service is outsourced.  In fact, “…although outsourcing arrangements often provide a cost-effective means to support the institution’s technology needs, the ultimate responsibility and risk rests with the institution.“*  So once you’ve established a strategic basis  for cloud-based data storage, risk assessing outsourced products and services is basically a function of vendor management.  And the vendor management process actually begins well before the vendor actually becomes a vendor, i.e. before the contract is signed.  Again, the FFIEC provides guidance in this area:

Financial institutions should exercise their security responsibilities for outsourced operations through:

  • Appropriate due diligence in service provider research and selection,
  • Contractual assurances regarding security responsibilities, controls, and reporting,
  • Nondisclosure agreements regarding the institution’s systems and data,
  • Independent review of the service provider’s security though appropriate audits and tests, and
  • Coordination of incident response policies and contractual notification requirements.*

So how do you comply (and demonstrate compliance) with this guidance?  For starters, begin your vendor management process early, right after the decision is made to implement cloud-based backup.  Determine your requirements and priorities (usually listed in a formal request for proposal), such as availability, capacity, privacy/security, and price…and perform due diligence on your short list of potential providers to narrow the choice.  Non-disclosure agreements would typically be exchanged at this point (or before).

Challenges & Solutions

This is where the challenges begin when considering large cloud-based providers.  They aren’t likely to respond to a request for proposal (RFP), nor are they going to provide a non-disclosure agreement (NDA) beyond their standard posted privacy policy. This does not, however, relieve you from your responsibility to satisfy yourself any way you can that the vendor will still meet all of your requirements.  One more challenge (and this is a big one)…since large providers may store data simultaneously in multiple locations, you don’t really know where your data is physically located.  How do you satisfy the requirement to secure data in transit and storage if you don’t know where it’s going or how it gets there?  Also, what happens if you decide to terminate the service?  How will you validate that your data is completely removed?  And what happens if the vendor sells themselves to someone else.  Chances are your data was considered an asset for the purposes of valuing the transaction, and now that asset (your data) is in the hands of someone else, someone that may have a different privacy policy or may even be located in a different country.

The only possible answer to these challenges is bullet #4 above…you request, receive and review the providers financials and other third-party reviews (SOC, SAS 70, etc).  Here again, large providers may not be willing to share information beyond what is already public.  So the answer actually presents an additional challenge.

Practically speaking, perhaps the best way to approach this is to have a policy that classifies and restricts data stored in the cloud.  Providers that can meet your privacy, security, confidentiality, availability and data integrity requirements would be approved for all data types, providers that could NOT satisfactorily meet your requirements would be restricted to storing only non-critical, non-sensitive information.  Of course enforcing that policy is the final challenge…and the topic of a future post!  In the meantime, if your institution is using cloud-based data storage, how are you addressing these challenges?

* Information Security Booklet – July 2006, Service Provider Oversight

© 2025 UFS Tech. All rights reserved. Compliance Guru is a registered trademark of UFS Tech. Privacy Policy