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.
This is particularly important for B2B software companies where proving the strength of your software security measures is the only way to get past the customer's internal security teams.
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 - especially those that don't have in-house security teams. 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 operations 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 software providers, you'll quickly realise that you've found the illuminated runway that leads to your SaaS growth and sales goals.
What are the types of application security controls?
Web application security controls are the building blocks for creating a secure web application. They are measures that are tested with security audits and are essentially security measures that protect your app's users from falling victim to sensitive data loss.
The best part is that you can implement these application security controls even if you don't have internal security teams or if your application security program is still in its infancy.
A secure application system is one that has most, if not all, of the necessary types of application security controls in place to protect the confidentiality, integrity and availability of the web application and its sensitive data.
Such applications not only employe web application firewalls for network security, but also conduct regular security testing, including a manual penetration test as well as automated security audits to protect and verify their security standards.
Remember, the top SaaS companies use best practice security features throughout the software development lifecycle.
Contrary to what you might have heard, modern application security controls require you to invest in a combination of tools, best practices, training and security tests that can sometimes be performed in-house, but are generally conducted by experienced penetration testers to uncover security vulnerabilities.
Are application security controls different for software hosted on-premise vs in the cloud?
Not really. A cloud server, like an AWS EC2 instance, is still a server. The only difference is that it is sitting in AWS' datacentres, rather than in your office.
Everything that you read here is relevant to you whether you host your own web applications or use a cloud platform like AWS, Azure or GCP.
Just be aware (as you'll read below) that hosting your application on the cloud doesn't absovle you of the responsibility to protect your infrastucture!
How to secure web applications?
The most common answer you might hear is that all you need to do to secure a web app is to get a web application penetration test done.
Some more knowledgeable people might also advise you to invest in cybersecurity training for your development team. Frankly, when combined, these are reasonable suggestions.
But in this day and age where your team is shipping new versions of your app on an almost daily basis, these two things alone are simply not enough.
There is no finish line in application security. You need to keep running & do as many miles as your time & budget will allow you.
Web application security testing is one piece of the puzzle that is your overall application security posture. Application security testing is a big part of that puzzle, but it's only useful when it's performed within 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 engaging a vendor to conduct an annual penetration testing service 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 web application penetration test should be:
- Preceded by meaningful web application security testing during the design phase (share this web application security best practices PDF 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 web app vulnerability testing of your code base to check for compromised code.
- Supported by regular static code scanning of your entire code-base, every commit.
- Fortified by authenticated automated vulnerability assessments of our web app and its infrastructure before you go live.
- Corroborated with regular application security testing.
- Reinforced with regular drills (ie. cybersecurity training) to help your team understand what they need to do in the event of an attack.
Four of the five steps above can be easily implemented by talking to a pentesting-as-a-service solution provider. Because PTaaS is literally a turnkey way to help you implement the structure above.
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 and they look after my application security measures
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 massive cloud hosting platforms typically offer protections against large-scale DDOS attacks. And. That's. About. All.
The flexibility and sheer range of services offered by cloud platforms like AWS and GCP and Azure present their own unique security challenges. Securing them is a very different exercise to securing your web application or mobile application.
This is why we offer a cloud platform cybersecurity testing services that allow you to implement the right cloud security control in the right place.
There are over 200 security controls that we look for but the most common ones include:
- Configuring IAM settings in the most secure way.
- Configuring secure communications between various servies that you're using.
- Setting up automated alerts and monitoring to understand when there's an issue.
- Creating end-to-end encryption of your services and pipelines to secure your code and data.
- Setting up self-remediation where possible.
Such best practices are almost useless if your developers often open random ports into your environments. Or if they don’t close SQL injection security 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. Or if data encryption controls are improperly configured. Or if...you get my drift, right?
These softare vulnerabilities leave you and your web applications wide open to a myriad of attack vectors. Only a deliberate and methodical application security structure that includes security measures like those described above will help your software developers find and fix these security vulnerabilities before it’s too late.
What application software security basics should I implement?
Contrary to popular belief, application security or SaaS security does not have to be an expensive, time-consuming and an anxiety-inducing exercise.
The good news for you is that simply implementing the basics of application security will also set you on the path to follow web application security best practices.
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.
There are really only seven security-focused HTTP headers that your application developers need to configure. Here’s a quick rundown of what the seven HTTP security headers that your application needs:
- X-Frame-Options - helps you combat clickjacking attacks by controlling whether browsers can render your web app in frames, thereby protecting authorized users from having their login credentials stolen. Think of this as an extended form of access controls.
- Strict-Transport-Security - HSTS strengthens your app’s ability to enforce TLS encryption of all 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) security 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.
How I can check my HTTP security headers?
You want easy AND quick? You're in luck!
The easiest and quickest way to check how many of these seven HTTP headers your application system uses adequately is by using the CyberChief.ai HTTP header scanner 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.
Are you planning on stopping at HTTP headers as your only application security controls?
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 application and APIs over HTTPS and ensuring that all HTTP traffic is automatically redirected to the more secure HTTPS protocol.
There are usually 0 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 cloud software 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 faster.
Download our application security controls checklist to understand the minimum security controls your SaaS business needs. Alongside baselining your application controls with thorough application security testing, it could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.
It probably will also help you land your next (or first) big enterprise customer for your SaaS, especially if yours is a business application.
Are there additional best practice application security controls suggested by OWASP?
OWASP indeed has a very rigorous list of best practice application security controls, you can access them here.
TL;DR, OWASP's list includes specific application security controls as well as 11 more general application security best practices like these:
- Patch your systems regularly
- Implement a Web Application Firewall (WAF)
- Use an automated web app security testing tool to look for security weaknesses during the application development phase
- Perform input validation on all inputs
- Sanitize the output of error messages
- Separate non-production environments from production environments
- Perform manual and automated application code analysis (see below about SAST tools)
- Verify vendor security processes throughout the application lifecycle
- Secure your databases with adequate security hardening
- Train developers on writing secure code by giving them on-the-job application security coaching
- Remove software development artifacts from production application code
OWASP is undoubdtedly a great source to level up your coding practices to minimise security threats and protect sensitive data.
We can't do everything at once, but we can do something at once.
However, keep in mind that it's not always possible to implement every OWASP application security control and the myriad others that you will hear about, like:
- Multi-factor authentication
- Salting and hashing
- CORS protections
- Access control hardening
- Application source code sanitization
- Etc, etc, etc...
Your biggest conundrum is that the security control you choose not to implemement might be the one that causes the application layer data breach you wanted to prevent!
That's why my tean gives you application security discovery calls, because they can help you understand the different trade-offs you might need to make and how to stay secure despite not being able to protect against every attack vector.
You will leave this call with a clear understanding of:
- Which best practices your currrent application security structure is missing;
- Whether you're adequately protecting your users' senstive data;
- How to help your developers find and fix security threats without losing productivity;
- The security tools will help you minimise security risks and how you can integrate them into your validity checks and completeness checks; and
- Security requirements of your target enterprise customers and how you can meet them.
How can I test my application security controls?
The DIY method of testing your application security controls is by using the best web application vulnerability assessment tools. These application security scanners are tools that can scan websites and applications and issue alerts when the application is vulnerable to a particular type of attack.
There are many types of security tools, which all work differently. So it's important to choose one that's right for your needs, especially if you don't have internal security teams.
The reason for this is that most tools are built for application security professionals. If you ask your developers to use those tools, you'll be wasting your money and their productivity, without reducing your security risks.
Instead you're better off investing developer-friendly online pentest tools that are custom-built for techies who have little or no security expertise, which, let's face it, is the majority of your development team.
Then you can supplement this with thorough application security testing.
The two types of application security tools that you must have are:
- Static code scanning (SAST): static scanners integrate with your GIT repository and scan your codebase line-by-line to see if known vulnerable code eixsts.
- DAST scanning (Dynamic Application Security Testing): automated penetration tools for web apps like Cyber Chief look at your application after it's been compiled to find application vulnerabilities like cross site scripting (XSS), remote code injection vulenrabilities, access control vulnerabilities, inpult validation vulnerabilities, session management problems, SQL injection and other nasty OWASP Top 10 vulnerabilities.
The second non-DIY way of validating your application security controls is by asking an application security testing firm to perform an application software security penetration test.
An application penetration test is where you let a team of highly trained and certified penetration testers go to work for you. Previous experience working in-house for your industry will enable them to quickly move from scanning to assessing, and then to exploiting vulnerabilities so that they can validate the effectiveness of your app's security controls.
This type of security audit will help you assess the ways the app and backend systems are vulnerable to attack and how that can lead to a break in.
As you can see, software security today is not as easy as it once was. You need multiple layers of security features, each addressing different best practice areas of application security controls.
If you need to understand the right application security program that would work for your team, why not book a discovery call where my team can take you through the structure that's right for you?
