The people writing software for self-driving cars are having difficulties. Telling a car to stop at a red light is relatively easy, but recent articles have pointed out the difficulties of merging into fast moving traffic, dealing with roundabouts and updated roadwork. In IT security we experience some of the same issues – the basic decision making on unauthorised hackers or malware is straightforward, even if dealing with them is not. For cloud security, much of the decision-making is more complex – cloud services are rarely all good or all bad, so we need to look at traffic patterns from multiple angles to be able to decide if a particular request should be allowed.
There’s no doubt of the need to secure cloud. Recent figures from the McAfee Cloud and Risk Report show that every company has some cloud use, 21% of files in the cloud contain sensitive data, 48% of users share data via the cloud and while IT often believe the number of cloud services is below 100, the average number of different services in a company is over 1,500.
It’s easy to see why cloud has exploded, the apps are typically easy to use, the commercial terms are flexible and our own policies may actually force people to use the cloud. When I speak at events, I typically ask how many companies have a restriction on the size of attachment allowed via email, and more than 50% of the audience raises their hands. As email traffic is usually logged and often the first place that DLP is deployed, why do we have this policy? Typically, the answer is “we’ve always had it”. Does anyone think that users will stop sending large files because of this restriction? What happens is that the user either uses an approved cloud app to transfer the data or simply searches for a way to send it and finds a free cloud service – probably not logged, not with DLP and who knows where the data ultimately goes?
To properly address cloud security, we need to start from the beginning and get visibility into all the cloud services in use, the type and quantity of traffic being sent/received, the user actions and to be able to drill down into details of each. For example, which collaborators are working with your employees and the cloud-to-cloud traffic that is a growing part of the whole cloud ecosystem. This is, of course, required for SaaS, IaaS and PaaS.
Then, organisations need the ability to set policies from the simple (block known bad/high risk clouds) to the more complex (don’t allow unmanaged devices to download files, check user behavior for anomalies, stop sharing via the cloud to untrusted organisations and deploy the same sorts of security technologies in the cloud as on premises, such as DLP).
The difficulty we often come up against is helping organisations define their policies – this is the real hard work. IT security need to be able to discuss with other departments, such as governance, risk and compliance and with the users themselves what policies are appropriate to make sure that they organisation can have the right balance of rights and security.
To enable cloud securely, I always recommend the setting up of a cloud adoption team that is multi-functional, that looks at the needs and concerns of all stakeholders – allowing IT to enforce the policies agreed by the whole company.
From a technology point of view, IT security needs this list of capabilities to provide the visibility and controls required. With this set of tools, they can go into the cloud adoption team discussions with enough knowledge and capabilities to define a robust series of policies – allowing users to take all the advantages of the cloud while safeguarding the organisation’s confidential data.
- Quick accurate ability to define trusted and untrusted clouds
- Stats on cloud use – with live updates and alerts and policy enforcement on unusual traffic.
- Multiple enforcement points that work for all, such as travelling remote users.
- Enforcement technologies – UBA, access control, sharing/collaboration control
- The ability to intercept user requests and push to trusted clouds
This post was originally posted on the Skyhigh Networks blog