FDIC Information Technology Officer’s Questionnaire

08 Apr 2011

From the Field Tom Hinkel 0 comment

“Concentration of duties”

It is not unusual for a community financial institution with limited personnel to have the Information Security Officer (ISO) act as a backup network administrator. In fact, this is a relatively common practice in an environment where key personnel will typically wear several hats. And there are practical reasons for this; the ISO is typically tech-savvy, and can act as an expedient resource when needed. Often when admin (or privileged) access is required, it is for a business critical purpose.

However, we have received several post-exam reports recently that examiners are taking a closer look at this practice. The finding is called “concentration of duties” (or sometimes “separation of duties”), and it addresses the very legitimate concern that the ISO must act in an oversight capacity to the network administrator, and that oversight dynamic is lost if the ISO has administrative capabilities. In fact in their Information Technology Officer’s Questionnaire, the FDIC requires you to “…briefly describe any known conflicts or concentrations of duties” . This oversight dynamic is exactly what they are referring to.*

If your institution engages in this multiple-hat practice, there are several things you can do to address this with the regulators. The first is to transfer the administrative oversight responsibilities from the ISO to a committee, typically the audit or tech steering committee. This requires more frequent meetings (preferably monthly, but no less than quarterly), and a strict adherence to an agenda that always includes discussion (and documentation) of rights and permission changes whether or not there were any. You may also want to consider event log monitoring software that can collect and aggregate all administrative user activity, and preferably store it on a logically separate system.

It’s also a good idea to have the committee review and re-approve all privileged accounts at each meeting. Another best practice is to make sure the ISO has a user account for administrative activities separate from their everyday user account. This assures that all activity is properly captured and reported. Finally, never share log in credentials…particularly admin accounts.

Also, review the section on privileged user access from the FFIEC IT Examination Handbook, Information Security Booklet, Page 23:

Authorization for privileged access should be tightly controlled. Privileged access refers to the ability to override system or application controls. Good practices for controlling privileged access include

Identifying each privilege associated with each system component,
Implementing a process to allocate privileges and allocating those privileges either on a need-to-use or an event-by-event basis,
Documenting the granting and administrative limits on privileges,
Finding alternate ways of achieving the business objectives,
Assigning privileges to a unique user ID apart from the one used for normal business use,
Logging and auditing the use of privileged access,
Reviewing privileged access rights at appropriate intervals and regularly reviewing privilege access allocations, and
Prohibiting shared privileged access by multiple users.

Incorporate these best practices into your access rights administration process. In the end, what’s expected is that you understand the risk of “concentration of duties”, and balance that against your business needs, given your size and complexity and the nature and scope of your operations. If you understand the residual risk, and believe your business needs are best met by sharing admin duties with your ISO, make sure your examiner knows how you got to that decision, and how you plan to manage it going forward.

*Note – Although you may be tempted to answer “No” to this question in order to avoid drawing attention to it, you are much better off responding “Yes”, and then describing your risk assessment process and resulting controls. It may not prevent the finding, but you will have a proactive response to it, which almost always implies more effective risk management.

04 Jan 2011

Hot Topics Tom Hinkel 0 comment

The Pendulum Swings in 2011?

I’ll be posting my list of audit and examination trends for 2011 soon, but this article by me on a similar topic was just published in Bank Technology News.

16 Dec 2010

From the Field Tom Hinkel 4 Comments

The IT Steering Committee – Should or Must?

At a recent user group meeting of one of the major core vendors for community banks, I asked the question ‘how many of you use an IT or Tech Steering Committee?’. I was expecting a vast majority of hands to go up, but only about half did. This was surprising to me, given that:

The FFIEC all but mandates this committee,
The FDIC strongly encourages it,
Auditors recommend it, and
It provides a mechanism to address many of the most difficult examination questions

First, the FFIEC mandate. On page 5 of the Management Handbook, it states:

Many boards of directors choose to delegate the responsibility for monitoring IT activities to a senior management committee or IT steering committee…The committee should consist of representatives from senior management, the IT department, and major end-user departments.

Some institutions may call it a Tech Steering Committee, or have another name for it, but in “FFIEC-speak”, if “many” choose to do this, you better have a pretty good reason if you decide not to do it. In fact in Objectives 3, 4 and 5 of the Examination Procedures, the examiner is instructed to review;

…the membership list of board, IT steering, or relevant management
committees established to review IT related matters.
…the minutes of the board of directors and relevant committee meetings
…IT oversight program, to determine if the Board…established a steering committee, and
…the effectiveness of the reports used by senior management or
relevant management committees.

The FDIC strongly encourages the use of an IT management committee in their IT Officers Questionnaire. Part 1 (b) asks for “the names and titles of individuals, committees, departments or others participating in the risk assessment process”. And as I addressed in my series of the trickiest questions on the questionnaire, this committee, and the documentation it produces, can help you document adherence with many aspects of your IT risk management process.

Finally, most of the recent findings in IT audits are due to institutions’ inability to document that they are following their own policies. The policies themselves are sufficient, and the institution may indeed be complying with them, but because of non-existent or inadequate documentation they can’t prove that they are. And in today’s compliance environment, if you can’t prove you’re doing it, you aren’t doing it.

Given it’s overall importance, consider the IT Steering Committee a “must”. If you don’t have one, make a New Years resolution to establish one. Give it a mission to assist the board in overseeing IT-related activities. Make sure it consists of members from all departments, and work from a standardized meeting agenda. Lastly, document each and every meeting, and periodically report to the Board. Better audits and examinations in 2011 will be the fruits of your labor.

07 Oct 2010

From the Field Tom Hinkel 1 Comment

The 5 trickiest FDIC IT examination questions (part 5).

In my last post, I asked you to weigh in on what question you wanted me to address in this final post of the series. This one came from a bank that was in the process of actually filling out the questionnaire, and it’s a good one. It’s found in the Vendor Management section:

“Has the bank identified and reported its service provider relationships (both domestic and foreign-based) to the FDIC (Y/N)?”

At first glance, you may be tempted to interpret this as asking “Has the bank identified and reported its MAJOR or CRITICAL service provider relationships…?”, but the question does not seem to limit your reporting requirement to a particular class or size of service provider. So are you really obligated to report ALL vendor relationships, from your core provider to your cleaning crew? Taken a face value it would certainly seem so.

To figure out exactly what is required you have to look at the 2 references listed under the question:

“Notification of Performance of Bank Services” FDIC Rules and Regulations 304.3, and
12USC1867 Section 7(c)(2) Bank Service Company Act (BCSA)

In researching this, it appeared at first that it only applied to Banks that owned more than 1% of a bank service provider. But upon further review (sorry, it’s football season), Section 7(c)(2) of the Bank Service Company Act states that any FDIC-supervised institution that has services performed by a third party “shall notify such agency of the existence of the service relationship within 30 days after the making of such service contract or the performance of the service, whichever occurs first.” So again, this looks like ALL vendor relationships need to be reported.

However, in a recent interview at bankinfosecurity.com with Donald Saxinger (senior examination specialist with the FDIC), this exact issue was addressed in the context of reporting social media vendors. Simply put, his response was that only if the vendor provides “banking functions” does it need to be reported to the regulators. Banking functions are defined in Section 3 of the Bank Service Company Act as:

check and deposit sorting and posting,
computation and posting of interest and other credits and charges,
preparation and mailing of checks, statements, notices, and similar items, and
any other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution

Using this list as a reference, only core vendors, item processors and outsourced accounting firms fall into these categories. (Whether or not IT vendors fall into this category will be addressed in a future post. Mr Saxinger makes the point that IT vendors are one of the dependency layers that supports the business process, and as such MAY fall into one of the categories above, depending on the outcome of your risk assessment.) To be safe, since there is no penalty for over reporting, it’s best to report all vendor relationships that even come close to fitting the definition of a bank service company.

So the correct answer is “Yes, we report all of our service provider relationships that provide banking functions to us, as well as any vendors providing a critical dependency to those service providers, as determined by our risk assessment.” Of course, make sure that you do report them. The FDIC form is here, other regulators may have their own reporting mechanism.

14 Sep 2010

From the Field Tom Hinkel 1 Comment

The 5 trickiest FDIC IT examination questions (part 4).

Last time in Part 3 we discussed (at some length) the FDIC IT Exam question “Are project management techniques and system development life cycle processes used to guide efforts at acquiring and implementing technology (Y/N)?”. This time, we address a question from the Part 3 – Audit/Independent Review Program section titled:

“Are the results of your audits/independent reviews used to adjust your risk assessment findings/results (Y/N)?”

I’m going to give you a 2 for 1 bonus on this one. There is another question just after this one that is closely related, so we’ll address them both at the same time:

“Do you have a system for tracking audit and regulatory exceptions to final resolution (Y/N)?”

They should really be asked in the reverse order, because if you have a “system” in place for tracking audit findings, it would necessarily address (as the final step in the audit process) adjusting your risk assessment findings. It would serve no useful purpose to submit to the time and expense of an audit, only to discard the findings. Nevertheless, you want to answer “Y” to both questions, and the proper way to document your answer is found in the references for both questions.

Both questions share the first reference (FDIC Rules and Regulations Part 364 Appendix B Section III (C)(3) and (E)), which states:

Section III (C)(3) – “Each Bank shall…Regularly test the key controls, systems and procedures of the information security program. The frequency and nature of such tests should be determined by the bank’s risk assessment. Tests should be conducted or reviewed by independent third parties or staff independent of those that develop or maintain the security programs.”

And,

Section III (E) – “Adjust the Program. Each bank shall monitor, evaluate, and adjust, as appropriate, the information security program in light of any relevant changes in technology, the sensitivity of its customer information, internal or external threats to information, and the bank’s own changing business arrangements, such as mergers and acquisitions, alliances and joint ventures, outsourcing arrangements, and changes to customer information systems.”

Simply put, you must first test the controls in your risk management program, and then adjust your program with the results of the findings. How do you prove compliance? The answer is found in the details of your audit program, specifically with your external auditor. The terms of the contract with your auditor determine the nature, scope and objectives of the audit engagement. An information security audit (sometimes referred to as a GLBA audit), will by definition include coverage of the key controls, systems and procedures of your information security program.

But just because you have an audit program, you haven’t directly addressed the questions just yet. What do you actually do with the findings from the audit? Whenever the FFIEC mentions a “system”, what they usually mean is that its formalized (policy driven), standardized (operates in a committee, and from an agenda), and documented. So what committee in your organization is tasked with IT security? If you follow FFIEC guidelines, it’s probably your IT Steering Committee. It’s logical then that IT related audit findings would be presented there as well. (Some institutions have a separate audit committee, but if audit findings require changes to IT policies or procedures, they would still need to be presented to IT Steering for implementation.)

So the correct answer to both questions is “Yes, the findings from our information security audits are presented to the IT committee, and are used to adjust our information security program.”

We’re down to the last of the 5 trickiest questions, and I’m going to turn to you for the final post in this series. What IT audit or examination question(s) have you had the most difficulty with? Leave a comment at the bottom, or send me an email, and I’ll discuss not only the correct answer, but most importantly how to answer the “If Yes,…” part.

07 Sep 2010

From the Field Tom Hinkel 1 Comment

The 5 trickiest FDIC IT examination questions (part 3).

Last time in Part 2 we tackled “Does the bank’s strategic planning process incorporate information security (Y/N)?” from the FDIC IT Examination Questionnaire. This time we take a closer look at another question that stumps many institutions preparing for examination;

“Are project management techniques and system development life cycle processes used to guide efforts at acquiring and implementing technology (Y/N)?”

This is the last of 25 questions in the PART 2 section Operations Security and Risk Management, and as with most of the other questions, you want to be able to answer “Y” to this. Although there is no explicit “if Yes,…” followup to this question (as there is to 14 other questions), you really don’t want to answer “Y” to anything unless you can document your answer. But how, exactly, do you document compliance with this? As with many of these trickier questions, it actually carries multiple presumptions:

You have established Project Management Techniques,
You have established System Development Life-Cycle Processes,
You utilize both when Acquiring and Implementing Technology.

It’s important to add here that I have not personally seen any particular increased scrutiny in this area. Most institutions simply answer “Y”, and move on without consequence. But before you decide that documenting compliance with this is too difficult (or unnecessary), remember that for every “Yes” answer, there is an implicit (if not explicit) “If Yes,…” response required. So let’s take a look at the references. The first is the FFIEC IT Examination Handbook, Development and Acquisition, December, 2003.

Development and Acquistion Handbook This is the only question in the FDIC questionnaire that references this particular handbook, so it’s easy to see why this manual is often overlooked when preparing for an IT examination. Additionally, how many financial institutions really utilize the System Development Life Cycle (SDLC) methodology when managing their technology projects? (Very, very few that I am aware of.) Still, having a basic understanding of effective project management is a good thing, because as the handbook states on page 3, “Project management in its basic form involves planning and completing a task.” This is done every day…and by most institutions, several times a day. So what does it take to demonstrate “Project Management Techniques”? Fortunately, the FFIEC does not expect you to become experts in the latest PM techniques and methodologies:

“Examiners should not expect organizations to employ elaborate project management techniques in all situations.”

However,

“The critical importance technology plays in financial institutions dictates the use of appropriate development, acquisition, and maintenance standards. Standards do not guarantee that organizations will appropriately develop, acquire, and maintain technology systems. However, standards do enhance management’s control over projects, thereby decreasing project risks.”

So, how do we define (and document) “appropriate standards”? Regardless of the exact methodology used, all successful projects have the following characteristics:

Detailed project plans (including integration with the overall strategic plan)
Clearly defined expectations and objectives
Realistic budgets
Participation by all departments impacted by the project
Effective communication

The best way to accomplish all of these is by incorporating discussion of IT projects (proposed, in process, and implemented) into your regular IT Steering Committee meetings. If the meetings are well attended, agenda driven, and documented, the correct answer to the question is “Yes. We acquire, implement, and maintain technology according to a risk-based management process, and document the process in our IT Steering Committee.”

By the way, I mentioned that there were multiple references for this question. The other reference cited is for FDIC FIL-12-99. Although this is too complex to cover adequately in this post, the referenced FIL discusses the Uniform Rating System for Information Technology (URSIT), and it’s four critical components: Audit, Management, Development and Acquisition, and Support and Delivery (AMDS), and specifically how these components are used to assess the overall performance of IT within the organization. As the IT Composite Rating affects the institutions’ overall CAMELS rating, it is important enough to cover in more detail in a future post. (I actually covered the “Management” element in a previous post.)

Next, in Part 4: “Are the results of your audits/independent reviews used to adjust your risk assessment findings/results (Y/N)?”

12 Next →