Enterprises almost always have users, accounts or processes that run critical business operations to enable smooth operations and ensure productivity. Often, there is a lot of emphasis placed on security, availability and integrity. Regardless of the checks and balances, systems are not infallible. Sometimes this is done because it is perceived to be secured trusted operations, and sometimes it’s based on a planned calculated risk management.
In a 1995 film called Under Siege 2: Dark Territory, Penn said “assumption is the mother of all f ups.”
By now, all of us should have learned: One should not assume. This is partially why regulations requires accountability in the first place.
On the surface, these systems may be complex but have well developed processes around implementation. But as you dig deeper, it gets more complex. The organization’s environments are built from basic accounts such as users and endpoints. User accounts can be human or programmatic and endpoints can be a server or a workstation. And then within each of these categories there are subcategories such as the type of servers, sensitivity and more.
These are service accounts or user accounts that are used to operate business processes, however they are not accountable because they are not directly tied to a specific human account.
SWIFT is a concrete example. SWIFT is the ubiquitous messaging and communication framework for financial institutions (formally known as Society for Worldwide Interbank Financial Telecommunications) that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment.
SWIFT processes over 25 million transactions per day between its 11,000 banks and financial institutions worldwide. The secure communication channels enable member institutions to communicate securely, exchanging standardised financial messages in a reliable way, thereby facilitating global and local financial flows. As such, it has always been the target of well organized hackers looking to breach its controls.
By now, most of us have heard about how the SWIFT network was used to perpetuate cyber fraud. Hackers compromised a Bangladesh bank and manipulated its SWIFT account using malware to transfer $81M. Since then, more SWIFT hacks have taken place and affected institutions names were not always published.
It goes without saying that a UEBA solution needs to provide classification that is based on traffic and other dynamic factors and not only on static data such as Active Directory (AD) metadata or logs. However, smart as this may be, this is not what I would like to discuss in this post. The point, beyond this essential visibility, is that there are elements in the network which are crucial for normal operation, and they need attention.
At Preempt we understand that. And hence we provide features that helps our customers make processes accountable. Since SWIFT has been a use case we’ve discussed with many of our customers, I thought I’d share a bit more into how UEBA with Adaptive Response capabilities, like in the Preempt Behavioral Firewall, can be used in these types of scenarios and provide an example of how our customers can secure their SWIFT transactions.
To protect service or user accounts for operating business processes that are not tied to a specific human user, an account can be assigned to an authorizer who is a human that is required to approve activities. For example in the case of SWIFT, a human is required to authorize a money transfer via Multi-Factor Authentication (MFA).
Here is a real life example from one of our financial customers that has an internal security procedure to protect SWIFT accounts.
At a high level this is what it looks like
- Account must be traceable
- Do not allow transactions after business hours
- Enforce MFA on interactive user account activiy
Now lets dive in a bit deeper into how it works.
First : the accountability requirement is covered by using an authorizer on the account.
Second: Preempt identifies anomalies in the account behavior such as working hours, unusual use of source endpoint and much more which means it identifies account take overs using attack vectors that are not known. Preempt augments this with additional dimensions and tracks a variety methodologies of known attack vectors and prevents them, such as Pass the Hash, Pass the ticket and other known attacks.
Third: the granular policy allows the security administrator to define whether they want to enforce this authorization to a specific activity, such as authentication or access request or maybe to any activity, triggered by the account being guarded by the authoritative human.
It even goes beyond that by allowing the administrator to set adaptive response to each of these activities, for example use stricted identity verification with additional factor on logins and simple notification for additional network access.
This all blends well into the SWIFT’s standards recommendations to enforce 2 step verification.
“2-step verification is a security measure that helps protect your account from unauthorised access if someone manages to obtain your password. An additional layer of security requires a verification code to be entered along with your username and password.”
In summary, SWIFT is only one example. There are other cases where this UEBA and this methodology should also be applied. Other examples include privileged accounts, crucial processes and other important business operations.
Another very common use case would be remote 3rd party vendor access vendors accessing the network (Target breach anyone?). In this scenario a 3rd party consultant vendor requests access to a bank network. They get a one time password however the authorizer is then required to approve the access when it actually happens.
So, as you can see, the applications of this approach is wide. If you have a specific use case you’d like to discuss, feel free to contact us.