Not long ago security professionals were still focused on protecting their IT in a similar formation to mediaeval guards protecting a walled city – concentrating on making it as difficult as possible to get inside. Once past this perimeter though, access to what was within was endless. For financial services, this means access to everything from personal identifiable information (PII) including credit card numbers, names, social security information and more ‘marketable data’. Unfortunately, we have many examples of how this type of security doesn’t work, the castle gets stormed and the data isn’t protected. The most famous is still the Equifax incident, where a small breach has led to years of unhappy customers.
Thankfully the mindset has shifted spurred on by the proliferation of networks and applications across geographies, devices and cloud platforms. This has made the classic point to point security obsolete. The perimeter has changed, it is fluid, so reliance on a wall for protection also has to change.
Zero trust presents a new paradigm for cybersecurity. In this context, it is already assumed that the perimeter is breached,no users are trusted, and trust cannot be gained simply by physical or network location. Every user, device and connection must be continually verified and audited.
What might seem obvious, but begs repeating, with the amount of confidential customer and client data that financial institutions hold – not to mention the regulations – this should be an even bigger priority. The perceived value of this data also makes financial services organisations a primary target for data breaches.
But how do you create a zero trust environment?
Keeping the data secure
While ensuring that access to banking apps and online services is vital, it is actually the database that is the backend of these applications that is a key part of creating a zero trust environment. The database contains so much of an organisation’s sensitive, and regulated, information, as well as data that may not be sensitive but is critical to keeping the organisation running. This is why it is imperative that a database is ready and able to work in a zero trust environment.
As more databases are becoming cloud based services, a big part of this is ensuring that the database is secure by default, meaning it is secure out of the box. This takes some of the responsibility for security out of the hands of administrators because the highest levels of security are in place from the start, without requiring attention from users or administrators. To allow access, users and administrators must proactively make changes – nothing is automatically granted.
As more financial institutions embrace the cloud, this can get more complicated. The security responsibilities are divided between the clients’ own organisation, the cloud providers and the vendors of the cloud services being used. This is known as the shared responsibility model. This moves away from the classic model where IT owns hardening the servers and security, then needs to harden the software on top – say the version of the database software – and then needs to harden the actual application code. In this model, the hardware (CPU, network, storage) are solely in the realm of the cloud provider that provisions these systems. The service provider for a Data-as-a-Service model then delivers the database hardened to the client with a designated endpoint. Only then does the actual client team and their application developers and DevOps team come into play for the actual “solution”.
Security and resilience in the cloud are only possible when everyone is clear on their roles and responsibilities. Shared responsibility recognizes that cloud vendors ensure that their products are secure by default, while still available, but also that organisations take appropriate steps to continue to protect the data they keep in the cloud.
Authenticate Everyone
In banks and finance organisations, there is always lots of focus on customer authentication, making sure that accessing funds is as secure as possible. But it is also important to make sure that access to the database on the other end is secure. An IT organisation can use any number of methods to allow users to authenticate themselves to a database. Most often that includes a username and password, but given the increased need to maintain the privacy of confidential customer information by financial services organisations this should only be viewed as a base layer.
At the database layer, it is important to have transport layer security and SCRAM authentication which enables traffic from clients to the database to be authenticated and encrypted in transit.
Passwordless authentication is also something that should be considered – not just for customers, but internal teams as well. This can be done in multiple ways with the database, either auto-generated certificates that are needed to access the database or advanced options for organisations already using X.509 certificates and have a certificate management infrastructure.
Tracking is a key component
As a highly regulated industry, it is also important to monitor your zero trust environment to ensure that it remains in force and exompasses your database. The database should be able to log all actions or have functionality to apply filters to capture only specific events, users or roles.
Role-based auditing lets you log and report activities by specific roles, such as userAdmin or dbAdmin, coupled with any roles inherited by each user, rather than having to extract activity for each individual administrator. This approach makes it easier for organisations to enforce end-to-end operational control and maintain the insight necessary for compliance and reporting.
Next level encryption
With large amounts of valuable data, financial institutions also need to make sure that they are embracing encryption – in flight, at rest and even in use. Securing data with client-side field-level encryption allows you to move to managed services in the cloud with greater confidence. The database only works with encrypted fields and organisations control their own encryption keys, rather than having the database provider manage them. This additional layer of security enforces an even more fine-grained separation of duties between those who use the database and those who administer and manage it.
Also, as more data is being transmitted and stored in the cloud – some of which are highly sensitive workloads – additional technical options to control and limit access to confidential and regulated data is needed. However, this data still needs to be used. So ensuring that in-use data encryption is part of your zero trust solution is vital. This also enables organisations to confidently store sensitive data, meeting compliance requirements, while also enabling different parts of the business to gain access and insights from it.
Securing data is only going to continue to become more important for all organisations, but for those in financial services the stakes can be even higher. Leaving the perimeter mentality to the history books and moving towards zero trust – especially as cloud and as-a-service infrastructure permeates the industry – is the only way to protect such valuable data.
