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.
Ian Muscat, Product Communications Manager, Acunetix
Ian Muscat is the product communicationsย manager at Acunetix. He works closelyย with the product team, contributing toย research efforts and published material.ย He has previously been part of Acunetixโย Technical Support and Quality Assuranceย Teams, supporting various Fortune 500ย companies and government organisationsย internationally.
Muscat was part of severalย scoping interactions around the implementationย of web application security tools intoย the SDLC. He is a frequent author onย Acunetixโ web application security blog andย is particularly interested in the emergingย global web application security climate andย new web technologies.
Comments are closed.