Johannesburg, 06 Apr 2017
Companies in industries from manufacturing to financial services to the public sector now trust cloud providers with their critical data.
The rapid growth of SaaS applications like Office 365 and Salesforce depended on trust. The floodgates of SaaS adoption did not open until IT security professionals became convinced that cloud providers could produce equivalent or better security compared to traditional software.
Still, challenges remain on the enterprise side; Gartner predicts 95% of cloud security incidents will be the customer's fault. Now, the second wave of cloud adoption is reaching its swell, with the edge around enterprises disappearing into IaaS services. Organisations need to update their approach to securing this new enterprise edge governed by the shared responsibility model.
Updating the shared responsibility model for IaaS
Cloud-first companies use SaaS tools for different functions: Office 365 for collaboration; WorkDay for HR; Salesforce for CRM. Every organisation also possesses anywhere from a handful to thousands of internally developed applications for employees, customers, and partners. Organisations are eliminating their data centres and moving these proprietary applications to infrastructure as a service cloud offerings en masse, leading to an IaaS growth rate double that of SaaS.
Even companies that have taken a proactive approach to SaaS security will need to reevaluate their capabilities when it comes to applications hosted on IaaS platforms. SaaS and IaaS platforms operate under different shared-responsibility models or the allocation of security capabilities between cloud provider and customer.
Many security vulnerabilities that SaaS providers address fall on the shoulders of the enterprise customer for applications hosted on IaaS services. Furthermore, the business pressure to move quickly means security teams may have little to no oversight on IaaS security; developer teams do not have extra resources to dedicate to updating security for existing on-premises applications slated to migrate to the cloud. Proprietary applications do not have dedicated security solutions like SaaS apps do, nor do they have APIs which integrate out of the box with security products.
While in the past, we have thought of start-ups and cloud service providers as the companies dealing with AWS, Azure, or Google Cloud Platform security, today the Fortune 2000 are contending with the challenges of securing apps in the cloud.
IaaS security threats come from both inside and outside the organisation. Hackers target corporate IaaS accounts to steal data or computing resources. This vector can be exploited through stealing credentials, gaining misplaced access keys, or leveraging misconfigured service settings. One researcher discovered over 10 000 AWS credentials on GitHub. Hacked accounts can be used to mine Bitcoin or hold companies for ransom, as in the worst-case scenario of hosting company Code Spaces.
Internally, a malicious employee with access to IaaS accounts can cause immense damage by stealing, altering, or deleting data on the platform. Human error and negligence can expose corporate data and resources to attackers. Healthcare company CareSet made a configuration error that resulted in hackers exploiting its Google Cloud Platform account to launch intrusion attacks against other targets. After a few days without remediation, Google temporarily shut down the company's account. Organisations cannot fall under the false assumption that IaaS environments are secure out of the box. In every case above, the cloud provider is powerless to address the customer's vulnerability.
IaaS security action plan
Keeping data safe in proprietary applications on IaaS platforms requires an extra step beyond SaaS security: protecting the computing environments themselves. Securing environments on AWS, Google Cloud Platform, Microsoft Azure, or other IaaS platforms begins with a configuration audit. Here are four categories of configurations critical to securing IaaS usage:
1. Authentication: Multifactor authentication is a necessary control for any application with sensitive corporate information, especially cloud applications exposed to the Internet. Companies should enable MFA for root accounts and IAM users to reduce the risk of account compromises. Heightened authentication can require a user to enter an additional login step before they commit an action like deleting an S3 bucket.
2. Unrestricted access: Unnecessarily exposing AWS environments increases the threat of various methods of attack, including denial of service (DOS), man-in-the-middle (MITM), SQL injections, and data loss. Checking for unrestricted access to AMIs, RDS instances, and EC2s can protect intellectual property, sensitive data, and prevent service outages.
3. Inactive accounts: Inactive and unused accounts pose an unnecessary risk to IaaS environments. Auditing and eliminating inactive accounts can prevent account compromise and misuse at little cost to productivity.
4. Security monitoring: One of the top fears of moving computing to the cloud is a loss of visibility and forensics. Turning on an audit trail like AWS's CloudTrail logging establishes a behaviour monitoring tool for active threats and forensic investigations. This is also a basic compliance requirement for any large company and can be a deal-breaker for moving an application to IaaS.
Of these four categories, security monitoring is the most complex and robust. Machine learning tools can be tuned to detect a range of behaviour indicative of a threat. APIs can enable monitoring based on session locations, excessive activity, or brute force logins. At first glance, moving applications to the cloud can appear to forfeit control. With a proactive, cloud-based security strategy, however, applications on IaaS can be just as, if not more, secure than their on-premises counterparts.
For more information, click here to download our eBook.
Share