For any SWIFT member, their SWIFT application is the perfect example of a high-value application. It enables the rapid transfer of financial messages, and is used to facilitate financial transfers themselves. It enables the connective tissue that knits together our international financial networks.
All of this means that a properly functioning SWIFT deployment is critical to the success of every SWIFT member. It also means that a compromised SWIFT application provides an incredibly alluring target to a hacker or malicious insider.
In my last post in this series, I discussed the rise of SWIFT-focused intrusions and the new SWIFT security controls designed to ensure that organizations are properly protecting this crown jewel. These controls are of course essential for any SWIFT member, as they must comply with them under the new security program.
Some compliance regimes quickly devolve to a box-checking exercise, with little linkage between required steps and increased security. SWIFT's controls, however, have lessons that every security team can benefit from. They map out several of the most critical components of any HVA security program.
To that end, I want to focus on three key lessons from the SWIFT controls. These lessons aren't just valuable for SWIFT members. They offer best practices for anyone looking to defend an HVA.
These are certainly not the only security steps you should consider, but if you're looking to step up your security around a particularly critical high value asset, make sure you've taken care of each of these steps first:
Eliminate non-essential software, and keep installed software fully patched
Defending a high value asset is all about controlling and reducing the attack surface that HVA presents. There are several ways to do this, but one is to limit the software that you install in that HVA. Every new piece of software offers new weaknesses that an intruder might be able to exploit; new vulnerabilities that need to be patched; new components that need to be kept up to date. The more software is installed in an HVA, the more risk that it your security team will miss a weak point. Several of the SWIFT controls address this challenge, requiring that only essential software be installed within the secure zone, that any software that is installed be "SWIFT certified," and that any software that is installed be regularly scanned for vulnerabilities and kept up to date.
These three requirements together make up essential advice:
- Only install essential software.
- Validate the security of any software you do choose to install.
- Keep it up to date and vulnerability free.
This advice can be much harder to follow than one might expect. The temptation to add one more piece of tooling – or to leave an old piece of tooling installed in case you need it again some day – is incredibly strong. Guarding against this is one of the simplest things you can do to make your life easier and reduce the attack surface you need to defend within your HVA.
Segment your HVA, as well as the core services that support your HVA
The other obvious way to reduce the attack surface of your high value asset is through segmentation. By closing unnecessary ports and shutting down unneeded processes, you reduce the number of gates into your secured environment that an intruder can exploit. This lets you focus your controls, making life more difficult for intruders and easier for you.
While this makes sense at a high level, SWIFT goes further, identifying at least three types of segmentation every HVA should have:
- First, and most obviously, you should isolate your HVA from the rest of your environment, permitting only essential communications in and out, and carefully monitoring those channels. This should include communications from the Internet itself – even update channels should be carefully monitored.
- Second, you should segment communications within your HVA. Externally connected services inside your HVA may be essential, but if you segregate them from your valuable data, even an intruder that accesses your HVA will still have to navigate inside your constrained environment. This puts them at a further disadvantage, and gives you an edge.
- Third, SWIFT requires that core services that support the HVA be segmented. This would require, for example, that Active Directory authentication for your HVA would be distinct and isolated from Active Directory authentication for your wider network. This is a valuable constraint that many security teams forget. Active Directory is one of the most common pivot points for intruders (it was leveraged in the 2014 Target breach, and the recent Petya ransomware uses Active Directory to help it spread), and is a common weak point in systems’ defenses. By isolating your HVA’s Active Directory, you rob intruders of one of their most common attack vectors.
- Segment traffic into, out of, and within your HVA.
- Limit Internet communications, and isolate any device that connects to the Internet.
- And segregate the core services that support your HVA from your general network core services.
Constrain user access to your HVA
Restricting the attack surface of your servers is critical, but it’s just as important to limit the attack surface of your users. In almost every case, an intruder must combine user access and system access together to exploit your system. Deny either one, and they will struggle. Deny them both, and they’ll be left out in the cold.SWIFT recommends several steps to limit your users' attack surface:
- First, reduce the number of users and administrators with access to your high value asset to only the necessary minimum.
- Second, reduce the access of the users and administrators that can access your HVA to only the components of the HVA that they need to access.
- Third, reduce local administrator access to the minimum as well.
By constraining these three dimensions, you drastically reduce the options of an intruder to secure credentials to your HVA, and also constrain malicious insiders, forcing them to seek the seek additional credentials (a risky move that can expose them) if they need broad access. Overall, you should constrain user access by reducing users, remote administrators, and local administrator accounts to the bare minimum, and limiting the privileges of those accounts that you do let in.