Cloud security is such a massive subject, usually focused on the security of the infrastructure itself. But what about securing the apps hosted and developed in the cloud? After all, the vast majority of modern apps are deployed in the cloud – and it’s a fast growing segment. For example, according to Cisco research, cloud apps will account for 90 per cent of total mobile data traffic globally by 2019.
[easy-tweet tweet=”#Cloud #security is such a massive subject, usually focused on the security of the infrastructure itself”]
Organisations are under intense and growing pressure to deliver web apps that satisfy global demand – from both customers and internal staff – and create differentiation and business advantage. This urgency means web application development can often leave certain aspects in second place, not least security. This problem is intensified when developing cloud-first applications, where changes are made multiple times each day, with the inherent danger of introducing security vulnerabilities way more frequently.
Our own Web Application Vulnerability report found that just under half of web apps contain a high-severity vulnerability, such as Cross-site Scripting (XSS), SQL Injection and Directory Traversal that could lead to data theft.
Types of apps commonly in the cloud
Clearly today’s enterprise IT focus is on moving to the cloud, but as millions have often been invested in their existing infrastructures it might be unrealistic to expect them to move everything to the cloud (although evidence shows movement in that direction). While web apps are arguably easier to move to the cloud, traditional thick client apps are also following suit.
Companies are offloading their security burden and getting more out of the cloud by putting their security infrastructure there. Rather than using a company’s own infrastructure, a plethora of cloud services such as Office 365 and Google Apps make it cheaper, more effective and more convenient. With cloud security, organisations want the same peace of mind they had from their on-premise security infrastructure. Using a modern cloud vulnerability scanner makes pushing security to the cloud easier – where a scan for web apps was previously run in-house, a cloud scanner doesn’t have to take account of physical machines; plus as there’s less resource implications, admins don’t need to worry about making sure everything is ready from the IT side prior to running the scan.
However, putting your sensitive data in the cloud can be a contentious issue – mainly of trust. So a mix of cloud/on-premise apps works for both SMEs and larger companies, the precise mix depending on resources allocated within the security team or IT team. Don’t forget, smaller businesses are still exposed to the same threats, they are just trying to find the most cost-effective security testing solution – and cloud security offers lower barriers to entry. Especially if they are a start-up with a cloud-first approach!
Where to start?
Large organisations can have thousands of web applications and web services to maintain –even for small businesses they can number over 100 – so where does the security team start? Remember it’s not just about identifying vulnerabilities, but it’s crucial to fix vulnerabilities based on how business critical the web application is. Key questions include: how severe is the vulnerability? Is it a business critical application? Is it an internal-only, or an Internet-facing web application?
The most effective way is to approach an application as an attacker would – from outside in. Scan each application individually using dynamic testing across a wide vulnerability assessment area.
A scanner will then produce a report based on the criticality of the app to your organisation. When dealing with hundreds of applications it’s often difficult to prioritise action, but clearly the first to fix should be the highly business critical apps. If it supports it, you will also receive a CVSS3 score which helps define the priority list further and is easy to add weightings to make it more appropriate to your business. Armed with this intelligence, an accurate action list can be built for the team to start working on.
Save money by identifying flaws before they reach production
Having a ‘let’s fix them later’ approach to vulnerabilities can be very costly and dangerous for organisations. With any vulnerability, the longer it remains in your design & build process, the more it costs to fix – the advice is clear, the earlier you start your security effort, the better.
A web application’s staging environment should be as close to production as possible, therefore it’s recommended to do security testing at this point. If a vulnerability is identified, it’s always easier/cheaper to fix here rather than when the vulnerability makes it into production. It’s also possible to run an automated scan on just a subset of the app, even prior to staging, in the development environment (e.g. by looking for XSS flaws in a new feature a developer created). Whether on-premise or cloud-native apps, the dev environment should be regularly checked for flaws using automated testing.
For some, automated scanning is more suited to a cloud model – where scanning web apps hosted in the cloud becomes easier, without the headache of installing or maintaining any software. Then later on, if all reasonable flaws have been fixed, a company can escalate their security efforts by manually pen-testing the application for logical/business logic security bugs.
[easy-tweet tweet=”In the race to get #cloud apps to market, #security must not be left behind”]
Test early & often
In the race to get cloud apps to market, security must not be left behind. Dealing with identified flaws – prioritised correctly – should be a critical part of your ongoing security cycle. Don’t forget… it’s always much more cost-effective for companies to test early and frequently.