Imagine you’ve just built your dream home – a sprawling mansion decked out with all the amenities you’ve always dreamt of having. Tennis courts, fully-equipped kitchen with a stocked bar, in-house movie theatre, your own 24/7 Whataburger… the works! You excitedly drive up to your newly built-home – and discover the front door doesn’t lock. Hmm. It doesn’t even have a mechanism. In fact, NONE of the entrances or room doors in the entire house are lockable. Windows, either.

You can still move in and start enjoying the good life – but with no security in place, you may be in for a rude awakening when you come home from work one day to find the whole place cleaned out. All the tricked-out amenities mean little when you’ve lost everything else.

So it is with web application security. It’s easy to get distracted by the amazing and valuable development, components, and services that make your application tick – but if security ends up overlooked in favor of everything else, you may as well have moved into that fancy house with no locks.

Good news: Securing your web app doesn’t have to be difficult so long as you know the basics, and there are steps you can take to start improving your web app security this very minute. Below are 4 major rules to enforcing web app security and buying yourself some peace of mind:

1) Control User Access.

This is possibly the simplest and most straightforward of all app security rules, yet is easily and often forgotten. We need to know who has backend access to our application and what they’re able to do.

The “who” is as easy as a user audit. Identify where app admin user accounts live – IAM in AWS, AAD in Azure, traditional on-prem AD, etc – and make sure that each app admin account has a known, current, and legitimate purpose. Stale accounts are a major security hole and ripe for exploitation if left to languish with the proper offboarding steps – and should be disabled wherever possible.

The “what” is a matter of looking over user permissions. In a large enterprise development environment, there could potentially be hundreds of users accessing and manipulating backend resources – but do they all need to global admins? A common security mistake is to simply assign global-type admin permissions to anyone who needs backend access; rather, we should be assigning permissions based on the Principle of Least Privilege. Does a certain developer need only the rights to modify a few cloud components of an Azure application? Then they should be assigned rights which give them ONLY exactly what they need, and nothing more.

Finally, we need to make sure that user account access is properly protected – meaning that we need both a secure password policy in place and multifactor authentication wherever possible. Both need to be enforced by policy, so that we can truly know user accounts are properly secured at all times.

2) Use HTTPS encryption.

In order to keep our app users safe, we need to make sure that the data they send to our app remains completely protected from outside interception and intrusion. To achieve this, HTTPS encryption is an absolute MUST for all web-based applications. Without it, we expose sensitive user info like credit card or social security numbers, private health information, addresses with phone numbers, and more. How amenable will a user be to utilizing your app services in the future after you’ve had to alert them to a potential data compromise?

Furthermore, the major web browsers don’t like unencrypted websites (for good reason) and will usually throw warnings at users when they attempt to visit one – reflecting poorly on the business and deterring potential users. Nothing scares away users like their own computer warning them not to visit your application.

Need more info on HTTPS and how to make it happen? Look over this good primer from WebARX.

3) Configure a Web Application Firewall.

Think back to our house example. Let’s say you get door locks – a good start. But your fancy house is a major target – and if a cat burglar is fiddling with the locks on your back door, they’re already too close for comfort. How about we invest in a high fence around the entire property, staffed by a 24/7 security agency with continuous, vigilant control over who’s allowed to even enter the property? That’s more like it!

We can do the exact same thing with our web application by using a Web-Application Firewall (WAF) – a Layer-7 service that monitors and filters all HTTP traffic accessing your application. The WAF will defend your application from the most common types of cyberattacks seen on web platforms – like cross-site scripting, SQL injection, DDoS, and many more. Similar to the security guard service, the WAF establishes control over data ingress and plays a key role in protecting the front end of your service.

There are a wide array of WAF options depending on where your infrastructure is hosted – Amazon has the proprietary AWS WAF, for example. However, there are more commercially available options which can be reviewed in this article from Comparitech.

4) Utilize a Web Security Platform.

This final rule is broader than the preceding and involves technology still somewhat in its infancy – but no less vital. We can have all the above security measures in place, all properly configured and managed down to the finest detail – but none of that can protect us in the face of the right zero-day threat – meaning, something completely new and unfamiliar that takes advantage of hitherto unknown vulnerabilities in software and/or technology. If a malicious actor discovers – for example – a flaw in the software of your WAF which allows them disguise harmful traffic and access the sensitive interior of your application, how will we know until it’s too late?

This is where a Web Security Platform comes in. We need a tool which, similar to the WAF, will continuously monitor all aspects of the web application. Who is accessing the app? From where? With what behavior? Regarding what data? Does it fit any known patterns of malicious behaviour? Does it match behaviour being seen on other web platforms? This could go on for some time – but my point is that a well-configured Web Security Platform will answer those questions for you.

Some key components of a Web Security Platform include SIEM, EDR/MDR, OWASP, Threat Intelligence, integrations for third-party services used in the course of your app – and much, much more. Coming from an IT background with a strong focus on security, I can attest firsthand that these tools are becoming increasingly critical in the face of ever-metastasizing security threats – and cyberinsurers / compliance frameworks are increasingly requiring them.

There are a huge number of web security solutions with varying features meant for different use-cases – so it’s not easy to provide any single list overviewing solutions. This article from CyNet is a list of their most highly-rated EDR providers as a start – but choosing the right platform requires knowing what you need to protect and choosing a platform with the tools to adequately address the existing risks.

Don’t spend a single night in the house without locking doors. Call your locksmith – start looking at the above security measures for your application today if not already in place!

Categories: Cloud, Cybersecurity

Tags: App Development, Cybersecurity, EDR, MDR, Security, SIEM, Web Application