Cloud-based security scanning

Vulnerability management (VM) has evolved over many years as a way of identifying and responding to the software and security configuration flaws used by cybercriminals to compromise enterprise systems.Traditionally these have been on the firewall side of networks, but in recent times the focus has shifted to public-facing web and cloud applications, which are becoming repositories for large volumes of vulnerable data.

Tweet

A recent report estimated that 41% of enterprise workloads now run in some form of public or private cloud, a figure that will rise to 60 percent by 2018. A growing proportion of this sits inside public Software-as-a-Service (SaaS) providers managed through what Gartner has termed cloud access service brokers (CASBs). This middle layer offers the ability to impose cloud security policies (encryption), visibility (integrating with SIEM), threat prevention (spotting anomalies) and compliance (reporting).

Traditional VM has inherent limitations when pitted against the world of web and cloud applications, primarily that it assumes that attackers are targeting conventional resources protected by security layers such as IDS and firewalls. VM scanning is also intermittent in nature, no longer a security model that is up to the task of protecting public-facing applications. It is to solve these problems that cloud-based vulnerability assessment has been pitched as a new layer of security service.

Although what these services do is complex below the surface, they are usually designed to be incredibly simple to use, offering the view of an application perimeter that an attacker sees. In their simplest format, the admin simply logs into the service and specifies applications and IP addresses with the VM assessment service automating other parameters. They can also be deployed in a multi-tenant mode that gives managed service providers (MSPs) the ability to offer cloud vulnerability scanning within a broader suite of services.

Additionally, where these services are part of an internal VM platform, they can be managed using the same security policies applied to those systems. The objective of this integrated approach is to avoid cloud-based vulnerability assessment becoming a ‘special case’ that has to be secured through a parallel management system in ways that increase costs and the risk of security oversights.

A related development are platform-specific cloud scanning services such as Amazon’s Inspector for AWS. The issues that arise here include the fact that such services are, by their nature, specific to one cloud platform. Second, they don’t (so far) fix issues, simply give customers a heads-up on their existence in return for a subscription fee. What Inspector offers for most cloud customers is an automated way of identifying issues as they deploy applications from the devteam.

Another often-cited platform tool is Google’s Cloud Security scanner for developers using the company’s Platform-as-a-service (PaaS) app engine development system. This is primarily a tool intended for developers rather than security teams but does remind us that cloud scanning is becoming a commodity service at a number of different levels.

Scanning and analysis

The job of cloud-based scanning systems is to find and interrogate ‘assets’ (including systems running in the cloud that might not be known about) for vulnerabilities such as cross-site scripting flaws (CSS), Cross-Site Request Forgery (CSRF), SQL injection and path traversal, all major routes for external attackers to compromise applications. The industry-standard list of vulnerabilities affecting web application is the OSWASP Top 10, last updated in 2013 but due to be updated in 2016.

They may also offer the detection of malware injection into valid cloud services, insecure APIs, and in a few cases straightforward abuse of cloud systems to man-in-the-cloud attacks targetting public services.

Important features of cloud scanning are varied but include:

• The ability to log-in using third-party authentication services such as Microsoft Live services avoids which the creation of separate credentials for any users allowed to use the scanner

• Ideally, scanning should be automated and not require additional scripting

• Subscription might or might not limit the number of IPs included in a scan at a given price (web applications will usually be priced individually)

• Scanning should be scheduled as well as ad-hoc

• HTML5 interfaces allow scans to be accessed on any browser and device supporting this standard

• The ability to group assets for ease of scheduled scanning

Reporting

The end result of a scan are reports that come in a number of types starting with vulnerability assessment. This will provide information on what was scanned, which flaws were found by type and some pointers to remediation. This process can never be perfect and some false positives are inevitable so the depth of explanation offered is always a critical resource

This scan will usually score the flaw according to the Common Vulnerability Scoring System (CVSS) as well as mention whether an exploit is present in a common pen-testing platforms such as open source Metasploit Framework or Core Impact. The fact that they are mentioned in these tools is important because it offers a pointer to which flaws to fix first.

A second layer of reporting is compliance which will be tailored to regimes including PCI-DSS, SOX, and HIPAA, in a native reporting format where appropriate. This will note the effect a discovered vulnerability will have on each of these regimes. The final level is to replicate this procedure for off-the-shelf or custom web application reporting.

Again, reporting functions from cloud-based scanning engines can in some cases integrate with on-premise VM systems to provide a full view of an organisation’s compliance.

Conclusion

There is no doubt that cloud-based scanning looks like a compelling technology not least because it understands applications from the ‘outside’ in the same way an attacker would. It does have weaknesses and is not a panacea.

It doesn’t on its own provide remediation for the flaws that are uncovered, which is one reason why it is best used when integrated into a larger vulnerability management system that does – simply spotting the flaws doesn’t explain how they will be fixed and on what timescale. This is also important for compliance and reporting, which is best done across an entire organisation.