Category: Hot Topics

09 Apr 2012

FFIEC Handbook Update – SAS 70 Transition

The FFIEC has just updated their online IT Examination InfoBase to address the AICPA phase-out of the SAS 70 reporting format.  All references to “SAS 70” have now been replaced, and the SAS 70 sections of the Audit and Information Security Handbooks have been completely removed.  Previously there were a total of 31 references to “SAS 70” in 8 different Handbooks.

I wrote about this a number of times, and speculated about when the FFIEC would update their Handbooks, and what would replace the term.  For the most part “SAS 70” has been replaced with “SSAE 16”, but there are also references to the SOC 2 and SOC 3 reports, as well as a more generic “other third-party review processes”.  I’m happy to see the FFIEC is allowing for more flexibility in the choice of vendor control reports they consider acceptable.  I’ve also made the case that although this does make the vendor management process a bit more challenging, institutions should welcome the transition.

20 Mar 2012

FDIC issues FIL addressing proper use of Bank information

Although a quick read of this FIL makes it seem that it only addresses the proper use of confidential information after the institution is placed into receivership, it really has implications for the bank officers, directors and legal counsel of all financial institutions.    I’ll explain that in a moment, but first the FIL makes the following points:

  • Officers and directors have a fiduciary responsibility to act in the best interests of the institution at all times.
  • In the pursuit of that responsibility, access to institution records is essential.
  • If the institution goes into receivership, the receiver (FDIC) becomes the owner of the institutions’ records.
  • Officers and directors of failed or failing institutions who remove FI records in anticipation of litigation or enforcement activity against them may be in breach of their fiduciary duty.

It has been my experience that the vast majority of FIL’s are issued re-actively, instead of pro-actively, so I think it’s safe to assume that the FDIC has actually seen occasions where financial institution records have been removed and used by officers and directors for reasons other than for the benefit of the institution.  So if you are an officer or director, the clear message here is that using FI records to prepare for or defend against litigation is acting in your best interests, NOT the best interests of the institution*.  And legal counsel representing officers and directors must not advise their clients to copy or remove institution records under penalty of civil money penalties, consent orders, or removal and prohibition from the banking industry.

In addition to the “fiduciary responsibility” argument against possessing records, the FDIC also make an argument from confidentiality (GLBA Part 364b , SAR confidentiality, and Fair Credit Reporting regulations), and this has very real implications for all officers and directors regardless of the financial condition of the FI.  Here’s why…how many of your officers and directors receive confidential information?  All of them probably, right?  Board reports, examination reports, loan packages, audit committee minutes, etc.,  all are essential to performing their fiduciary duties.  Now how many of those records go off-site, and how are those records being secured in transit, use, and storage?  Are records stored off-site treated with the same document retention and destruction policies as those stored in-house?  The FDIC may not have the same motivation to go after officers and directors of healthy institutions that they do failed ones, but it is clear they expect records to be treated the same regardless of the physical location.  How are you distributing this information?  We’ve seen an increased interest in institutions using technologies such as iPads and cloud-based portals to distribute director reports, but you must be careful not to let convenience trump security.  Use this FIL as an excuse to review your records safekeeping practices and make sure you (and your officers and directors) are adhering to your data confidentiality, security, retention and destruction policies, wherever the data resides.

 

*The FDIC does recognize that officers and directors may have a legitimate need to access institution records to defend themselves from litigation, but they require that access to be arraigned formally through them, and only after signing confidentiality agreements.

12 Mar 2012

Risk Managing BYOD (bring your own device)

Thanks in part to social media, users today often don’t differentiate between work and non-work activities, and they certainly don’t want to have to carry multiple work/non-work devices to keep them connected.    As a result, new multi-function, multi-purpose mobile devices are constantly being added to your secure financial institution network…and often in violation of your policies.

Most institutions have an IT Acquisition Policy, or something similar, that defines exactly how (and why) new technology is requested, acquired, implemented and maintained.  The scope of the policy extends to all personnel who are approved to use network resources within the institution, and the IT Committee (or equivalent) is usually tasked with making the final purchasing decision.   And although older policies may use language like “microcomputers”, and “PC’s”, the policy effectively covers all network connected devices, including the new generation of devices like smartphones and iPads.  And managing risk always begins with the acquisition policy…before the devices are acquired.

Your policy may differ in the specific language, but it should contain the following basic elements required of all requests for new technology:

  • Description of the specific hardware and software requested, along with an estimate of costs (note what type of vendor support is available).
  • Description of the intended use or need for the item(s).
  • Description of the cost vs. benefits of acquiring the requested item(s).
  • Analysis of information security ramifications of requested item(s).
  • Time frame required for purchase.

Most of these are pretty straightforward to answer, but what about bullet #4?  Are you able to apply the same level of information security standards to these multifunctional devices as you are to your PC’s and laptops?  Or does convenience trump security?  This is where the provisions of your information security policy take over.

The usefulness of these always-on mobile devices is undeniable, and they have really bent the cost/benefit curve, but they have also re-drawn the security profile in many cases.  The old adage is that a chain is only as strong as its weakest link, and in today’s IT infrastructure environment these devices are often the weak links in the security chain.  So while your users have their feet on the accelerator of new technology adoption, the ISO (and the committee managing information security) needs to have both feet firmly on the brake unless they are willing to declare these devices as an exception to their security policy…which is definitely not recommended.

So how can you effectively manage these devices within the provisions your existing information security program, without compromising your overall security profile?  It might be worth reviewing what the FFIEC has to say about security strategy:

Security strategies include prevention, detection, and response, and all three are needed for a comprehensive and robust security framework. Typically, security strategies focus most resources on prevention. Prevention addresses the likelihood of harm. Detection and response are generally used to limit damage once a security breech has occurred. Weaknesses in prevention may be offset by strengths in detection and response.

Regulators expect you to treat all network devices the same, and clearly preventive risk management controls are preferred, but the fact is that many of the same well-established tools and techniques that are used for servers, PC’s and laptops are either not available, or not as mature in the smartphone/iPad world.  Traditional tools such as patch management, anti-virus and remote access event log monitoring, and techniques such as multi-factor authentication and least permissions, are difficult if not impossible to apply to these devices.  However there are still preventive controls you can, and should, implement.

First of all, only deploy remote devices to approved users (as required by your remote access policy), and require connectivity via approved, secure connections (i.e. 3G/4G, SSL, secure WiFi, etc.).  Require both power-on and wake pass codes.  Require approval for all applications and utilize some form of patch management (manual or automated) for the operating system and the applications.  Encrypt all sensitive data in storage, and utilize anti-virus/ anti-spyware if available.

Because of the unavailability of preventive controls, maintaining your information security profile will likely rest on your compensating detective and corrective controls.  Controls are somewhat limited in these areas as well, but include maintaining an up-to-date device inventory, and having tracking and remote wipe capabilities to limit damage if a security breach does occur.

But there is one more very important preventive control you can use, and this one is widely available, mature, and highly effective…employee training.  Require your remote device users to undergo initial, and periodic, training on what your policies say they are (and aren’t) allowed to do with their devices.  You should still conduct testing of the remote wipe capability, and spot check for unencrypted data and unauthorized applications, but most of all train (and retrain) your employees.

22 Feb 2012

The single most important vendor management control

Pop quiz…according to the FFIEC Handbook on Outsourcing Technology Services

“The ________ is the single most important control in the outsourcing process”:

  1. Initial due diligence process
  2. Review of third-party audit reports
  3. Contract
  4. Risk Assessment
  5. Vendor’s financial stability

I’ve written before about the importance of the third-party review in the ongoing vendor management process (and how that changes with the phase-out of the SAS 70), and of course vendor financial stability can speak to the ability to continue to provide services.  And a vendor risk assessment has been an essential component of your Information Security Program since GLBA.  All of these are important, but according to the FFIEC;

“The contract is the legally binding document that defines all aspects of the servicing relationship. A written contract should be present in all servicing relationships.  This includes instances where the service provider is affiliated with the institution. When contracting with an affiliate, the institution should ensure the costs and quality of services provided are commensurate with those of a non-affiliated provider. The contract is the single most important control in the outsourcing process.

 I’ve already predicted that vendor management would become an area of increased regulator scrutiny in the coming year, and one of the first things they will be looking at are the contracts.  Actually, regulators asking to see vendor contracts is nothing new, but lately some have been examining these contracts for specific elements.  So here are the 18 elements that should be included (or at least considered) in all critical vendor contracts:

  • Scope of Service
  • Performance Standards
  • Security and Confidentiality
  • Controls
  • Audit
  • Reports
  • Business Resumption and Contingency Plans
  • Sub-contracting and Multiple Service Provider Relationships
  • Cost
  • Ownership and licensing
  • Duration
  • Dispute Resolution
  • Indemnification
  • Limitation of Liability
  • Termination
  • Assignment
  • Foreign-based
  • Regulatory Compliance

Not all contracts, even with critical vendors, will contain all of these elements.   But each of them represents an important factor for consideration as you negotiate (or re-negotiate), and your vendor risk assessment should ultimately determine exactly which elements you’ll require.

“The time and resources devoted to managing outsourcing relationships should be based on the risk the relationship presents to the institution. “

And unlike some risk assessments, where smaller financial institutions may have enjoyed less scrutiny because of their size and complexity…

“…smaller and less complex institutions may have less flexibility than larger institutions in negotiating for services that meet their specific needs and in monitoring their service providers.”

So smaller institutions may actually be in for a more rigorous vendor management review than larger institutions!

I’ve created a check-list of all contract considerations listed above, along with a brief description of each one.  I hope you’ll find it useful.  You can download it here.

06 Feb 2012

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?