information security – Page 3

16 Feb 2012

From the Field Tom Hinkel 0 comment

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.)

28 Oct 2011

Hot Topics Tom Hinkel 0 comment

The “Security Breach” and your Incident Response Program

Last week Wells Fargo said that some of their customers in South Carolina and Florida received portions of other customers’ bank statements in the mail as the result of a printer error. Essentially a printer malfunction caused some printed statements to contain a portion of another customer’s statement to be appended to the bottom. A Wells Fargo spokesman said that “we’re treating this matter as an information security breach.” This got me thinking about what constitutes a “breach”, vs. what is an “event”, and what the regulators expect you should do about it in either case.

I usually associate a breach with an act perpetrated by an intelligent agent*, and in fact BusinessDictionary.com defines breach as “An act from outside an organization that bypasses or contravenes security policies, practices, or procedures.” Based on this definition the Wells Fargo incident was not technically a breach because it originated from within the organization. On the other hand, Wikipedia defines data breach as “…the intentional or unintentional release of secure information to an untrusted environment.” This seemingly would include both internal and external events, as well as intelligent as well as inanimate agents…cause and source don’t matter.

So what does the FFIEC have to say? They don’t specifically use the “breach” terminology when referring to an information security event, but in the Information Security Handbook they define a security event this way: “An event that compromises the confidentiality, integrity, availability, or accountability of an information system.” So cause and source aren’t material to the definition of event, and by this definition the printer malfunction did constitute a security event.

Whether you refer to it as a “breach”, and “event” or an “incident”, your incident response plan must guide your response. According to the FFIEC, your incident response program should contain, at a minimum, procedures for:

Assessing the nature and scope of an incident and identifying what customer information systems and types of customer information have been accessed or misused;
Notifying its primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information;
Consistent with the agencies’ Suspicious Activity Report (SAR) regulations, filing a timely SAR, and in situations involving federal criminal violations requiring immediate attention, such as when a reportable violation is ongoing, promptly notifying appropriate law enforcement authorities;
Taking appropriate steps to contain and control the incident to prevent further unauthorized access to or use of customer information; and
Notifying customers when warranted in a manner designed to ensure that a customer can reasonably be expected to receive it.

Whenever I see events like this in the news, I see an opportunity for financial institutions to use it as training. Conduct a table-top drill using the details of the actual event as your scenario. Dust off your incident response plan, and follow it to the letter. The objectives of the test should include such items as:

What defines an event? Under what specific circumstances is the plan activated?
Who is notified and when? Should an SAR be filed? If customers are required to be notified, how will they be notified? What will you say?
What was the root cause of the incident? What controls failed and why? Make sure you document and preserve as many of the details of the event as possible to facilitate the post-event investigation process.

Finally, update your program to address any gaps between what your plan says, and what you would actually do. Incorporate any additional controls indicated by the post-event analysis back into your information security program. And re-test as soon as possible to validate all changes.

*Although I suppose you could say that printers and copiers have become more “intelligent” in the sense that almost all of them contain some sort of microprocessor, and even storage, I think of an intelligent agent to mean human-based.

22 Aug 2011

Hot Topics Tom Hinkel 0 comment

Risk Assessing Internet Banking – Two Different Approaches

One of the big “must do” take-aways from the updated FFIEC Authentication Guidance was the requirement for all institutions to conduct risk assessments. Not just prior to implementing electronic banking services, but periodically throughout the relationship if certain factors change, such as:

changes in the internal and external threat environment, including those discussed in the Appendix to this Supplement;
changes in the customer base adopting electronic banking;
changes in the customer functionality offered through electronic banking;
and actual incidents of security breaches, identity theft, or fraud experienced by the institution or industry.

The guidance also mandated annual re-assessments if none of these previous factors change, but given the increasingly hostile on-line environment it’s really a question of ‘when’ actual incidents occur, not ‘if’. That being the case, if you only update your risk assessment annually the regulators could reasonably take the position that you’re not doing it often enough.

So risk assessments must occur “routinely”, but what is the best way to approach them? Although the guidance does not specify a particular approach, it might be instructive to take a look at what the FFIEC has to say about Information Security and Disaster Recovery, both of which require (separate) risk assessments. In both cases the FFIEC encourages that you approach the task by analyzing the probability and impact of the threat, not the nature of the threat. This makes perfect sense. By shifting the focus of your risk assessment off of the moving target of the constantly changing threat environment, and on to strengthening the overall security of your Internet-based services¹, you can build a secure transaction environment that will scale and evolve as you grow. Here is the critical difference between the two approaches; if you take a “nature-of-the-threat” approach, you must list every possible specific threat both existing and reasonably anticipated². It doesn’t work very well for disaster recovery or information security risk assessments, and in my opinion it is not the best approach for Internet banking either.

Although certainly not the only way to do the risk assessment, I would recommend a 2-step approach that addresses most if not all of the updated FFIEC guidelines. Step 1 of this approach is to assess the overall risk of your products by listing the capabilities and controls for each one. As a part of that step you would determine how many customers use the product, and then also how many of those you consider to be “high-risk” as defined by high transaction frequency and high dollar amount. In Step 2 you should list those high-risk customers you identified in step 1 separately, along with the associated controls you plan to implement for each one.

Again, there is no one single way to do this correctly. Whatever you do should be consistent with the size and complexity of your institution, and the nature and scope of your Internet banking operations. Good luck!

¹ Although other regulations and guidelines address financial institutions’ responsibilities to protect customer information and prevent identity theft, this guidance specifically addresses Internet authentication, and should be the primary focus of this risk assessment.

² You must still re-assess if either you or the industry experience any actual incidents, but instead of adding a new threat to your risk assessment, you simply determine if your existing control environment is sufficient to address the impact of the threat. In other words, you re-assess for the impact, not the nature of the threat.

27 Jun 2011

From the Field Tom Hinkel 0 comment

Audits vs. Examinations

As I speak with those in financial institutions responsible for responding to audit and examination requests, I find that there is considerable confusion over the differences between the two. And some of this confusion is understandable…there is certainly some overlap between them, but there are also considerable differences in the nature and scope of each one. It may sometimes seem as if you are asked to comply with 2 completely different standards. How often has the auditor had findings that you’ve never been asked during an examination? And how often has an examiner thrown you a curve ball seemingly out of left field?

In a perfect world shouldn’t the audit be nothing more than preparation for the examination? The scope of the audit should be no more and no less than what you need to get past the examination. Any more and you feel as though you’ve wasted resources (time and money), any less and you haven’t gotten your money’s worth, right? Well…actually no. While the two have the same broad goal of assessing alignment with a set of standards, the audit will often use a broader set of industry standards and best practices. This is because the FFIEC guidance is so general and non-prescriptive. For example, take one of the questions in the FDIC Information Technology Officer’s Pre-Examination Questionnaire.

“Do you have a written information security program designed to manage and control risk (Y/N)?”

Of course the correct answer is “Y”, but since the FDIC doesn’t provide an information security program template, how do you know that your program will be acceptable to the regulators? You know because your IT auditor has examined your InfoSec program, and compared what you have done to existing IT best practices and standards, such as COBIT, ITIL, ISO 27001, SAS 94, NIST, and perhaps others. While this doesn’t guarantee that your institution won’t have examination findings, it will reduce the probability, as well as the severity, of them. This point is critical to understanding the differences between and audit and an examination; an audit will identify and allow you to correct the root cause of potential examination findings prior to the examination. So using the example above, even if the examiner has findings related to your information security program, they will be related to how you addressed the root cause, not if you addressed it. (I’m defining root cause as anything found in the Examination Procedures.) In fact, the FFIEC recognizes the dynamic between the IT audit and examination process this way:

An effective IT audit function may also reduce the time examiners spend reviewing areas of the institution during examinations.

And reduced time (usually) equals fewer curve balls, and a less stressful examination experience!

09 Feb 2011

Hot Topics Tom Hinkel 0 comment

Top 5 Compliance Trends for 2011 – Part 5

As I write this, the only case to go to trial of a Bank suing the Merchant over account takeover losses is awaiting the jury’s decision. The result may redefine the liability, and by definition the roles and responsibilities, of both the financial institution and the merchant when it comes to securing electronic transactions. It may also finally determine what is considered “commercially reasonable” security, or (I hope) even toss out the use of this murky term altogether. I believe there is a perfect storm brewing over this issue, with several factors converging simultaneously to produce my final compliance trend for 2011:

Corporate Account Security (merchant capture, remote ACH and remote wire transfer).

Here are all the converging elements and their implications:

The aforementioned lawsuit between EMI and Comerica- The trial just ended on 1/26 and it’s now in the hands of the jury. We’ll see how this plays out, but it will have implications either way particularly if (as I suspect) the merchant prevails.
The upcoming FFIEC update to authentication guidance – We are expecting final guidance on this from the FFIEC any day, but whatever the final requirements, increased scrutiny of authentication mechanisms will be the result. New guidance always results in increased regulator focus, even if it is only an update to existing guidance. Additionally, I suspect that the update won’t go far enough to address preventive measures.
The tendency for affected institutions to under report incidents – Because of the potential for reputation risk, financial institutions are reluctant to report account takeover incidents. That is the primary reason that most institutions choose to settle with customers rather than take the case to court (there have been only 2 cases brought to court so far). In the meantime, we know that online crime complaints have increased substantially each year since 2005, resulting in losses of hundreds of millions of dollars.
A fundamental misunderstanding by both merchants and financial institutions of their respective responsibilities – BankInfoSecurity.com recently interviewed a bank CEO affected by an account takeover incident. In the interview, he reveals that he believes that remote transactions should carry a lower degree of perceived protection than transactions carried out inside the Bank’s security perimeter. He also expected the third-party vendor that provided the remote ACH software to have done more to keep the bank secure. In the meantime, merchants expect the transactions they initiate remotely to be just as secure as those initiated inside the physical confines of the bank.

Here is how this trend differs from the others...regardless of whether or not regulators increase focus on this issue in 2011, I believe institutions absolutely must. The guidance is behind the curve on this issue, and institutions simply have too much to lose. It is clear that the minimum requirement is not sufficient, you must go further. Implement additional preventive controls at the merchant side, and educate everyone on basic security best practices.

11 Nov 2010

From the Field Tom Hinkel 0 comment

Dodd-Frank and regulatory compliance

In an excellent article by Lori Moore of ATTUS Technologies, she states that there are multiple reasons why bank examiners may be ramping up scrutiny:

“Examiners who may already be on the defensive in regard to criticism about their actions prior to the fall 2008. Examiners who now have the Dodd-Frank Act on their side, giving them more authority. Examiners who in conjunction with Dodd-Frank have been charged with heightening their scrutiny of all consumer protection compliance.

No doubt, examiners are going to get tough. A decree recently stated by a representative from the OCC: “Fair but tough”. In fact many anecdotal reports confirm this is already happening.”

The difference between “tough but fair”, and “fair but tough” is much more than semantic. It means that “tough” is the operative word. As the pendulum of regulatory focus swings from credit risk back to regulatory risk, expect regulators (and auditors) to spend more time scrutinizing your information security policies, procedures and practices.

← Previous 1 23