04 Apr 2011

From the Field Tom Hinkel 8 Comments

The Control Self-Assessment (CSA)

If there was a process that was mentioned 43 times in 7 of the 12 FFIEC IT Examination Handbooks, (including 12 times in the Information Security Handbook alone!), would you consider implementing it? How about if it virtually assured better audits and examinations? OK, you’re interested, but the last thing you need is to implement another complicated process, right? What if the framework is probably already in place at your institution, and all you need to do is fine-tune it a bit?

I’m referring to the Control Self-Assessment (CSA), and let’s first make the regulatory case for it. The FFIEC Operations Handbook says:

Periodic control self-assessments allow management to gauge performance, as well as the criticality of systems and emerging risks.

And…

Senior management should require periodic self-assessments to provide an ongoing assessment of policy adequacy and compliance and ensure prompt corrective action of significant deficiencies.

If you’re familiar with “FFIEC-speak”, then you know that “should” really translates to “must”. But the Information Security Handbook makes the most compelling argument for utilizing the CSA in your risk management program:

Control self-assessments validate the adequacy and effectiveness of the control environment. They also facilitate early identification of emerging or changing risks.

So there is plenty of regulatory support for the CSA process, what about the audit and exam benefits? All of the major auditing standards bodies (IIA, AICPA, ISACA) address the importance of internal control reviews. Indeed most auditors say that institutions with an internal CSA process in place generally demonstrate a much more evolved risk management process, resulting in fewer, and less severe, audit findings. This stands to reason, as they tend to identify, and correct, control weaknesses prior to audit, as opposed to waiting for the auditor to identify them. And since one of the first things the examiner wants to see when they come in is your most recent audit, this often results in fewer examination findings as well.

One more reason to implement a CSA process from the examination perspective is something I touched on here…for those institutions trying to maximize their CAMELS IT composite ratings, one of the biggest differentiators between a “1” and a “2” is that in institutions rated a “1” “…management identifies weaknesses promptly (i.e. internally) and takes appropriate corrective action to resolve audit and regulatory concerns”. Conversely, in those institutions rated a “2” “…greater reliance is placed on audit and regulatory intervention to identify and resolve concerns”. A CAMELS “3” rating speaks directly to the CSA, stating that “…self-assessment practices are weak…“.

OK, so there are certainly lots of very good reasons to implement a CSA process in your institution. How can this be done with minimal disruption and the least amount of resource overhead? Chances are you already have a Tech Steering Committee, right? If the committee consists of members representative of all functional units within the organization, it has the support of senior management, and is empowered to report on all risk management controls, all that’s needed is a standardized agenda to follow. The agenda should address the following concerns:

Identification of risks and exposures
Assessment of the controls in place to reduce risks to acceptable levels
Analysis of the gap between how well the controls are working, and how well management expects them to work

As you can see, this is not substantially different from what you are probably already doing in your current Tech Steering Committee meetings. In fact, this list is really only a sub-set of your larger agenda…the only possible difference is that any and all findings in the gap analysis must be assigned to a responsible party for remediation.

In summary; the FFIEC strongly encourages it, the auditors and examiners love it, and for most institutions it’s not too difficult to implement and administer. But if you only need one good reason to consider the CSA process, it should be this:

Improved audit and examination ratings!

27 Mar 2011

Hot Topics Tom Hinkel 0 comment

The RSA breach, and 5 things you should do

For those of us already waiting for the latest update on guidance from the FFIEC on Internet Authentication, the news of the recent RSA SecurID breach complicates things a bit. One-time password (OTP) hardware devices (tokens and smartcards) are considered one of the most secure forms of the “something you have” element in complying with the multifactor authentication requirement. So let’s take a look at the RSA breach in the context of authentication guidance, and what you should do to respond.

When the FFIEC released its original guidance on Internet Authentication in 2005, they said this about tokens:

Password-generating tokens are secure because of the time-sensitive, synchronized nature of the authentication. The randomness, unpredictability, and uniqueness of the OTPs substantially increase the difficulty of a cyber thief capturing and using OTPs gained from keyboard logging.

And 6 years later, in the draft release of the FFIEC updated guidance, they said:

“OTP tokens have been used for several years and have been considered to be one of the stronger authentication technologies in use.”

And they are correct; in the last few years OTP tokens for authentication have proven to be very secure and have become very popular, and arguably the biggest player in that market is RSA. There are millions of RSA SecurID tokens in use today, many of them in financial institutions, and many of those authenticating Internet based financial transactions…perhaps for your customers.

So what exactly happened? Well, their Website is (strangely) completely silent on the event, and RSA customers I’ve spoken to say that information is slow coming to them, and extremely vague when it does, but according to what has been disclosed by the RSA, here is what we do know:

“…the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.”

So…according to the FFIEC, the security of the OTP is based on “randomness, unpredictability, and uniqueness”, but we don’t know if the “certain information” mentioned by the RSA included the main algorithm or some other critical information necessary to generate the OTP.

As a financial institution responsible (and liable) for the security of your customers’ Internet based transactions, you must err on the side of caution here if you utilize RSA tokens. I’ve got to believe that RSA will do the right thing here, and place their customer’s security ahead of their own business interests, but in the meantime it may be prudent to consider some additional measures, such as:

Since multi-factor authentication relies on “something you know” in addition to “something you have”, encourage (require?) your customers to change their user names and passwords.
Review (and possibly temporarily adjust) your built-in transaction monitoring metrics, such as dollar volumes, transaction frequency, ACH / Wire recipient lists, etc.
Implement “Out-of-Band” confirmation for all high-risk transactions. In other words, temporarily require all transactions to be confirmed via a return phone call, fax, SMS, or similar method.
Make sure your customers know exactly who they can contact if they suspect unauthorized activity, and most importantly, let them know under what circumstances (and what methods) you will contact them.
Finally, consider an alternate token vendor. You may be at the mercy of your on-line banking software vendor on this, but there are 2 trust issues in jeopardy here…the one between you (or your vendor) and the RSA, and the much more important one between you and your customer. RSA may be able to fix whatever problems allowed the breach, and thereby repair the trust (or not) with their customers (your vendor), but the trust issue with your customers may not be repairable. Rightly or not, they may be reluctant to use anything with “RSA” printed on it.

All of these items (except the last) are best practices anyway, but the key is that you must be pro-active on this. Do not wait for RSA to release all the details (we may never know them anyway), because what we do know now is enough to justify additional security measures.

In conclusion, tokens and OTPs are still very effective as one element in one layer of a multi-layer, multi-factor, authentication process, but clearly the lesson here is that there is no fool-proof method. Indeed as we await the FFIEC update, this line from the draft release is almost prophetic:

“Since virtually every authentication technique can be compromised, financial institutions should not rely on any one authentication method or security technique in authorizing high risk transactions, but rather institute a system of layered security.”

Perhaps the only change necessary to that statement in the final release is to remove the word “virtually”.

22 Feb 2011

Hot Topics Tom Hinkel 1 Comment

AICPA finalizes SAS 70 replacement

I wrote about this here as well, but it’s now official: The AICPA has clarified the SAS 70 replacement reports. They are actually officially being referred to as “Service Organization Control Reports (formerly SAS 70 reports)”.

The new SOC reports provide a framework for auditors to examine controls and to help senior management understand the related risks of outsourcing to a service provider.

According to the AICPA:

“Companies had misused SAS 70 to issue reports on controls related to outsourced non-financial data rather than the correct attest standard which was in place. The SOC reports clarify which standard needs to be used and how it should be implemented to meet specific user needs.

SOC 1 reports are primarily an auditor-to-auditor communication which addresses the controls at a service organization relevant to financial reporting. These reports are restricted use reports and therefore are not designed for promotional purposes. – (This is the functional replacement for the SAS 70 only where financial controls are concerned.)
SOC 2 reports are in response to the rapid growth in cloud computing and data outsourcing, as well as the marketplace need for clarification on how reports on non-financial controls regarding information, such as data security, confidentiality and privacy should be structured. – (This will likely be the SAS 70 replacement for the vast majority of service organizations)
SOC 3 reports cover the same subject matter as SOC 2, but in a general use, short form format which may be freely distributed.”

Get used to seeing this logo instead of the myriad of SAS 70 logos:

SOC Reports

Most importantly, know what it is…and what it isn’t. Understand why your vendor chose one report over another, and determine if the report is relevant to you, and adequately addresses your concerns. The term “SAS 70” is mentioned 31 times in 8 of the 12 IT Examination Handbooks, so it is a critical element in how the FFIEC expects you to manage your vendor relationships. No word yet on how the FFIEC will address this going forward…

22 Feb 2011

From the Field Tom Hinkel 1 Comment

Management of IT reflects overall management

(This is an extract from an article written for Bank Technology News. The full article is here.)

One of the reasons compelling the shift towards increased focus on IT is found in the only non-financial element in the CAMELS ratings: management. Post-mortem reports on the failures of both Washington Mutual and Indy Mac placed the blame equally on management for pursuing overly aggressive growth strategies, as well as on the regulator (OTS) and their inability to effectively identify and assess the risks. The OTS was a regulatory casualty of Dodd-Frank, and I think we can expect (and rightly so) increased focus on all governance issues going forward. But how does that translate into increased IT focus?

There are twelve factors that go into the CAMELS management rating component, and one of them is a measure of how well the institution manages its information systems. In addition to that, the FFIEC makes it clear in their IT Examination Handbook on Management that

“…effective IT management practices play an integral role in achieving many goals related to corporate governance. The ability to manage technology effectively in isolation no longer exists. Institutions should integrate IT management into the strategic planning function of each line of business within the institution.”

And regarding the relationship between IT and strategic planning;

“…an institution capable of aligning its IT infrastructure to support its business strategy adds value to its organization and positions itself for sustained success.”

Clearly IT is so pervasive throughout financial institutions that no enterprise-wide assessment of management and governance is complete without a thorough review of IT. It also stands to reason that an institution that can not demonstrate that they can adequately manage technology (and do so at all levels of management, from the Board of Directors down) may have fundamental management issues enterprise-wide.

Bottom line…more scrutiny of management equals more scrutiny of IT, and deficiencies in IT can lead to lower CAMELS scores. Solution? Implement a formal IT management process consisting of a dedicated committee. Use a standardized agenda, assigning follow-up items to responsible parties with specific time-frames for resolution. Involve ALL functional units in the committee, and regularly report status updates to the Board.

Then take this same model and apply it to the rest of the organization!

01 Feb 2011

Hot Topics Tom Hinkel 1 Comment

Top 5 Compliance Trends for 2011 – Part 4

According to the FFIEC IT Examination Management Handbook, many institutions choose to delegate responsibility for monitoring IT activities to an IT Steering Committee. I also addressed this here. One of the most important roles of the IT Steering Committee is to ensure that the IT strategy is aligned with the overall business strategy. And the best way to do that brings me to my next trend:

The IT Strategic Plan

Although the FFIEC Management Handbook came out in June 2004, we first saw this appear in FDIC examinations in 2009. Since then it sort of faded away, but now it’s back, and at least one other primary federal regulator is asking for it…the OTS. (Whether or not this makes the transition to the OCC remains to be seen.)

According to the FFIEC:

Strategic IT planning focuses on a three to five year horizon and helps ensure the institution’s technology plans are consistent or aligned with its business plans. If effective, strategic IT planning can ensure delivery of IT services that balance cost and efficiency while enabling the business units to meet the competitive demands of the marketplace.

Since IT is often the largest single investment (not to mention the largest concentration of risks) a financial institution has, regulators recognize that managing this process is vitally important. The IT Strategic Plan can demonstrate that you are managing effectively.

There is no one single template for this, but in general the plan should contain the following elements:

A mission statement. This should establish the basis for the plan, and the broad goals and objectives.
Coordination with the overall Strategic Plan
Organizational structure
Agenda
A list of IT initiatives

Many institutions choose to manage the plan in their IT Steering Committee…it simply become another agenda item. As the FFIEC states:

The information technology steering committee’s cross-functional membership makes it well suited for balancing or aligning the organization’s IT investment with its strategic and operational objectives.

However you choose to do it, since the IT Strategic Plan is so critical operationally, you may not want to wait until the examiners ask for it (and they will). And if you need to get senior management buy-in, mention this:

Well implemented technology plans provide the capability to deliver business value in terms of market share, earnings, and capital growth to the organization.

14 Jan 2011

Hot Topics Tom Hinkel 4 Comments

FFIEC to issue updated authentication guidance?

I’ve been hearing this rumor for a while now, but we may actually be seeing something new from the FFIEC soon. Gartner is the latest to suggest that an update to the 2005 guidance on authentication is imminent.

In addition to updating it for technological advances since 2005, (Facebook and LinkedIn were in their infancy, and Twitter hadn’t even been launched), I hope it also addresses the increasing responsibility held by the customer, (both commercial and consumer) for data security. I continue to believe that there should be shared responsibility, and liability, for establishing and maintaining a secure electronic banking environment.

Reg. E protects the consumer, and so far the courts have held overwhelmingly in favor of the commercial customer as well. Will regulators extend Reg. E to commercial accounts, or place more responsibility on the customer? Could the new guidance further define “commercially reasonable”?

My guess is that we may not see much clarification on these issues, but we are likely to see additional burdens placed on the financial institution. For example, don’t be surprised to see customer education become more prescriptive, with the financial institution being responsible for it.

Stay tuned!

← Previous 1…91011…15 Next →