Strengthening community financial institutions. That's our mission at SHAZAM.
As manager of SHAZAM's risk consulting business, I have the unique opportunity to help institutions of all sizes fortify their defenses, with both information and physical security programs. We work with clients of all asset sizes, across the country and assist financial institutions with "all things risk." This may mean information technology audits, BSA and ACH audits, as well as network penetration testing, vulnerability assessments, and social engineering. In our work, we've noticed recurring findings that many institutions share. We strive to strengthen not only our clients' security, but the security of all financial community institutions. Addressing these common findings is a part of that process.
Information Technology Audit Programs
Access management. When conducting an IT audit, the majority of recurring findings are related to poor logical access management. This can include a wide variety of issues, but often focuses on poor control of Microsoft Active Directory. Many institutions have a high number of users with "domain administrator" privileges, don't restrict logon hours, allow nonexpiring passwords, haven't deleted unneeded or unused service accounts, or haven't removed terminated users from the system. Attackers look for these types of accounts. Digging deeper, we find that many institutions don't have a process for reviewing user access to wire platforms, core systems, internet banking or other systems. We hear the term "least privilege possible," which is a good security principle… but it's not being followed consistently. Review why administrator accounts are needed. Chances are they're being used for privileges that can actually be—and should be—assigned to user accounts.
Configuration standards. Industry best practices tell us to use configuration standards found in "hardening documents." These standards are usually provided by firewall, switch and IDS/IPS manufacturers and the documentation outlines how to secure each system effectively. Download a free (usually) copy from the manufacturer's website. Make it a priority to update system configurations based on these standards.
Inventory. Institutions failing to maintain current hardware or software inventories is another common issue. It's your stuff-know where it is! Institutions should maintain an inventory of their assets, including what operating system and version each is running. In addition, a software inventory should be maintained. If needed, find a tool that will do this for you; knowing what software is on the system is critical. By having a software inventory in place, unwanted programs or even malicious programs, can be more easily located and this process can lead to reductions in system latency. In our reviews, we often find that these inventories are out-of-date and vulnerable programs exist.
Track findings. Once an audit is complete, it's important that institutions track their findings, assign them to a specific person, or establish deadlines to correct the issues. While there are many tools available to help with audit tracking, a simple spreadsheet can be created listing the audit's origin, responsible person, risk or priority level, and a deadline for remediation. This process is important to the security of your networks and systems.
Many institutions fail to manage their overall exposure when they don't adequately assess, track, mitigate or accept risks. While they may adequately assess the risk through a risk assessment, they fail to fully mitigate risks for those items deemed higher risk. More threatening, however, is improperly lowering a risk score of a specific product or business line. Institutions do this to "accept" risk, yet lower risk items are easily forgotten. This simply isn't proper risk acceptance. Institutions should assess the risk of the product in question only after careful scrutiny. If there is a business need for the risk, move forward with an acceptance process that encompasses both senior management as well as the board of directors.
Security vulnerabilities are often found during network penetration tests or vulnerability analysis. The following items include text from the Common Vulnerabilities and Exposures (CVE) database, and from findings identified by Nessus, a vulnerability assessment solution used by SHAZAM Secure.
Security protocol. Most findings we identify are related to institutions still running transport layer security (TLS) protocol, version 1. This protocol uses cryptography to encrypt communication over a network using a symmetric key system. Originally, many governing bodies listed June 2016 as the deadline for depreciation of TLSv1, although it was eventually extended to 2018. Resolve this issue now by upgrading to TLSv1.1 or TLSv1.2.
SSL certificates. Many institutions have findings related to SSL certificates which can't be trusted. An SSL certificate verifies that the data being shared is from a trusted source. When the certificate is correctly installed on the institution's web server, a secure connection is established. A registered certificate authority issues these certificates to ensure authenticity.
Out-of-date certificates create vulnerability to man-in-the-middle attacks. These occur when an attacker secretly relays, and possibly alters, communication between two parties who believe they are directly communicating with each other. It's important to take these steps to make sure your certificates work to keep information safe:
- Confirm that the top of the certificate chain sent by the server is from a known public certificate authority. When the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing, the certificate may fail.
- Make sure the certificate chain contains a certificate that is valid at the time of the scan. If the scan occurs before one of the certificate's "Not Before" dates, or after one of the certificate's "Not After" dates, it can fail.
- Ensure that the certificate chain doesn't contain a signature that doesn't match the certificate's information, or it doesn't contain a signature that can't be verified. Bad signatures can be resolved by getting the certificate re-signed by its issuer.
Cipher strength. Medium strength ciphers are less than 112 bits (but more than 64) or using 3DES encryption. Using poor encryption makes your organization susceptible to attackers. The fix is to configure applications to use higher strength ciphers.
Internet Key Exchange (IKE). Essentially, IKE version 1 supports aggressive mode with pre-shared key (PSK) authentication. "Aggressive mode" refers to the nature of the encryption between the two entities taking part in the key exchange. Using aggressive mode means the identity of the two entities in the key exchange isn't encrypted. Using this type of authentication allows an attacker to crack the PSK of a virtual private network (VPN) gateway. The easiest fix is to upgrade to IKE v2 as IKE v2 doesn't allow aggressive mode. If upgrading isn't an option, IKE v1 allows for "main mode," which encrypts the identity of the entities involved in the key sharing. If none of these are an option, use very strong keys.
Protect Your Institution
Cybersecurity and IT risks present some of the scariest challenges to financial institutions. To compound the problem, a recent IBM study conducted by the Ponemon Institute, an independent research firm, found the average amount of time from breach to discovery is 197 days. This means the attackers could be in your network for more than six months before you know it!
For the security of your institution and your accountholders, don't treat audits or security testing as a compliance "check the box." These risks should be analyzed with the same priority and level of concern as credit or liquidity risks.
Hayden manages SHAZAM's risk management services, helping member institutions mitigate their risks in information technology, cybersecurity, physical security and BSA/ACH compliance. SHAZAM is a WBA Gold Associate Member. Learn more at shazam.net and follow @SHAZAMNetwork.