Category: From the Field

16 Feb 2012

FDIC changing annual IT report to Board?

Based on recent examination findings, it would appear that the FDIC is changing what they expect to see in the annual information security report to the Board of Directors.  The requirement for the report is established in the FFIEC Information Security Handbook where it states that a written report to the board should describe the overall status of the information security program, and that at a minimum, the report should address:

  • The results of the risk assessment process
  • Risk management and control decisions
  • Service provider arrangements
  • Results of security monitoring and testing
  • Security breaches or violations, and management’s responses
  • Recommendations for changes to the information security program

However in a recent examination the institution was written up because the FDIC did not believe the report contained enough detail.  They stated that “Board reporting should be expanded and include detail at a minimum for the following areas:

  • The information security risk assessment
  • Service provider agreements
  • Results of testing, audits, examinations or other reviews of the program
  • Any security breaches, violations, or other incidents since the previous report and management responses
  • A summary of information security training provided to employees since the last report
  • Status of the patch management program
  • Status of the Business Continuity Plan and testing results
  • Customer Awareness Program efforts and plans
  • Any recommendations for changes to the information security program”

I’ve highlighted the changes between the original guidance and the examination finding.  I’m not surprised at the training findings, as I have previously identified both employee and customer training as likely 2012 trends.  Nor am I particularly surprised by the inclusion of the status of the BCP and testing results.  This has been a requirement and an area of increased regulatory focus for a couple of years.  However it would appear that examiners may now prefer the BCP status update to be a part of the information security update report to the Board.

The inclusion of a patch management status report was a bit surprising though, as in the past this was not reported separately but simply included as one of your many risk management controls.  Perhaps they are looking for more control detail now?  (I plan to address patch management in a future post.)

I was also a bit baffled by the exclusion of “Risk management and control decisions” from the list of findings.  I had also identified the “Management” element as a probable area of increased regulatory scrutiny in 2012, so I’ll keep an eye on future examination findings to see if this actually represents a shift in focus or simply an oversight by the examiners this time.  (Of course a third possibility is that the examiner felt that the “risk management and control decisions” were present and properly documented, but given the other findings I doubt that was the case.)

25 Jan 2012

Bank Directors and Officers targeted in 2011

The final numbers are in for 2011, and it was a record year for Director and Officer (D&O) lawsuits by the FDIC.  In 2011 alone, 264 defendants were named in FDIC lawsuits.  To put that in perspective, that’s more than twice the number sued in the previous 2 years combined.  Some of the most frequently repeated charges were:

  • “Negligence”
  • “Simple negligence”
  • “Gross negligence”
  • “Engaged in corporate waste”
  • “Recklessness and willful misconduct”
  • “Breach of fiduciary duty” (more…)
09 Jan 2012

Another incident management table-top training exercise

I’ve mentioned before that financial institutions would be wise to use news reports of security incidents as “what if” table-top training exercises.  Here is another one that just occurred a couple of days ago:

Test scenario:

  • You receive a subpoena from a government agency requesting financial information on several customers.  The subpoena includes names and social security numbers for the customers involved.
    • (Your privacy policy probably contains verbiage similar to this:  “Social Security numbers may only be accessed by and disclosed to <bank employees> and others with a legitimate business “need to know” in accordance with applicable laws and regulations”, or perhaps you state that you will disclose only if “…responding to court orders and legal investigations”.)
  • You determine that information disclosure is necessary and appropriate in this case, and you provide the information.
  •  Although there is nothing in your privacy policy that requires it, you then decide that you will notify the affected customers that their information was disclosed pursuant to a legal request.
  • You send a letter to each affected customer explaining the reasons for the disclosure, as well as what information was disclosed.
  • You include a copy of the original subpoena in the letter to the affected customers in it’s original form, including the names and social security numbers of all of the affected customers.  In other words, you did not redact information pertaining to everyone other than the intended recipient of the letter, all affected customers received everyone else’s information in addition to their own.

Discussion topics:

  1. Does this qualify as  a “security incident” as it is defined by your Incident Response Plan?  It is clearly not an intrusion, but it does qualify as an irregular or adverse event which negatively impact the confidentiality of customer non-public information.
  2. Is customer or regulator notification required?  In order to answer this question, answer the following:  “Has misuse of non-public information occurred, or is it reasonably possible that misuse could occur?”  If the answer is “yes”, customer and regulator notification is required, as well as credit monitoring services, ID theft insurance, credit freeze activation, and any other remedies the law, and your policies, require.
  3. Is a Suspicious Activity Report filing required?  (Perhaps not, but I would err on the side of caution.)
  4. What, if anything, would we do differently?  Under what exact circumstances will we disclose customer NPI?  If disclosed, will we notify the affected customer?  What are the legal implications?

Use these real world examples to fine tune your incident management policies and procedures.  Perhaps they will prevent you from becoming someone else’s training exercise!

22 Dec 2011

FDIC offers “Insight” on Mobile Banking

Although not considered official supervisory guidance, the most recent FDIC Supervisory Insights newsletter offers an instructive early look into how the agency might examine this emerging electronic banking delivery method in the future.  (Before you tune out and decide to wait for the formal guidance, remember it was the Winter 2009 issue that first introduced us to the concept of the Enterprise-wide risk assessment as the preferred replacement for the traditional information security risk assessment.  I consider these Supervisory Insight newsletters to be a pretty accurate peek into the regulatory crystal ball.)

The article is titled “Mobile Banking: Rewards and Risks”, and is a fairly deep dive into this relatively new banking service.  Mobile banking is defined as the use of a mobile device, commonly a cell phone or tablet computer, to conduct banking activities.   The article starts by discussing the current, and estimated future, market for this service, quoting a survey placing the potential adoption of mobile banking at 38 million households by 2015.  Clearly, if institutions have not already considered adopting this delivery method, they certainly will in the near future.  They separate the mobile service offerings into 3 broad categories based on the delivery method:

  • Text messaging/short message service (SMS)
  • Mobile-enabled Internet browser
  • Mobile applications (apps)

They then discuss the channel-specific mobile banking risks, and this was one of the most interesting parts of the article for me:

A recent study looked at the security of four types of mobile applications – financial services, social networking, productivity, and retail.  The study focused on the types of sensitive data that mobile applications store on the device and whether these data were stored securely. Each application was rated “Pass,” “Warn,” or “Fail.” A “Pass” rating means sensitive data are not stored on the device or are encrypted.  A “Warning” rating means certain data are stored on the device, but this does not put the user at significant risk of fraud. A “Fail” rating indicates sensitive data, such as account numbers and passwords, are stored on the device in clear text, placing the user at an increased risk of identity theft or other financial fraud.

As you can see, although financial institutions had the highest “pass” rate for mobile applications, they also had uncomfortably high “warn” and “fail” rates.  (Also note the extremely high “fail” rates for social networking apps…this only confirms my concerns.)  Although they don’t go into great detail on the availability and proper use of controls to mitigate the risks, they do make the point that proper vendor management is key.  This is particularly true for community institutions who rely heavily, and almost exclusively, on the built-in controls provided by their product’s vendor.

But they also refer to the updated FFIEC Authentication guidance, stating that it “applies to mobile banking“.  This is a bit of a news flash, as the term “mobile banking” is not specifically mentioned anywhere in the updated guidance.  In fact this was one of the major criticisms of the update when it was released (although I disagreed).  I think it’s clear now that the FFIEC intended for the updated guidance to be broad enough include new and emerging technology, and that we shouldn’t expect a new update every time technology changes.  This also means that you should include mobile capabilities in your Electronic Banking risk assessment, as well as the associated controls.

So consider this an early Christmas present from the FDIC, and make sure to incorporate the mobile banking risk management concepts discussed in this article into your electronic banking risk assessment.  In summary:

Financial institutions are challenged to ensure their mobile banking service is designed and offered in a secure manner, and customers are made aware of steps they can take to protect the integrity of their mobile banking transactions.  (Edit – so does making customers aware mean mobile banking customer training will be a requirement?)

22 Nov 2011

Thankful for…Dodd-Frank?

I made a similar post last year about this time, so I thought I would continue the “Thanks-giving” tradition here…and no, I haven’t completely lost my mind about Dodd-Frank.  Let me explain.  Over the past year I’ve had the opportunity to give several presentations to various groups on the impact of Dodd-Frank (DFA) on community financial institutions, and I know the attitude out there on DFA ranges from cautious optimism to dread, but “Thankful”?!?  Actually so far, overall, the impact had been negligible to slightly positive for community financial institutions (defined as <$1B in assets).  But there is also reason for caution.

Reasons to be thankful

First and foremost among these are lower assessment rates.  Lower deposit insurance assessments mean that the vast majority of community banks will see 30% – 40% decreases in their fees paid to the FDIC.  And at the same time the amount of deposit insurance coverage has increased to $250,000.  Getting more for less is always a good thing.

Although we can’t really credit this to Dodd-Frank, we can nevertheless also be thankful that financial institutions are for the most part healthier than they were last year at this time:

 

Another reason to be thankful is that the provision limiting debit card interchange fees does not apply to institutions with less than $10B in assets.  In fact the vast majority of DFA provisions will only apply to institutions larger than $1B in assets, which as of June 2011 is only 8.9% of all financial institutions:

 

Reasons to be cautious

But as I said, there are still reasons to be cautious.  According to DavisPolk in their latest Dodd-Frank Progress Report, 326 of the 400 rules required by the law have not yet been enacted, which, (regardless of whether or not community institutions will ultimately be affected)  still leads to a climate of regulatory uncertainty. And there are  couple of other more obscure provisions that will affect all institutions, like the Source of Financial Strength provision, and the requirement for risk committees to have outside directors, and of course whatever burdens the CFPB brings…stay tuned!

I mentioned previously that one of the reasons that I’m NOT thankful for DFA is that it raises the threshold for triggering a Material Loss Review from $25M to $200M, so we’ll have fewer post-failure reports to review.  I believe the best way to avoid repeating the mistakes of the past is to learn from them, and the MLR’s were a great way to do that.  I think they can also predict future examination trends…which is a preview of my next 2012 Trends post!

 

(I’d be remiss if I didn’t take this opportunity to express thanks for all the blog readers out there…over 11,000 visits since this time last year!  THANK YOU!!)

08 Nov 2011

Access Rights a frequent finding

In reviewing recent audit and examination findings, the issue of access rights and permissions is coming up with increasing regularity.  Making sure that end-users have no more access rights than absolutely necessary to do their job is one of the best information security controls.  According to the FFIEC, formal access rights administration for users consists of four processes:

  •   An enrollment process to add new users to the system;
  •   An authorization process to add, delete, or modify authorized user access to operating systems, applications, directories, files, and specific types of information;
  •   An authentication process to identify the user during subsequent activities; and
  •   A monitoring process to oversee and manage the access rights granted to each user on the system.

One best practice for simplifying the management of access rights is to assign them via  group membership based on the employee’s role.  Most financial institution employees are easily categorized by job duties (lending, deposit ops, senior management, IT, etc.).  Job duties logically translate to responsibilities, and network file and folder access flows from that.  When an employees job duties change, changing group membership is much easier than changing individual file and folder permissions.

One of the main reasons for audit and exam findings in this area is not necessarily that users and groups aren’t maintained, but that there is a  disconnect between access rights on the Core system and the local network (Active Directory).  Unfortunately until the Core providers implement Active Directory integration this is a manual, 2-step process.

The key to addressing the FFIEC guidance (and preventing rights gaps in the process) is to manage all four of the above steps at the same time in the IT Steering Committee (or functional equivalent).  Each time the committee meets it should approve all access rights adds, changes and deletes, and review activity logs.  Periodically review the existing users (by group if possible) to validate the appropriateness of their (and the groups) access rights on a schedule commensurate with the risk.  Properly restricted regular users may only require semi-annual reviews, but privileged access (administrative) accounts should be reviewed for activity and re-approved at each committee meeting.