We’ve all seen the little green bar on our web browsers and the padlock icon that tells us the site we are visiting is secure. Whilst this is a very useful and visual indicator that the website owners have adopted a verified and acceptable level of encryption certificate, it doesn’t tell us the whole story about the web application security and your personal data security.

Communication channels

Https websites and web applications encrypt the connection between your browser and the site. The communication channel is secure, meaning that the data transferred between the two is secure. When you log in, the username and password you enter is communicated over an encrypted channel. Any data ‘in transit’ between you and the site is protected by the encryption algorithm and its strength. The little green bar in your browser also indicates that the site owners have been verified, giving you assurance that they are who they say they are and, as they can unencrypt the data at their end, you know who will be seeing it.

Further layers of security

But what about security beyond an encrypted web front-end? What other layers of security should fintech providers be proficient with when offering software as a service to financial institutions? Https deals with data in transit over the internet between you and the web application, but what about the data that is moving about behind the scenes in the application itself? Most modern web applications have a secure front-end that is separated on a different part of the network from the processing and back-end databases. These back-end systems live in a protected network where the internet can’t reach them. During the normal operation of a web application, all these internal systems are talking to each other and transferring data back and forth. In many instances, this network and data is not encrypted. The old excuse for this was that it added network overhead and could slow the application down, or that it was overly complicated and unnecessary. These reasons are no longer valid. It’s a relatively straight forward task and modern encryption algorithms don’t add overhead that would impact application performance. It’s necessary because it would be very easy for internal attackers to capture this data and use it to exploit the system.

Another layer that should be employed in the cyber security battle is encrypting ‘data at rest’. This is the data within the back-end databases. It’s not moving between systems, it’s just being stored in a database ready to be processed, or its results that have been processed ready for reporting. Again, encrypting this data protects it from simple access from internal staff and it’s a simple process to implement with most modern database platforms.

Implementing these best practices is important in both private and public cloud environments. In public cloud environments the external cloud provider, such as Amazon, could, in theory gain access to systems if they were able to bypass account access and controls. By encrypting the back-end network and the databases, any rogue cloud provider employee would be thwarted and wouldn’t have access to any sensitive data.

Secure encryption keys

With all this encryption going on, one of the most important aspects to manage is the encryption keys themselves. Different key technology is used depending on what type of data you’re encrypting and if it is data in transit or data at rest. Therefore, you are likely to have multiple encryption keys within your environment. There is no point encrypting the data in a database and then storing the encryption key in the same place (you’d be surprised how many people actually do this). Having a strong and secure key management policy is essential in maintaining the overall security of your application and environment. There are various options available when it comes to securing your encryption keys. Actual physical devices called hardware security modules (HSM) can be used allowing you to securely store keys while still allowing authenticated servers access for encryption operations. Another best practice is encryption key lifecycle management. This means rotating and changing keys based on a policy. Ensuring keys are only used for a specified period of time, before being replaced. A bit like changing the lock and key on your front door every three months. You can also use third party escrow providers to backup and store old keys in archive in case they’re ever needed to rebuild data in the event of a disaster.

Controlling access to secure key stores is also an important element of data security. You need to have the ability to identify people from their user accounts and for all access to be audited. Another essential best practice is segregation of duties, something that can be hard in smaller organizations. Your database administrator and your key administrator should not be the same person. Critical security functions should be divided among different staff members to ensure no one individual has enough information or access to commit fraud or cause damage.

Conclusion

There are many other elements to web application security, way too many for this blog, but as you can see, going beyond simple https website encryption is essential if you’re serious about securing confidential data. When you’re working with fintech providers, make sure you understand how they maintain high levels of data security. It might all start with that little green bar in the browser, but there is much more beyond it.

{{cta(‘f01c9128-0435-4e5b-bdb6-6c16dbb17572’)}}