Skip to main content

Observations from Our Review of Completed Cybersecurity Assessments

Written by admin on . Posted in Information Technology.

By: Mike Detrow, Senior Consultant and Manager of IT

Financial institutions have begun the process of completing the Cybersecurity Assessment Tool provided by the FFIEC and some are struggling to complete it accurately. In this article, I will discuss the process for using the tool, as well as some of our observations from the review of these completed assessments.

Using the Tool
The Cybersecurity Assessment Tool was designed to help financial institutions identify their Inherent Risk Profile and evaluate their level of Cybersecurity Maturity. The end result is for financial institutions to understand the relationship between the risks associated with the activities, services, and products offered and the adequacy of the controls used to mitigate these risks. During the completion of the tool, management must collaborate with personnel from all internal departments and include third parties that are providing risk management services, such as IT service providers.

Determine the Inherent Risk Profile
The assessment process begins with the identification of the institution’s Overall Inherent Risk Profile. The tool identifies five categories for the activities, services, and products in place at the institution. For each activity, service, or product, management must select the most appropriate inherent risk level based upon the options listed within the tool. Once this process is complete, management must determine the Overall Inherent Risk Profile based on the number of applicable statements in each risk level. As an example, if the majority of activities, products, or services fall within the Minimal risk level, management may determine that the institution has a Minimal Overall Inherent Risk Profile. As each category may pose a different level of inherent risk, management should consider evaluating whether a specific category poses additional risk in addition to evaluating the number of instances selected for a specific risk level.

Determine Cybersecurity Maturity Level
The second part of the assessment is to evaluate the institution’s Cybersecurity Maturity Level for each of the five domains identified within the tool by indicating whether or not the institution has attained each of the Declarative Statements within a specific maturity level for that domain. To attain a specific Cybersecurity Maturity Level for a domain, 100% of the Declarative Statements within that maturity level must be attained.

Determine Relationship Between the Two Parts
The tool includes an illustration showing the relationship between the Inherent Risk Level and the Cybersecurity Maturity Level. As an example, if an institution has determined that it has a Minimal Overall Inherent Risk Profile, the recommended Cybersecurity Maturity Level range for each domain is Baseline to Intermediate. As an institution completes the assessment, the first goal should be to ensure that the Baseline Cybersecurity Maturity Level is attained for each of the five domains identified by the tool as the Baseline level identifies the minimum expectations required by law, regulations, or supervisory guidance. If an institution has not yet reached the Baseline level at the time of the Cybersecurity Assessment completion, an action plan should be developed to implement the requirements to attain the Baseline level. Once the institution has attained the Baseline level, management can determine the target Cybersecurity Maturity Level and develop an action plan to attain that level. In the example above, for an institution with an Overall Inherent Risk Profile of Minimal, management may determine that their target Cybersecurity Maturity Level is Evolving. It is important for financial institutions to understand the relationship between the Overall Inherent Risk Profile and the recommended Cybersecurity Maturity Level identified in this tool to recognize that regulators will not expect an institution with a Least or Minimal Overall Inherent Risk Profile to attain a Cybersecurity Maturity Level of Advanced or Innovative.

Observations
The primary issue that we have identified through our review of completed Cybersecurity Assessments is the misinterpretation of the Declarative Statements. Each of the Declarative Statements within the Baseline level has a reference to the associated FFIEC Information Security Booklet, which allows institutions to locate additional information about the requirements to attain the statement. Management should review the references to the FFIEC Information Security Booklets to fully understand the meaning of each Declarative Statement. Interpretation of the Declarative Statements for Cybersecurity Maturity Levels above Baseline may require assistance from a third party or additional research.

We have found that a number of institutions with Inherent Risk Profiles of Least or Minimal have selected Yes for many Declarative Statements that the institution has not yet attained. If management is unsure of the meaning of a Declarative Statement, appropriate expertise should be sought before selecting Yes. Incorrectly indicating that the institution has attained a Declarative Statement will eventually lead to audit and examination findings.
Small community financial institutions should thoroughly evaluate a number of the Baseline level Declarative Statements before indicating that they have been attained. To view a list of these Declarative Statements, click here.

Conclusion
Completion of the FFIEC’s Cybersecurity Assessment Tool is a new process for financial institutions that will require feedback from the institutions that use the tool, as well as additional clarification from regulatory agencies. Institutions that spend time with examiners and risk management providers to understand and complete the tool accurately should gain a better understanding of their current cybersecurity risk level and be able to identify additional mitigating controls that can be implemented to prevent or reduce the impact of a cyberattack.

For more information on this article and/or how Young & Associates can assist your bank, contact Mike Detrow at 1.800.525.9775 or click here to send an email.

Do You Know Where Your Data Went Last Night?

Written by admin on . Posted in Information Technology.

By: Mike Detrow, CISSP, Senior Consultant and Manager of IT

Maybe your data went to a football game on an employee’s smart phone. Or, perhaps your data met some international friends at an offsite backup location used by one of your service providers. In either case, if you do not know how your data moves and where your data is stored, you cannot protect it.

During our IT Audit engagements, it is not uncommon to see bank employees storing or transferring non-public information (NPI) using services such as Google Drive or Dropbox. This creates a very dangerous situation if one of these services suffers a data breach or the data is synchronized to personal devices infected with malware. In most of these cases, senior management does not understand how employees are handling NPI.

The importance of understanding and controlling NPI data flow and data storage is emphasized in the newly released version of the FFIEC’s Information Technology Management Handbook, as well as in the declarative statements to meet the Baseline maturity level within the Cybersecurity Assessment Tool. This article will discuss a process that can be used to document the data flow and data storage locations used within your institution and those used by your third-party service providers.

Here’s a way this could be used to illustrate the way that an institution can document data flow and data storage. You will first identify each Service or Application that uses NPI. Some examples of these services and applications include: core processing, lending platform, internet banking, and online loan applications. Next, you will identify the Vendor(s) associated with each service or application. The Process Type is used to identify the various processes that are performed using the specific service or application that may use different methods for accessing the data or result in data being transmitted through different connectivity types. An example of different process types can be illustrated with internet banking where data may flow between the core processing system and the internet banking system through a dedicated circuit, but customers access the internet banking system through a home internet connection. The Type of Data will most often be customer NPI, but may also include proprietary institution data. Data can be accessed in numerous ways including: institution workstations, institution servers, employee mobile devices, customer PCs, and customer mobile devices. The Connectivity Type may include: dedicated circuits, virtual private networks (VPN), local area networks (LAN), wide area networks (WAN), wireless networks, or the internet. Controls in Transit may include: encryption, firewall rules, patch management, and intrusion prevention systems (IPS). The Primary Storage Location(s) should include known locations where the data is stored such as: application or database servers, data backup devices, service provider datacenters, and service provider backup locations. The Optional Storage Location(s) should consider other places where data can be stored such as: removable media, an employee’s workstation, mobile devices, Dropbox, and Google Drive. Identifying the Optional Storage Location(s) may take a significant amount of time, as this step will involve discussions with application administrators to understand the options for exporting data and discussions with employees to understand their processes for transferring and storing data. A review of this information may lead to the implementation of additional controls to block the use of unapproved sharing and storage services.

Controls at Rest may include: encryption, physical security, and environmental controls. The Access Rights column should identify who can access the data at any point in time, which may include institution employees, service provider employees, and subcontractors used by a service provider.

This may seem like a daunting task to complete, and it may take a significant amount of time depending on the size and complexity of your institution. One option for implementing this process is to start with your annual vendor review process rather than trying to complete the process for all of your services and applications at one time. When you are gathering and reviewing documentation from each service provider, complete the table shown above for the service or application provided by that service provider. Documentation for internally managed systems and applications can also be completed over a period of time.

Upon completion of this process, you should have a full understanding of how your data moves between devices and where the data is stored. This information will allow you to justify the risk ratings within your information security risk assessment and identify additional controls that need to be implemented to properly protect your data.

For more information on this article, contact Mike Detrow at 1.800.525.9775 or click here to send an email.

Network Vulnerability Testing and the Case for Increasing Test Frequency

Written by admin on . Posted in Information Technology.

By: Mike Detrow, CISSP, Senior Consultant and Manager of IT

Even though you may only hear about a few IT vulnerabilities through mainstream news outlets each year, new vulnerabilities are being identified and reported on a daily basis. If remediation steps are not taken, a financial institution may be vulnerable to a cyber-attack if its information systems are affected by one of these vulnerabilities. A number of methods can be used to identify vulnerabilities that affect an institution’s information systems, including: network vulnerability testing, subscribing to services that provide vulnerability alerts, and monitoring vendor websites for vulnerability notifications. This article will focus on identifying vulnerabilities that currently exist within an institution’s information systems through the use of network vulnerability testing.

Network vulnerability testing is used to identify vulnerabilities such as misconfigurations, default passwords, and missing patches on network devices such as PCs, servers, routers, printers, and firewalls. This testing is typically performed using an automated tool that scans these devices for known vulnerabilities. The automated tool can perform either an un-credentialed scan or a credentialed scan. An un-credentialed scan assesses the vulnerabilities that can be detected without network credentials. A credentialed scan assesses the vulnerabilities that can be detected by a user that can log onto the network. An assessor reviews the results from the automated tool and performs tests to determine the applicability and criticality of the vulnerabilities detected before providing a report of the vulnerabilities and recommended remediation steps to the client.

We typically talk about external network vulnerability testing and internal network vulnerability testing. External network vulnerability testing focuses on the firewalls that the institution has implemented to protect its internal network. Internal network vulnerability testing focuses on the devices connected to the internal network which encompasses the institution’s operations center and any branch office networks.

In the past, it was typically deemed acceptable for smaller financial institutions to have network vulnerability tests performed on an annual basis. While this may have been acceptable for institutions with very static configurations, many institutions are actually making numerous changes to their IT environment over a one-year period that may introduce new vulnerabilities. Changes such as new software, new devices connected to the network, and firewall rule changes can create vulnerabilities that may not be identified until the next annual vulnerability test. Another common issue occurs when an institution takes steps to remediate an identified vulnerability, but the steps taken do not eliminate the vulnerability and it remains exploitable until the next annual network vulnerability test. It is also common for some institutions to focus only on external network vulnerability testing. However, it is important to test the internal network as well to identify any vulnerabilities that may be exploited by insiders or malware that makes its way onto an internal device.

With the increasing number of large-scale data breaches and the focus on cybersecurity, financial institutions should anticipate increased scrutiny from examiners during their evaluation of each institution’s selected network vulnerability testing schedule. While the network vulnerability testing frequency required for each financial institution will differ based on its size and complexity, most institutions should be increasing the frequency of external network vulnerability tests beyond once each year to help identify any potential vulnerabilities before they are exploited. Institutions should also consider increasing the frequency of internal network vulnerability testing to identify any vulnerabilities that may be exploited by insiders or malware.

For more information about this article or to learn more about the services offered by Young & Associates, Inc. to assist your financial institution with network security, please contact Mike Detrow at 1.800.525.9775 or click here to send an email.

 

The Importance of User Access Reviews

Written by admin on . Posted in Information Technology.

By: Mike Detrow, CISSP, Senior Consultant and Manager of IT

The FFIEC has emphasized the importance of reviewing user access granted within all of the IT systems in use at a financial institution, including but not limited to: the network operating system (Active Directory®), core processing system, new account and lending platforms, document imaging system, internet banking system, and wire transfer system through its recent statement about compromised credentials. The frequency of these reviews will depend on the size and complexity of the financial institution; however, it is a good practice to perform an annual review at a minimum. User access reviews will help to identify accounts that have been assigned excessive privileges, accounts with access that have not been updated to reflect job position changes, accounts that do not require password changes in accordance with the institution’s policies, and dormant accounts. Failing to perform user access reviews on a regular basis will place the institution at a higher risk for:

  • A terminated employee gaining remote access to the network or email system
  • Segregation of duties issues if an employee moves to a new department, but retains system privileges from the previous department
  • Misuse of dormant administrative accounts that are still active
  • System compromise through the use of vendor passwords that never expire

The user access review process should include an employee that is independent of the system administration role for each IT system to verify that an administrator is not assigning excessive privileges to users or creating hidden accounts to use for illicit activities.

For some systems, the process to obtain all of the security details in an easy-to-understand report can be difficult. This is the case with Active Directory unless additional tools are used to compile the information into a simple report. To simplify the process of reviewing Active Directory accounts, Young & Associates, Inc. has developed the Account Auditor for Active Directory. This tool makes it easy for financial institutions to generate the following security reports:

  • A listing of all of the user accounts within Active Directory
  • Group memberships for each account
  • Dormant accounts
  • Disabled accounts
  • Accounts with passwords that do not expire
  • Accounts with passwords that have not been changed within the past year

The Account Auditor for Active Directory will simplify your network operating system user account review process, reduce IT Audit findings, and is designed to work with your Windows® server operating system to generate your information quickly and easily. There’s no new software to install! It available for just $100.  Click here for more details.

The Overlooked Risks of VOIP

Written by admin on . Posted in Information Technology.

By: Mike Detrow, CISSP, Senior Consultant and Manager of IT

We are seeing financial institutions continue to expand their use of VOIP (Voice Over Internet Protocol) to reduce expenses and increase efficiencies for voice communications. VOIP is a technology that refers to transmitting voice communications over the internet, LAN (Local Area Network), or WAN (Wide Area Network), rather than through the PSTN (Public Switched Telephone Network). We have found that the risks associated with a VOIP system are not always properly evaluated prior to implementation.

Some of the risks associated with the use of VOIP include:

  • Denial of service attacks
  • Emergency services inability to use automatic location services (depending on configuration)
  • Customer service issues during power or network outages
  • Interception of telephone conversations
  • Unauthorized or fraudulent use of the telephone system

We have seen situations where public safety personnel were not able to respond to an emergency in a timely manner due to the misconfiguration of E911 physical address information. In addition, we have seen multiple VOIP system outages due to problems at vendor data-centers or the lack of backup plans for data line failures.

During the process of evaluating and implementing a VOIP system, financial institutions should consider the following steps:

  • Perform a risk assessment to identify the risks associated with the VOIP system and the mitigating controls that will be used.
  • Perform due diligence steps for any vendors involved with the VOIP system and include these vendors in the ongoing vendor review process.
  • Develop contingency plans for communications during power or network outages.
  • Develop processes to test the contingency plans and to test E911 physical address assignments.
  • Verify that VOIP communications that pass over public networks or the internet are encrypted.
  • Develop system hardening processes for the VOIP system equipment.
  • Develop patch management processes for the VOIP system equipment.
  • Develop security procedures for the VOIP system to prevent denial of service attacks and unauthorized use of the system.
  • Include the VOIP system in ongoing vulnerability assessments.

With the appropriate planning and ongoing risk management procedures, a financial institution can develop and maintain a secure VOIP system that will reduce expenses and improve customer service.

For more information on this topic or on how Young & Associates, Inc. can assist your bank with its IT needs, contact Mike Detrow at 1.800.525.9775 or click here to send an email.

Connect with a Consultant

Contact us to learn more about our consulting services and how we can add value to your financial institution

Ask a Question