By: Michael Gerbick, COO

Do you have a due diligence packet?

Can you answer these questions for our due diligence?

Our outsourced vendor relationship manager will be reaching out to you for due diligence information.

As a trusted vendor to many clients, we receive requests/comments like these every day from our customers and it brings to light the large disparity between what is requested and what is understood from the information. We are trusted with personal, identifiable information daily, and it is our responsibility to do our best to protect that information. No one can guarantee foolproof protection as it’s not “if” but “when” security breaches will occur. We can, however, adhere to industry standards that assist in reducing these risks significantly. This is important when looking internally at our own systems and processes as well as our critical vendors.

There are several areas to consider in the due diligence evaluation. I have highlighted a few of these areas below to assist you in choosing a trustworthy vendor.

Vendor Purpose

Knowing how a vendor will be leveraged will begin to shape the risk analysis needed for the remaining due diligence areas. Think about if they will need access to your environment, if they will need access to your confidential information, and/or if they will provide a service that you could not otherwise handle without them. How long have they been in business? Have they declared bankruptcy? Your risk profile will start to take shape regarding strategic and reputational risk and will direct the due diligence areas you focus on going forward.

Information Access

At a most basic level, how will your vendor access your information? Remotely from anywhere, with unbridled access to your core system? Onsite via paper documents with 24-hour oversight by your staff? Or will the service be executed in a hybrid fashion (onsite and remote)? In addition to access, will you allow the vendor to save the information outside of your environment? Will you send information electronically to the vendor and if so, how will you communicate? Vendors that do not have direct access to your core or large repositories of confidential information may still touch non-public information. You may consider a business email compromise for your vendor and its impact to your organization as a scenario when you approach sharing non-public information through either email or a secure file transfer. Thinking about how the information will be accessed, transferred, and used will help in your due diligence process and help ensure that you’ve done your best to get the valuable service from your vendor with a method of accessing confidential information you are most comfortable with.

Information and System Controls

This is more than just passwords. It’s about if the vendor’s systems are updated frequently with the latest patching, data center security (SOC 1 and 2 reports), the encryption on devices, the MFA (Multifactor Authentication) in place at the account and device level, the antivirus, antimalware, protection from ransomware and MDR (Managed Detection and Response), where your information is accessed and that all the system controls are monitored. Every week, there are news reports of another ‘hack’ and ransom of individuals’ sensitive information. The only constant here is that this is reality, and the protections and attacks are ever-changing and evolving. There is a lot to unpack here, and you can ask thousands of questions of your provider. Ultimately, you need to decide if the information you share with them is held in an environment that meets your expectations of safety and security. An informed and trusted IT leader on your team can help make sense of this space for your organization and identify those areas that apply to you. At a minimum a complete set of robust questions or list of requests will help you immediately highlight those vendors that can help you from those that may just introduce risk to your organization.

Business Continuity, Incident Response Plan, and Disaster Recovery

An event will happen. Plans in place that are reviewed and tested regularly will minimize the negative impact. Ask your vendor if they have these plans and discuss with them to understand how robust they are. Gain a comfort level that the vendor cares about managing the inevitable event as much as you do. If they are a critical vendor and something happens to them, you should expect them to have a plan in place to mitigate your risk.

Confidential Information

In addition to specific language in your vendor contract and the methods of accessing confidential or non-public information, ask about cybersecurity-specific insurance coverage in case of an incident. If their staff is touching your information, ask about their hiring practices and the expertise of their personnel, confidentiality agreements, and background checks.

Conclusion

There are many talented vendors out there to assist your organization. A consistent approach with a defined leader on your team will elevate the quality of the vendors your organization chooses to do business with. The few areas discussed above help manage risk when something goes wrong. The more prepared your vendor and you are for those inevitabilities, the less impact it will have on you and your customers.

If you want to find out more about vendor due diligence or need help improving or starting your vendor due diligence program, please contact Michael Gerbick at mgerbick@younginc.com or 330.422.3482. Young & Associates can help you every step of the way.

By: Edward Pugh, CAMS, CAMS-Audit, AAP, CFE, Consultant

For many financial institutions, the concept of a BSA/AML Model Validation is new. In the past, model validations were in the domain of larger financial institutions, typically with $1 Billion or more in assets. In general, model validations are a component of model risk management (MRM), and the guidance for MRM doesn’t easily conform to AML models, particularly models purchased from vendors. To rectify this, the regulatory agencies released an Interagency Statement of Model Risk management for Bank Systems Supporting Bank Secrecy Act/Anti-Money Laundering Compliance in April 2021. We have found that subsequent to the release of this guidance, examiners are frequently requesting that model validations be completed for financial institutions of all sizes.

The purpose of Anti-Money Laundering (AML) model validation is to evaluate the effectiveness and accuracy of an AML model in identifying potentially suspicious transactions and preventing money laundering and terrorist financing activities.

A model validation consists primarily of three components:

• Conceptual Soundness – This entails (among other considerations) the review of documentation and empirical evidence used and variables selected for the model. Much of this information is found in the implementation documentation.
• Ongoing Monitoring – This component confirms that the model is appropriately implemented and is performing as intended. Additionally, the processes and procedures for changes to the model are evaluated. For example, when an agent is added or thresholds are changed, what is the process leading up to the change?
• System/Outcome Analysis – This verifies that the alerts generated are indeed valid. On the flip side, is the model missing transactions due to parameter settings or data issues?

Common Findings

As more financial institutions are having model validations performed, we have found some common findings, both in validation reports and examination reports. Below are some of the most common findings. Reviewing these findings may help a financial institution prepare for its first validation. These include:

• Data Quality Issues – Appropriate data is not flowing to the model. This often includes monetary instrument information, wire information, ATM activity, and NAICS codes. A particular concern is 314(a) lists – data from closed accounts and non-customer transactions (such as monetary instrument purchases) is not included in the searches.
• Inadequate Model Governance – This includes lack of model documentation, lack of proper oversight and controls, and lack of model testing.
• Lack of Documentation of Filtering Thresholds – This includes documentation as to why thresholds were selected, as well as why/how any subsequent changes were made.
• Missing or Incomplete Mapping Documentation – Mapping documentation demonstrates how inputs from various systems flow into the AML Model. This information is usually included in the implementation documentation, though issues often arise when new products and services are introduced.
• No Reconciliation Procedure – Institutions should periodically reconcile the data between the system feeding the data into the model and the model. This ensures that transactions are appropriately monitored.

While this list is not exhaustive, it does shed some light as to what auditors and examiners are looking for when it comes to model performance. Addressing these issues prior to a model validation or examination can help the process go more smoothly.

In Conclusion

BSA/AML model validations are essential for both financial institutions and regulatory bodies to ensure that AML models are working as intended and regulatory requirements are being met. Young & Associates performs customized BSA/AML Validations and Reviews and collaborates with many of the AML software providers throughout the validation and review to provide a seamless process for our clients. If you would like more information on this article, or on how we can assist your organization, please contact me at epugh@younginc.com or 330.422.3475.

By: Brian Kienzle, CISSP, OSCP and Mike Detrow, CISSP

As we discuss technical testing techniques with financial institutions, we still see a lot of confusion about the difference between a vulnerability scan and a penetration test (pen test). In the past, and even nowadays, these two terms are sometimes used interchangeably. However, a true pen test is quite different from a simple vulnerability scan.

A vulnerability scan is an assessment performed by running a scanning application like Nessus or Qualys. With these applications, the assessor inputs the target IP address ranges or DNS names, clicks scan, and then waits for the results. Scans are important tools for detecting and mitigating several types of vulnerabilities; however, they are limited, since they generally rely on fingerprints of known vulnerabilities.

A pen test, on the other hand, can be thought of as a highly technical audit. A pen tester will use a wide variety of techniques and tools, often including vulnerability scanners, to discover and exploit vulnerabilities. The tools that are used will be different depending on what network services and device types are encountered.

One of the biggest differences between a scan and a pen test is that a pen test will exploit vulnerabilities. This minimizes false positives and lets you know exactly what a vulnerability’s real impact is in your unique environment.

Are vulnerability scans worthless? No, but it is important to understand their strengths and weaknesses. Scanning software cannot think; it can only discover what it has been programmed to discover. It is valuable for finding low-hanging fruit, but its inherent design limitations prevent it from detecting certain vulnerabilities, such as vulnerabilities requiring custom exploitation, fuzzing, or guided brute-force attacks. Discovery and exploitation of these vulnerabilities requires investigation by an experienced security professional.

How do you tell which one you’re getting?

It takes a hacker to know how a hacker will try to exploit the devices on your network. Unlike vulnerability scans, pen tests require a lot of time and expertise. These are not perfect indicators, but can be helpful in determining what type of service is being performed:

• The proposal should give some detail about the overall penetration testing. True penetration testing by its nature is somewhat open-ended but should always involve manual investigation and exploitation of any discovered vulnerabilities.
• Engagement price can be an indicator. If the cost of your penetration test is very low, that could mean the pen test is simply a vulnerability scan. It would not make business sense to sell such a skill and time-intensive engagement so cheaply.
• If the findings do not include step-by-step instructions to exploit the specific vulnerability, that could be an indicator that the findings are automatically generated.
• Hackers and penetration testers are often self-taught, so certifications may not be strictly necessary. However, if this is an area of consideration, more weight should be given to certifications whose exam processes are practical exploitation tests, rather than multiple-choice exams. Certifications like this include Offensive Security Certified Professional (OSCP) and Licensed Penetration Tester (LPT).

When should you get a pen test or vulnerability scan?

Vulnerability scans and pen tests are different types of tools and therefore should be applied in different situations. Because of the lower cost and time restraints of vulnerability scans, they should be conducted more frequently. Regular vulnerability scans help to identify vulnerabilities in a timely manner, which allows IT staff to limit the time that these vulnerabilities remain exploitable on the network by remediating the vulnerabilities soon after they are discovered.

Vulnerability scans can even be performed by financial institution staff or by the financial institution’s Managed Service Provider (MSP). This is typically more cost-effective than hiring an independent party to perform frequent scans. However, it is still important to have an independent party perform an annual vulnerability scan to verify that the financial institution’s vulnerability management processes are effective.

Pen test frequency will typically vary based on a financial institution’s network infrastructure and vulnerability management practices. While external pen tests may commonly be performed annually, a financial institution may choose to perform internal pen tests annually, biennially, or even less frequently. Management should use a risk-based approach to determine the frequency of pen tests by considering the following factors:

• Significance of data stored on internal systems
• Frequency of network infrastructure changes
• Complexity of network infrastructure or network operating system
• Any network services or applications developed in-house, such as intranet sites
• Demand from examiners

If you have any questions about the differences between vulnerability scans and pen tests, or you would like to get more information about the testing services that Young & Associates has to offer, please contact Mike Detrow, Director of IT, at mdetrow@younginc.com or 330.422.3447. We look forward to helping you maximize the return on your technology investments.