Author: Tom Hinkel

As author of the Compliance Guru website, Hinkel shares easy to digest information security tidbits with financial institutions across the country. With almost twenty years’ experience, Hinkel’s areas of expertise spans the entire spectrum of information technology. He is also the VP of Compliance Services at Safe Systems, a community banking tech company, where he ensures that their services incorporate the appropriate financial industry regulations and best practices.
20 Sep 2012
Hot Topics Tom Hinkel 0 comment

New cyber attack targeting small to medium-sized financial institutions

The FBI, in association with the Financial Services Information Sharing and Analysis Center (FS-ISAC) and the Internet Crime Complaint Center (IC3), recently issued a fraud alert warning that criminals are using a multi-vector attack to compromise financial institution networks and initiate fraudulent wire transfers.  The first thing that struck me about this attack is that although all the recent focus has been on strengthening controls on the merchant side, this is targeted not at the merchant, but directly at the financial institution itself.

Simply put, the attack uses a combination of SPAM and phishing emails (#1 below), keystroke loggers, and remote access software (#2 below) to capture employee authentication credentials.  A successful attack results in the employee’s PC being under the control of the criminal, who will then use the employee’s authority to initiate wires, approve them, and even override built-in transaction limits. The following graphic describes how the attack occurs, with the exception that in #5 the victim is the financial institution, not the on-line banking customer:

(Click here for original document)

It is important to understand that this is not a “proof-of-concept” attack, this is actually occurring, and has resulted in attempted transfers ranging from $400,000 and $900,000.

One of the unique indicators of the attack is that either just prior to or just after the attack, the institution’s website is targeted by a denial of service attack which is designed to slow or deny access to the FI’s website, distracting institution employees and preventing or delaying them from detecting the fraudulent transactions.  They recommend that institutions monitor for spikes in website traffic that may indicate the beginning of the attack.

The alert also lists 17 best practice recommendations for financial institutions designed to prevent and detect this (and similar) attacks.  It is not surprising that the first 5 recommendations address the weakest link; the employee.  I previously identified the employee as the biggest single risk to information security, and employee training as a trend for 2012.  Many of the other recommendations should be familiar to most FI’s; restrict user access rights and login times, review Anti-malware and Anti-virus defenses, implement anomaly detection, and utilize IPS and “white-lists” to prevent connections to suspicious sites.  They also recommend that institutions strongly consider (their words, my emphasis) implementing out-of-band authentication for wire authorization.  This is where the final authentication approval is send back to the originator via a communication channel other than the one used to initiate the transaction.  This was also one of the recommendations from the FFIEC in their authentication supplement released last year.

In my opinion there are 2 controls financial institutions can implement now that will do more than any other to significantly reduce the incidence of fraudulent transactions.  The first is out-of-band authentication, and the other is utilizing a secure DNS service, similar to this.

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.”
© 2025 UFS Tech. All rights reserved. Compliance Guru is a registered trademark of UFS Tech. Privacy Policy