Since the FFIEC published the Cybersecurity Assessment Tool (CAT) in 2015, it has become a popular way to measure control maturity. It includes a series of statements which must be answered "Yes" to achieve "Baseline" maturity, which is the "minimum expectations required by law and regulations or recommended in supervisory guidance."

One benefit of the CAT is that it can be used to see trends, since it is standardized and so widely adopted. One emerging trend is that while most financial institutions have achieved the baseline requirements, there are still baseline requirements which are not met by a subset of financial institutions.

The baseline statements in this article are the top five which have been answered "No" the most. So, let's identify these pain points, review what regulatory guidance says, and see what it means to be "baseline" in those areas. At the end of the article, we'll include some resources and recommendations for helping you get to baseline.

The information in this article is based on data from the Tandem Cybersecurity "Peer Analysis" feature, an optional and anonymous way for financial institutions to compare CAT results with their peers. Learn more and participate in the peer analysis today at Tandem.App/Cybersecurity-Assessment-Tool-FFIEC.

 

Trend #1. Data Flow Diagrams

External Dependency Management > Connections > Connections > Baseline Question #4
"Data flow diagrams are in place and document information flow to external parties."

The Guidance

This baseline requirement stems from the FFIEC's Information Security Booklet, Section II.C.9 Network Controls, which says:

"Management should maintain accurate network and data flow diagrams, and store them securely, providing access only to essential personnel. These diagrams should identify hardware, software, and network components, internal and external connections, and types of information passed between systems to facilitate the development of a defense-in-depth security architecture."

If you're not quite sure what this looks like, have no fear. The FFIEC provides an example in the Architecture, Infrastructure, and Operations Booklet, Section III.C.2 Data Flow Diagrams.

What exactly about this guidance and declarative statement makes it so noteworthy? (Or should I say "No"-worthy?) To understand this, I think we need to have a conversation about the difference between the letter of the law and the intent of the law.

  • The letter of the law says you need to have data flow diagrams.
  • The intent of the law asks "why?" Why do you need data flow diagrams? For what purpose? Answering this question often helps get to the bottom of things.

Looking at the surrounding context in both guidance documents, the answer becomes clear.

The Recommendation

You need to have a process in place to identify and track where your data is going.

You cannot secure your data if you don't know where it lives. So, what are you doing to identify and track your data? The answer to this question should shape how you answer this declarative statement.

  • "No" might just be the right answer if you aren't doing anything at all. (It's not a good answer, mind you. But it might be the right one.)
  • "Yes with Compensating Controls" could be a good choice if you do have a process, but you just haven't sketched it out.
  • "Yes" is your answer if you use a flowchart software to help you create official data flow diagrams. (Or if you're just really good at sketching things out on a whiteboard.) Better yet, use the same program you use to create your network diagrams.

The benefit of creating a data flow diagram is that it is visual. It not only shows the connections, but it can make it easier to recognize gaps or missing pieces.

If you aren't quite sure how to start, download our Sample Data Flow Diagram here. (The data flow diagram can be edited in Visio, which is included with Microsoft Office 365 subscriptions.)

Where is your data? Now feels like a good time to find out.

Trend #2. Firewall Rules

Cybersecurity Controls > Detective Controls > Threat & Vulnerability Detection > Baseline Question #3
"Firewall rules are audited or verified at least quarterly."

The Guidance

The guidance cited on this declarative statement comes from the FFIEC Information Security Booklet, Section III, which states:

"Security operations activities can include the following: Security software and device management (e.g., maintaining the signatures on signature-based devices and firewall rules)."

Now, if you're thinking that puzzle piece doesn't quite look like it fits, you'd be right. The declarative statement was actually based on the 2006 version of the Information Security Booklet (which itself was based on the original version of NIST SP 800-41). The original guidance read:

"Firewall policies and other policies addressing access control between the financial institution's network and other networks should be audited and verified at least quarterly."

So, why the change? It wasn't because "at least quarterly" was bad or incorrect. It's just that there was a better way to say it. NIST SP 800-41 Rev. 1 now reads:

"It is best to review the firewall policy at regular intervals so that such reviews do not only happen during policy or security audits (or, worse, only during emergencies). Each review should include a detailed examination of all changes since the last regular review, particularly who made the changes and under what circumstances. It is also useful to occasionally perform overall ruleset audits by people who are not part of the normal policy review team to get an outside view of how the policy matches the organization's goals. Some firewalls have tools that can do automated reviews of policies, looking for such things as redundant rules or missing rules that are widely recommended. If such tools are available for an organization's firewall, they should be used periodically, probably as part of the regular policy review."

In short, as guidance and technology improve, so should we and so should our firewalls.

The Recommendation

Audit or verify your firewall rules on a regular basis.
(Preferably, at least quarterly.)

Set a reminder on your calendar to check on the firewall rules once every three months.

Use the tools, software, and logs available to you to make sure that your firewall is doing what it needs to be doing. Make sure firewall rules are configured correctly, make note of any concerns, and most importantly, make a plan for improvement, when it is needed.

If this seems like a bit of a stretch, contact your third parties to see how they can help.

Once you get into a rhythm where you are reviewing your firewall rules regularly (i.e., quarterly or more often), you can feel confident about answering this statement "Yes."

Trend #3. Normal Network Activity Baseline

Cybersecurity Controls > Detective Controls > Event Detection > Baseline Question #1
"A normal network activity baseline is established."

The Guidance

The FFIEC Glossary defines a network activity baseline as:

"A base for determining typical utilization patterns so that significant deviations can be detected."

The NCUA Automated Cybersecurity Evaluation Toolbox (ACET) explains:

"Financial institutions should perform an analysis of their network traffic and then develop a normal activity baseline. A baseline is a process for studying the network at regular intervals to ensure that the network is working as designed. It is more than a single report detailing the performance or health of the network at a certain point in time."

This is a lot of fancy words to say, if you know what's normal, you can more easily identify what's abnormal and fix it. For example:

If you know your employees:

Work from 8:00 AM to 5:00 PM

Mistype passwords only once or twice

Only upload data to Microsoft SharePoint

 

→

→

→

Then they shouldn't be:

Logging in at 2:00 AM

Trying to login a hundred times

Sending terabytes of data to Dropbox

Only login from a specific IP address

→

Logging in from multiple IP addresses


You get the idea. A "normal network activity baseline" makes it easier to identify abnormal activity.

The Recommendation

Determine what is normal for your network and set some rules to alert you when things are awry.

Monitoring continues to emerge as a prevalent topic in the world of cybersecurity. It isn't enough to have good systems or even to implement them effectively. Network monitoring helps ensure that systems remain relevant in the face of an ever-changing threat environment. By setting suitable key performance indicators (KPIs) which indicate normal (and abnormal) network activity, you can better secure your systems, your data, and your business.

 Learn more about this topic in the FFIEC Architecture, Infrastructure, and Operations Booklet, Section VI.D.2 IT and Operations Key Performance Indicators.

Trend #4. Audit & Security Event Logs

Threat Intelligence and Collaboration > Monitoring & Analyzing > Monitoring & Analyzing > Baseline #1
"Audit log records and other security event logs are reviewed and retained in a secure manner."

The Guidance

The FFIEC Information Security Booklet, Section II.C.22 states:

"Management should have effective log retention policies that address the significance of maintaining logs for incident response and analysis needs. […] Additionally, logging practices should be reviewed periodically by an independent party to ensure appropriate log management. […] Regardless of the method of log management, management should develop processes to collect, aggregate, analyze, and correlate security information."

The FFIEC Architecture, Infrastructure, and Operations Booklet, Section VI.B.7 Log Management dives further into the topic, giving a helpful list of pros and cons of logging.

Pros: Logging can help with

  • Troubleshooting issues.
  • Investigating potential incidents.
  • Knowing baseline activity (see trend #3).
  • Supporting ongoing improvements.

Cons: Logging is a challenge because

  • There is a ton of data.
  • Storage and capacity are limited.
  • Analysis and response require skill.
  • False positives happen.

 

The Recommendation

Become a logger.

I'm not necessarily suggesting a career change here. (But if you do decide to become a woodsman, here's a helpful resource: What to Do if Your ISO Leaves.) What I am saying is that when you're in the midst of the day-to-day cybersecurity battle, sometimes you can't see the forest for all the trees.

There's some trend-ception going on here. Trends within the trends suggest that we (as an industry) need to do some review work. If there's one thing that we can learn from the baseline statements, it's that financial institutions are (by and large) pretty good at selecting and implementing controls. It's the post-implementation activity that is causing institutions to miss the "baseline" mark in these domains (e.g., logging, monitoring, reviewing, documenting, etc.).

Two viable options for improvement in these areas would involve 1) upskilling and/or 2) investing in a security information and event management (SIEM) system or some kind of log management system. Learn more about your options via CrowdStrike's blog: What is Log Management? The Importance of Logging and Best Practices.

Trend #5. Secure Coding Practices

Cybersecurity Controls > Preventative Controls > Secure Coding > Baseline Question #1
"Developers working for the institution follow secure program coding practices, as part of a system development life cycle (SDLC), that meet industry standards."

The Guidance

Having a SDLC has been an emerging topic in guidance over the years, including:

The idea is generally the same: Having an SDLC is a good idea. It introduces stability, reduces confusion, and makes sure systems (and software) are secure both before and after they are launched.

So, what seems to be the problem?

Well, it seems that the question is not about whether having a SDLC is a good idea or not, or even how to have one. In my experience, the question often comes back to a matter of interpretation of the declarative statement. Are these "developers working for the institution?" If the institution does not have any developers on staff, wouldn't "N/A" be a better answer here? Why is there not an "N/A" answer option for this question on the CAT?

I believe these questions are well addressed with this quote from the FFIEC Information Security Booklet:

"At institutions that employ third parties to develop applications, management should ensure that the third parties meet the same controls."

The Recommendation

Make sure third-party developers working for the institution follow a SDLC.

As part of your ongoing vendor management practices, do your due diligence.

  • In general, if you are using a software-as-a-service (SaaS) product, you should determine if the vendor follows a SDLC. Our sister company, Tandem, puts this information in their "Due Diligence FAQ" document and customers can download it any time through the Due Diligence page in the application. 
  • If you are developing your own software (think: website, mobile application, etc.) or engaging in financial technology ("fintech") activities with a third-party developer, you should dig a little deeper. Create a policy that guides your decisions. Make sure contracts and agreements are favorable. Develop a plan to ensure ongoing security.

If you are doing these things, you can be confident in answering "Yes" to this declarative statement.

Ready to be a Trend Breaker? 

If you answered "No" to one or more of the declarative statements highlighted in this article, do not despair. You most certainly aren't alone, and there are people and solutions here to help.

  • CoNetrix Technology specializes in providing computer network support, IT managed services, and network design and implementation. One area in which CoNetrix Technology specializes is called "Network Threat Protection." This is a suite of Managed Security Service (MSS) solutions, including topics addressed in this article, like: 
    • Firewall monitoring and management. 
    • Cybersecurity monitoring and reporting. 
    • Endpoint and email protection. 
       
  • The Tandem suite of cybersecurity governance, risk management, and compliance (GRC) solutions is also ready to help. For example: 
    • Tandem Policies offers recommendations for your cybersecurity policies, including "Third-Party Secure Application Development," "Project Management," "Cloud Computing," and more. 
    • Tandem Vendor Management features a way to streamline and simplify your third-party risk management processes. Track and document due diligence for your vendors, get helpful reminders, and access reporting on your third-party "developers working for the institution."  
    • Tandem Risk Assessment allows you to identify and classify your data types, connect them with information assets, and perform information security risk assessments. 

See how CoNetrix Technology can help you: CoNetrix.com/Technology/Managed-Security-Services 

Want to see how you measure up with your peers? Sign up for the free Tandem Cybersecurity Assessment Tool product today at Tandem.App/Cybersecurity-Assessment-Tool-FFIEC.