FFIEC – Page 9 – Compliance Guru

28 Jun 2011

Hot Topics Tom Hinkel 2 Comments

Final FFIEC Authentication Guidance just released

Well, after much anticipation and speculation we finally have the updated FFIEC guidance, and there doesn’t appear to be anything radically new here that would justify waiting an additional 6 months. At the very least I thought we might see some changes in the Effectiveness of Certain Authentication Techniques section, or in the Appendix (Threat Landscape and Compensating Controls), but both sections are virtually unchanged. That said, I examined the final release against the draft, and here are my observations divided into 3 categories; Good, Bad, and Odd (all bold and italics in quoted text is mine):

Good

Education: “A financial institution’s customer awareness and educational efforts should address both retail and commercial account holders…”. Agreed. This is a good change from the draft. Education shouldn’t be limited to high-risk transactions only.

Risk Assessments for Financial Institutions: (Generally good, but see below under Bad and Odd)

Layered Security Programs: (Again, generally good, but see below under Bad)

Bad

Multifactor Authentication: The draft release stated that “Financial institutions should implement multifactor authentication and layered security…”. The final release changed that to “Financial institutions should implement layered security…the Agencies recommend that institutions offer multifactor authentication to their business customers.” The verbiage change seems to remove multifactor authentication as a requirement.

Layered Security Programs: “Financial institutions should implement a layered approach to security for high-risk Internet-based systems”…how about layered security for ALL Internet-based systems? (Late edit – the guidance does recommend layered security for both retail and business banking customers, but only “consistent with the risk” for retail customers. More prescriptive guidance on determining a high risk retail customer from a low risk retail customer would have been beneficial here.)

And,

“The Agencies expect that an institution’s layered security program will contain the following two elements, at a minimum.
Detect and Respond to Suspicious Activity”. NO, NO, NO, the FFIEC has previously stated that layered security programs must contain ALL THREE types of controls; preventive, detective and corrective. The omission of preventive controls is particularly puzzling because in the section on Control of Administrative Functions it states “For example, a preventive control could include…An example of a detective control could include…”. Preventive controls are the least expensive to implement, and by far the most effective. It’s such a glaring error that I’m inclined to believe it was a typo.

Risk Assessments for Financial Institutions: The final release changed an “and” to an “or”, possibly introducing some confusion. Here is what the draft release said:

“Financial institutions should review and update their existing risk assessments as new information becomes available, focusing on authentication and related controls at least every twelve months and prior to implementing new electronic financial services.”

The final release says:

“Financial institutions should review and update their existing risk assessments as new information becomes available, prior to implementing new electronic financial services, or at least every twelve months“

The final guidance might be misinterpreted to suggest that conducting risk assessments every 12 months are an either/or situation instead of a minimum requirement.

Risk Assessments for Customers: “A suggestion that commercial online banking customers perform a related risk assessment and controls evaluation periodically” Really? Nothing stronger than a suggestion? This should be a requirement.

Odd

Specific Supervisory Expectation – Risk Assessments: Original draft: “…financial institutions should perform periodic risk assessments and adjust their customer authentication, layered security, and other controls as appropriate in response to identified risks, including consideration of new and evolving threats to customers’ online accounts.”

Final release: “…financial institutions should perform periodic risk assessments considering new and evolving threats to online accounts and adjust their customer authentication, layered security, and other controls as appropriate in response to identified risks.”

Not sure why the verbiage change there, but I don’t perceive any change in meaning…I actually liked the original verbiage better.

General Supervisory Expectations: This verbiage appeared in both the draft and final version, and it is this final odd observation that disturbs me the most…”The concept of customer authentication…is broad. It includes more than the initial authentication of the customer when he/she connects to the financial institution at login.” It would be extremely instructive here to define the “concept” by focusing on what it is, and not what it’s not. Specifically, what more does the concept include beyond initial authentication? The authentication of the transaction itself? The transmission of the transaction through the Internet? All interaction of the user with the interface? The processing of the transaction at the financial institution and/or payment provider? By defining the concept only as “broad”, by saying that it includes more than the initial authentication, this guidance has the potential of expanding the liability of the financial institution, and I can easily see this used in a future legal proceeding to obfuscate the lines of responsibility*.

In the end, although the basics of the guidance are sound, I was disappointed that it didn’t go farther. I will repeat what I said back in February; the guidance is still behind the curve on this issue, and institutions simply have too much to lose. Implement additional preventive controls at the merchant side, additional controls at the institution side (such as dual authorization, out-of-band, positive pay, etc.), conduct annual (or more frequent) risk assessments, and most of all, educate everyone on basic security best practices.

*Particularly on the heals of recent court cases, one of which went the customer’s way, and the other (so far) going the Bank’s way.

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!

14 Jun 2011

Hot Topics Tom Hinkel 4 Comments

SOC 2 vs. SAS 70 – 5 reasons to embrace the change

The SOC 2 and SOC 3 audit guides have recently been released by the AICPA, and the SAS 70 phase-out becomes effective tomorrow. The more I learn about these new reports the more I like them. First of all, as a service provider to financial institutions we will have to prepare for this engagement (just as we did for the SAS 70), so it’s certainly important to know what changes to expect from that perspective. But as a trusted adviser to financial institutions struggling to manage the risks of outsourced services (and the associated vendors), the information provided in the new SOC 2 and SOC 3 reports are a welcome change. In fact, if your vendor provides services such as cloud computing, managed security services, or IT outsourcing, the new SOC reports provide exactly the assurances you need to address your concerns. Here is what I see as the 5 most significant differences between the SAS 70 and the SOC 2 reports, and why you should embrace the change:

Management Assertion – Management must now provide a written description of their organizations’ system (software, people, procedures and data) and controls. The auditor then expresses an opinion on whether or not managements’ assertion is accurate. Why should this matter to you? For the same reason the regulators want your Board and senior management to approve everything from lending policy to DR test results…accountability.

Relevance – The SAS 70 report was always intended to be a your-auditor-to-their-auditor communication, it was never intended to be used by you (the end-user) to address your institutions’ concerns about vendor privacy and security. The SOC reports are intended as a service provider to end-user communication, with the auditor providing verification (or attestation) as to accuracy.

Scope – Although the SAS 70 report addressed some of these, the SOC 2 report directly addresses all of the following 5 concerns:

Security. The service provider’s systems is protected against unauthorized access.
Availability. The service provider’s system is available for operation as contractually committed or agreed.
Processing Integrity. The provider’s system is accurate, complete, and trustworthy.
Confidentiality. Information designated as confidential is protected as contractually committed or agreed.
Privacy. Personal information (if collected by the provider) is used, retained, disclosed, and destroyed in accordance with the providers’ privacy policy.

If these sound familiar, they should. The FFIEC Information Security Booklet lists the following security objectives that all financial institutions should strive to accomplish:

The Privacy and Security elements of GLBA
Availability
Integrity of data or systems
Confidentiality of data or systems
Accountability
Assurance

As you can see, there is considerable overlap between the FFIEC requirements and the scope of a typical SOC 2 engagement.

Testing – Like the SAS 70, the SOC 1 and SOC 2 are available in both a Type 1 and Type II format. A Type I speaks only to the adequacy of vendor controls, but the Type II gives management assurance that the vendor’s controls are not just adequate, but also effective. The auditor can do this in a Type II engagement because they are expected to not just inquire about control effectiveness, but actually observe the control operating effectively via testing. And because the scope of the SOC 2 is significantly greater than the SAS 70 (see above), the test results are much more meaningful to you. In fact, the SOC 2 audit guide itself suggests that because your concerns (particularly as a financial institution) are in both control design and effectiveness, a Type I report is unlikely to provide you with sufficient information to assess the vendor’s risk management controls. For this reason you should insist on a Type II report from all of your critical service providers.

Vendor Subcontractors – This refers to the subcontractor(s) of your service provider, and again this is another FFIEC requirement that is directly addressed in the new SOC reports. The FFIEC in their Outsourcing Technology Services Booklet states that an institution can select from two techniques to manage a multiple service provider relationship:

Use the lead provider to manage all of their subordinate relationships, or
Use separate contracts and operational agreements for each subcontractor.

The booklet suggests that employing the first technique is the least cumbersome for the institution, but that either way;

“Management should also ensure the service provider’s control environment meets or exceeds the institution’s expectations, including the control environment of organizations that the primary service provider utilizes.”

The audit guidelines of the SOC 2 engagement require the service auditor to obtain an understanding of the significant vendors whose services affect the service provider’s system, and assess whether they should be included in the final report, or “carved-out”. Given the regulatory requirement for managing service providers you should insist on an “inclusive” report.

In summary, there will be an adaptation curve as you adjust to the new reports, but in the end I think this is an overwhelming step in the right direction for the accuracy and effectiveness of your vendor management program.

17 May 2011

From the Field Tom Hinkel 0 comment

The IT Strategic Plan – Why, Who, & How

One of the most common examination findings recently (particularly with the FDIC) has been the lack of an IT Strategic Plan. I’m not sure why the focus lately (perhaps the shift from the CAMELS “A” to the “M”?), but the concept is certainly not new. The regulatory mandate for it is found in the 2004 FFIEC Management Handbook:

“The Board of Directors and management should* implement an IT planning process that:

Aligns IT with the corporate wide strategic plan;
Aligns IT strategically and operationally with business units;
Maintains an IT infrastructure to support current and planned business operations;
Integrates IT spending into the budgeting process and weighs direct and indirect benefits against the total cost of ownership of the technology; and
Ensures the identification and assessment of risk before changes or new investment in technology.”

The first requirement of an effective IT planning process is alignment with the overall strategic plan, yet whenever I ask a group of financial professionals how many have seen their own strategic plan, very few hands go up. I get more hands in a group of senior management than in a group of network administrators, which seems to make sense except for one thing; the administrators are the ones actually maintaining the IT infrastructure (#3 above). So the very folks tasked with making sure the infrastructure is aligned with the overall strategic plan, probably haven’t even seen it!

This is the real disconnect from my perspective. Although you can develop an IT Strategic Plan from a template fairly quickly using standardized verbiage, integrating it into the overall plan, and then executing it, is much trickier. It should be a live document, linking the overall Strategic Plan with IT projects and issues through the IT Steering Committee. In fact, the FFIEC even suggests that the IT Steering Committee is the ideal forum for this, stating that the committee:

“…may also oversee the development and maintenance of the IT strategic plan.”

And furthermore,

“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.”

So the Management Handbook strongly suggests that IT steering is the best forum, and that everyone from the Board of Directors, to IT line management, to business unit management should participate. But this brings us back to dilemma I mentioned above; that IT line management (and most business unit management, for that matter) are rarely familiar enough with the overall strategic plan to effectively affect alignment. This brings us to the “how”:

Step 1 – Senior management must communicate the mission,
Step 2 – Ensure that the IT Committee is tasked with implementing that mission by making sure all IT initiatives support and enhance the missions’ goals and objectives.
Step 3 – Most importantly, make sure the committee has the tools and expertise necessary to effectively monitor, gather, analyze and report the data that will document the entire process. Because in the end…

“…institutions that are better at keeping IT aligned with changing business goals and objectives are positioned to compete more effectively.”

*In FFIEC-speak, “should” really translates to “must”.

29 Apr 2011

Hot Topics Tom Hinkel 0 comment

Vendor Management and the SAS 70 Replacement

I’ve written about the replacement for the SAS 70, which officially phases out on June 15th, previously. But because this one report is being replaced with 3 new reports, financial institutions have an additional challenge that they didn’t have before. Your vendor management program must now determine the most appropriate report to request based on your specific concerns regarding the vendor. Of course, once the correct report is identified, you must then acquire and review it…this step doesn’t change from the old SAS 70 world.

In the past, determining the correct report wasn’t really necessary, as the SAS 70 was the only reporting tool available if you needed to validate the security controls in place at a service provider. With the SAS 70 being replaced with the SOC 1, SOC 2, and SOC 3, you have 3 options to choose from (and with Type I and Type II versions for the SOC 1 and SOC 2, you really have 5 options!). So how do you choose? It might make sense at this point to back up and take a look at the overall vendor management process.

The FFIEC considers risk management of outsourced services to consist of the following components:

Risk Assessment (assessing the risk of outsourcing)
Service Provider Selection (the due diligence process)
Contract Issues (prior to signing the contract)
Ongoing Monitoring (post contract)

Most institutions believe that their vendor management program begins once the contract is signed, i.e. once the vendor become a vendor. But it’s clear that the vendor management process must begin well before that, and in fact third-party reviews like the old SAS 70, and the new SOC reports, should be obtained during the due diligence phase. This is the proposal phase (step 2 above), well before the decision to engage the vendor.

According to the FFIEC, the due diligence process should determine the following about the vendor:

Existence and corporate history;
Qualifications, backgrounds, and reputations of company principals, including criminal background checks where appropriate;
Other companies using similar services from the provider that may be contacted for reference;
Financial status, including reviews of audited financial statements;
Strategy and reputation;
Service delivery capability, status, and effectiveness;
Technology and systems architecture;
Internal controls environment, security history, and audit coverage;
Legal and regulatory compliance including any complaints, litigation, or regulatory actions;
Reliance on and success in dealing with third party service providers;
Insurance coverage; and
Ability to meet disaster recovery and business continuity requirements.

That is a lot of information to obtain from a non-vendor, but the new SOC reports, and the SOC 2 report in particular, will go a long way towards addressing many of the above concerns. Specifically; systems architecture, internal controls, any third-party providers, insurance coverage, and business continuity would all be addressed in a SOC 2 Type II* report.

I’ve developed this flowchart to assist you with the correct SOC report selection process, and I encourage you to discuss it with your auditor. Of course once the correct report for that vendor has been determined, you must then obtain and evaluate it…that is a topic for a future post.

*Note: We are still waiting for the AICPA to finalize the work program for the SOC 2 and SOC 3 reporting format. Check with your auditor for additional guidance.

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.

← Previous 1…8910…15 Next →