The Safe Systems Compliance Team – Page 6

The FFIEC recently released a long-awaited update to the Cybersecurity Assessment Tool, and we think overall it is a relatively minor but useful evolution. But before we get into the details of what the update does address, it’s important to note that it did not address the ambiguity issues that plague the current assessment. One example…in the Inherent Risk section, there are a plethora of semicolons. Are they supposed to be interpreted as “or” or “and”? Take the question about personal devices being allowed to connect to the corporate network (4th question in the Technologies and Connection Types category).

The minimal risk level states the following:

“Only one device type available; available to <5% of employees (staff, executives, managers); e-mail access only.”

If the semicolons are interpreted as “or,” the statement reads like this:

“Only one device type available OR available to <5% of employees (staff, executives, managers) OR e-mail access only”.

This is considerably different than:

“Only one device type available AND available to <5% of employees (staff, executives, managers) AND e-mail access only”.

Unfortunately, the update did not offer any clarification on this, and as a result we are left to guess what the regulator’s intentions are. Our approach has been to risk-rank each question segment individually. So in the example above, what is the greater risk? The number of device types, the number of employees using them, or what they are allowed to access? We rank the risk of what employees are allowed to access highest, followed by the number of employees accessing, followed by the device types. And this is just one example, 18 of the 39 inherent risk questions require this type of interpretive challenge, and correct interpretation is absolutely critical, because your gap analysis and subsequent cyber action plan depend on an accurate inherent risk assessment.

Appendix A

However, the FFIEC CAT update does impact 2 areas; the first is a more detailed cross-reference in Appendix A mapping the baseline statements to the 2 recently released IT Handbooks (Management and Information Security), and the second will give most FI’s more flexibility when evaluating declarative statements.

First, the changes to Appendix A. Compare the original Risk Management/Audit section…

Risk Management/Risk Assessment: The risk assessment is updated to address new technologies, products, services, and connections before deployment.

Source: IS.B.13: Risk assessments should be updated as new information affecting information security risks is identified (e.g., a new threat, vulnerability, adverse test result, hardware change, software change, or configuration change). IS.WP.I.3.3: Determine the adequacy of the risk assessment process.
* Information Security, E-Banking, Management, Wholesale Payments

…with the updated section:

Risk Management/Risk Assessment: The risk assessment is updated to address new technologies, products, services, and connections before deployment.

Source: IS.II.A: pg7: External events affecting IT and the institution’s ability to meet its operating objectives include natural disasters, cyber attacks, changes in market conditions, new competitors, new technologies, litigation, and new laws or regulations. These events pose risks and opportunities, and the institution should factor them into the risk identification process.

IS.II.C:pg11: Additionally, management should develop, maintain, and update a repository of cybersecurity threat and vulnerability information that may be used in conducting risk assessments and provide updates to senior management and the board on cyber risk trends.

IS.WP.8.3.d: Determine whether management has effective threat identification and assessment processes, including the following: Using threat knowledge to drive risk assessment and response.

This more detailed and expanded set of cross-refences will be useful for both institutions and consultants as they navigate their way through this interpretive minefield.

However, this could be the most significant change:

“The updated Assessment will also provide additional response options, allowing financial institution management to include supplementary or complementary behaviors, practices and processes that represent current practices of the institution in supporting its cybersecurity activity assessment.” (Emphasis added)

It took us a while to find how this one was implemented because we were looking for a whole new section, but all the FFIEC has done is add a third option to your response to the declarative statements in the Control Maturity section. Prior to this update, you could only answer either “Y” or “N”. Now there is a third option; “Y(C)”, or Yes with Compensating Controls:

CAT Yes/No Controls

The FFIEC defines a Compensating Control as:

“A management, operational, and/or technical control (e.g., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system.”

Essentially what this means is now institutions will be able to document adherence to a declarative statement using either direct off-set (primary) controls, or alternative compensating controls, IF they are able to properly identify them. Because these controls are “in lieu of” recommended controls, they are necessarily more difficult to identify and document, much more so than a primary control.

That said, having a way for institutions to document their adherence to a particular declarative statement using either direct or compensating controls is a significant improvement, and should ultimately result in more declarative statements being marked as achieved. Be careful though, although we haven’t seen any IT exams since the update, a “Y(C)” response may very well prompt additional regulatory scrutiny precisely because it requires more documentation.

Safe Systems has assisted almost 100 customers through the CAT so far, helping to document their responses, producing stakeholder reports, and crafting action plans. Let us know if we can help you.

This request was seen in a recent State examiners pre-examination questionnaire, and although I usually like to see a request a couple of times from different examiners before identifying it as a legitimate trend, this one could prove so potentially problematic that I thought I needed to get ahead of it.

Before we go much farther, it’s important to distinguish between “data-flow diagrams” and the “work-flow analysis”, which is a requirement of the business continuity planning process. They are completely separate endeavors designed to address two very different objectives. The BCP “work-flow analysis” is designed to identify the interdependencies between critical processes in order to determine the order of recovery for the processes. The “data-flow diagram” is designed to:

Supplement (management’s) understanding of information flow within and between network segments as well as across the institution’s perimeter to external parties.

It’s important to note here that what the examiner asked for actually wasn’t unreasonable, in fact it appears word-for-word in the FFIEC AIO Handbook:

Common types of documentation maintained to represent the entity’s IT and business environments are network diagrams, data flow diagrams, business process flow diagrams, and business process narratives. Management should document and maintain accurate representations of the current IT and business environments and should employ processes to update representations after the implementation of significant changes.

And although this particular examiner quoted from the Operations Handbook, the term “data flow” (in combination with “maps”, “charts” and “analysis”) actually appears 15 times in 5 different Handbooks; Development and Acquisition, Information Security, Operations, Retail Payment Systems, and Wholesale Payment Systems.

So this concept is certainly not unheard of, but previously this “understanding of information flow” objective was achieved via a network topology map, or schematic. Sufficiently detailed, a network schematic will identify all internal and external connectivity, types of data circuits and bandwidth, routers, switches and servers. Some may even include workstations and printers. In the past this diagram, in combination with a hardware and software inventory, was always sufficient to document management’s understanding of information flow to examiners. But in this particular case the examiner highlighted (in bold) this section of the guidance (and this was the most troublesome to me):

Data flow diagrams should identify:

Data sets and subsets shared between systems;

Applications sharing data; and

Classification of data (public, private, confidential, or other) being transmitted.

…and…

Data flow diagrams are also useful for identifying the volume and type of data stored on various media. In addition, the diagrams should identify and differentiate between data in electronic format, and in other media, such as hard copy or optical images.

Data classification? Differentiation between electronic, printed and digital data? This seems to go way beyond what the typical network schematic is designed to do, way beyond what examiners have asked for in the past, and even possibly beyond the ability of most institutions to produce, at least not without significant effort. Of course using the excuse of “unreasonable resource requirements” will usually not fly with examiners, so what is the proper response to a request of this nature?

Fortunately there may be a loophole here, at least for serviced institutions, and it’s found in the “size and complexity” predication. The guidance initially states:

Effective IT operations management requires knowledge and understanding of the institution’s IT environment.

This is the underlying requirement, and the core issue to be addressed. It then goes on to state that documentation of management’s “knowledge and understanding” be “commensurate with the complexity of the institution’s technology operations”. And depending on size and complexity, this may include “data-flow diagrams”. So the examiner is effectively saying in this case that they feel that a “data-flow diagram” is the most appropriate way for the management of this outsourced institution to document adequate knowledge and understanding of their technology operations. I suggested that the institution respectfully disagree, and state:

Our management believes, based on our size and complexity as a serviced institution, that an updated detailed schematic, and current hardware and software inventories, adequately demonstrates sufficient knowledge and understanding of our technology operations.

This directly addresses the core issue and I’m pretty sure the examiner will agree, but I’ll let you know. In any case it’s worth pushing back on this because of the potentially enormous resource requirement that it would take to comply with the request, both now and going forward.

Now here is the real question…should you require the same level of documentation (i.e. data classification and data type differentiation) from your core vendor? And if so, are you even likely to get it from them?

Author: The Safe Systems Compliance Team

FFIEC Cybersecurity Assessment Tool Update

The minimal risk level states the following:

If the semicolons are interpreted as “or,” the statement reads like this:

This is considerably different than:

Appendix A

“Data-flow diagrams”