March 26, 2019

Security in the Public Cloud

Serverless cloud deployments change your security risks in ways that are different from VPC deploymments

Security in the Public Cloud

Security in the Public Cloud

This article is the first of what I hope will be a series covering aspects of security issues when using services offered by public cloud providers. My focus will be on Amazon Web Services (AWS) but the principles, if not the specifics, will apply to other cloud service providers. The purpose of this report is to inform users, or potential users, of cloud services of the new risk paradigm that they need to be aware of. It is commonly said that the public cloud reduces security risks but this report will argue that it does not necessarily diminish the risk but changes the risk in significant ways.

Andy Jassy CEO AWS
“Most people come away feeling like their security posture improves when they’re in AWS versus when they’re on-premises,” Jassy said. “If you’re a CIO, you have all these servers that you’ve distributed over many years —you don’t know where they all are. You don’t know what things are running under people’s desks.”

Security is everyone’s job

Internet security failures have the capacity to turn an unknown or a well-known business into a news headline for all the wrong reasons.
When an attacker wins once he wins
When a defender loses once he loses, a defender has to win every time to win. The mantra that prevention is better than a cure is never more apposite when it comes to cloud security.

So how to defend all the time? – create a defensive aware mindset and that is our first objective in this series

A Cautionary Tale ……

The following tale is complete fiction and so, technical impossibility or error aside, the purpose in telling the tale is to create a certain fear as in respect for the power that the cloud brings in order that some fundamental lessons be rigorously applied.
Nor is it meant to imply that overseas hires or new staff represent greater risk than any other class of employee.

Let the tale begin …

A business was undergoing transformation with new markets, new products and a new marketing strategy. As a result there was a need to rapidly move the business off premises and to the cloud in order to scale to meet increased demand. A number of new people were hired to implement this as quickly as possible.
The new devops technical lead, for easy future reference we will designate him X, was well qualified academically and experienced and was keen to understand the business needs and application processes. The migration to the cloud and rollout of the apps went well.
The great advantage was that X was able to use deployment scripts that the rest of the devops team were unfamiliar with and work quickly and efficiently.
A month or so later the ICT Manager was looking at the EC2 Usage Report and noted that costs were above budget by a big margin. He looked at the deployment region dashboard to see how many EC2 instances were running and spotted no anomaly there. As he was required at a meeting he resolved to look at the issue later.
Unfortunately, the over budget costing slipped his mind. No one else seemed to have noticed so it was another few weeks before he revisited the EC2 Usage Report and saw that costs were running consistently at elevated levels i.e. well over budget.
He looked at the regions again where the system had been deployed and could not see anything amiss.
A couple of days later he happened to be talking to the head of accounts payable who mentioned he had just seen the monthly cloud services invoice and was curious why it was running well above budget.
Later that day the ICT Manager talked with X and asked if he had any thoughts on the unexpected usage levels. X explained that DevOps had been running a number of stress tests, penetration tests and simulated DDoS attacks and tests on autoscaling response times and load balancing failovers so that may be an explanation.
A couple of days later HR received an email from X to say that he was out of the country as his mother had suddenly been taken to hospital and he had gone to arrange her care.
A week later the offices were visited by several forensic police officers including two agents from overseas who specialised in cyber crime. Apparently the business cloud account had been identified as the source of a transfer of hundreds of millions of dollars of crypto currency from a crypto currency exchange to an unknown account.
Investigations eventually uncovered 30 C5n.18xlarge EC2 instances had been running for several weeks but now terminated at a cost of $3.88 per hour each giving the business a monthly bill of $83,808.
Apparently X had SysAdmin IAM permissions and used his own personal account to cross link to the business account and create the 30 instances in the Sao Paolo region where no other business operations were conducted. As there were no CloudWatch billing alarms, logging had been directed to a S3 bucket with life cycle management to delete records after 30 days and as that bucket had now been deleted it was difficult to trace much.

The moral of the story is that there are all sorts of new risks to be encountered in the cloud.

  • Insiders are the biggest source of leaks, exploits and exposures both deliberately and unintentionally. Training and oversight, policies and procedures are essential. Data privacy case. This is an even more severe case
  • Cloud affects all areas of a business and all areas need to be aware of risk and share information between departments; even if it seems irrelevant to one department it could be a vital clue to someone else that something is amiss.
  • Use tags on every asset possible to identify the customer or application or project; identify the department or budgetary sector; identify who made the change – Employee ID.
  • Cross account access should be a special area of oversight and subject to policy and security restrictions
  • Cloudwatch Cost Alarms should be used to notify whenever an unexpected use is occurring.
  • IAM policies, roles, security groups, access control lists (ACLs) should be as restrictive as required to give the least privileges to perform the job.
  • Use of regions should be subject to policy to avoid hidden assets
  • Logging should be centralised with functional dashboards, reports and so on that are available to a wide group of management to ensure high visibility of usage, cost, errors and other operational matters. Third party vendors are definitely worth considering such as DataDog, Splunk and so on.