Cloud Application security is seldom considered during the ideation phase of web application development – unless the development team has previously been hacked and survived to tell the tale. But it’s also true that it’s never too late to secure your cloud-based web app.
In fact, smart and fast-growing cloud software companies who outperform their peers usually share this common trait: they consistently grow sales and build their brand by turning their security standards into a key differentiator and selling point.
There are at least three things that these smart companies do to prove to their B2B customers that their web application is secure and can be trusted. How many of these three things do you offer your prospective customers?
Why is cloud application security important?
Great question. There are the most obvious and often quoted reasons for investing in robust application security standards and processes:
- It helps to protect your business.
- It helps to protect your customers’ business.
- It helps to minimise your costs when you do eventually get hacked.
- Prevention is always better than cure.
- As a professional, it’s your moral (and legal, in many countries) obligation to ensure that the solution you provide to your customers is as secure as possible.
However, you will most likely view this finding from an IBM Security study to be the most compelling data point when deciding if now is a good time to look at your web application’s security standards:
Doesn’t it then make complete sense to give your potential customers just what they’re looking for? Combine the above overarching statistic with these 10 cybersecurity questions that enterprise clients consider when evaluating cloud service providers, you’ll quickly realise that you’ve found the illuminated runway that leads to your cloud sales goals.
So, should I just get a web application penetration test done?
Penetration testing for web applications is one piece of the puzzle that is your overall application security posture. Pen testing is a big part of that puzzle, but it’s only useful when it’s performed with the right structure.
What do I mean? Consider this: when a nation’s armed forces are trying to rid a city of terrorists, they don’t just go in with the army, do they? They first call for drone surveillance, then the air force for targeted strikes, then advanced reconnaissance units are sent it, followed by heavy infantry and more soldiers. All of this is then supported by engineers and civilian support to rebuild that city.
Simply conducting an annual penetration test on your cloud application and nothing else is like sending battalions into a war zone without any idea of where the enemy is hiding. By conducting penetration tests alone, you will be wasting your money and diminishing your ROI.
A penetration test should be:
- Preceded by meaningful cybersecurity assessments during the design phase (share this checklist with your development team to help them understand the security mechanisms that they should build into new and existing features in your cloud application).
- Backed by automated scans of your code base to check for compromised code.
- Fortified by (at least black box) vulnerability assessments of our web app and its infrastructure before you go live.
- Reinforced with regular drills to help your team understand what they need to do in the event of an attack.
Watch this training video to understand how you can put this type of application security structure in place and learn about the benefits it could bring for you.
I’m not telling you cybersecurity is easy. I’m telling you that it is doable. I’m telling you that the first step is the hardest. Your team is unlikely to take the first step until you lead the way by showing them what to do.
But my web app is hosted on AWS/Azure/Google Cloud
You’re not completely wrong, because to an extent these hosting platforms do provide a level of security. But it’s a very minimal security layer that they offer (unless you have the budget to pay for their really effective security offerings).
These hosting platforms typically offer protections against large-scale DDOS attacks and the like. Such protections are almost useless if your developers often open random ports into your environments. Or if they don’t close SQL injection vulnerabilities that allows an attacker to download your entire database without any valid login credentials. Or if they forget to apply security patches for the open source libraries that your cloud application uses.
The vulnerabilities leave you and your application wide open to a myriad of attack vectors. Only a deliberate and methodical cybersecurity structure like the one described above will help your developers find and fix these security vulnerabilities before it’s too late.
First step in enhancing cloud application’s security
Contrary to popular belief, application security does not have to be an expensive, time-consuming and anxiety-inducing exercise. In fact, properly configuring your web app’s first line of defence against attackers should be a reasonably quick exercise for most competent developers.
The first step to making it difficult for hackers to hack your web app or exploit it for other nefarious motives, is to configure 7 security-focused HTTP headers. These HTTP headers tell the browser how users can interact with your application and infrastructure.
More, importantly, these security headers instruct browsers about what users SHOULD not be able to do when loading and interacting with your application.
The good news is that there are really only seven security-focused HTTP headers that your developers need to configure. Here’s a quick rundown of what the seven HTTP security headers that your web application needs:
- X-Frame-Options – helps you combat clickjacking attacks by controlling whether browsers can render your web app in frames.
- Strict-Transport-Security – strengthens your app’s ability to enforce TLS encryption of data in transit by forcing the use of the secure HTTPS protocol.
- X-Content-Type-Options – helps to counter MIME Confusion attacks and unauthorised hotlinking attacks.
- Feature-Policy – allows you to selectively enable, disable, and modify the behaviour of APIs and features in the browser.
- Set-Cookie – implementing the right directives makes it difficult for hackers to exploit cross-site scripting (XSS) vulnerabilities and hijack the authenticated user sessions.
- Referrer-Policy – helps you control if and how much information your application submits to external websites that your users are clicking through to.
- Content-Security-Policy – allows you to explicitly define the sources from which a browser can load components when rendering your application. It supersedes previously recommended headers like X-WebKit-CSP and X-Content-Security-Policy.
The easiest and quickest way to check how many of these seven HTTP headers your web application uses adequately is by using the CyberChief.co free HTTP header analysis service. Simply enter your web app’s login page and in less than 2 seconds you will be will have a complete analysis of the HTTP headers that are already configured properly, and those that need more work.
The best part is that Cyber Chief’s recommendations spell out in detail where your developers can configure these HTTP headers in your application. It will also explain what directives and keywords should be used maximise the security that each HTTP header can offer.
At this stage, it would be remiss of me to not point out that this header optimisation process is pointless unless you are serving your web application over HTTPS and ensuring that all HTTP traffic is automatically redirected to the more secure HTTPS protocol.
There are usually ZERO compelling reasons to pay hundreds or even thousands of dollars fancy SSL certificates from brand-name SSL certificate vendors. A free SSL certificate from services like LetsEncrypt or Cloudflare will be more than adequate for most cloud applications.
Remember that this HTTP header configuration process is only the first step in your journey to securing your web application and its infrastructure. The speed at which you’re able to build the remaining structure will determine a) how far ahead of attackers you can get, and b) how quickly you can turn your new cybersecurity resilience into a selling point to grow sales convert faster.
Download our Cheat Sheet For Building Unhackable Apps to understand the minimum security controls that SaaS applications must-have. It could just save your product and your company from much embarrassment and even the loss of you and your team’s livelihood.
Check out all the software testing webinars and eBooks here on EuroSTARHuddle.com
This blog post was originally posted here: https://www.audacix.com/2019/10/does-your-cloud-application-have-this-7.html
