In one of the articles in a series on perimeter security published on our blog, we looked at the data security challenges inherent to adopting new technologies — more specifically, how the process of migrating data and systems into a cloud environment makes more flexible the perimeter to be protected and, by extension, increases the need for controls.
Unfortunately, as the article points out, there are still companies that choose to migrate systems and routines into these environments not only seeking operational advantages but believing that they are, in themselves, also security solutions, which is far from true as demonstrated by a series of incidents in recent years.
In one of the most recent incident, sensitive information from over 100 million US and Canadian citizens (including payment, social security, and bank account numbers) was exposed in a Capital One company data leak. The data, accessed due to a firewall configuration failure, was stored on Amazon servers, which claims that their customers are responsible for their own applications. In its official statement, the company has stated: “The attacker gained access from the wrong configuration in a web application, not through the underlying infrastructure.”
The case is particularly illustrative of responsibility sharing issues, with regards to the security of cloud environments. The reality is that, regardless of the cloud service model you are hiring, the task of keeping data and systems protected is shared between the service provider and the contractor.
It should also be noted at the outset that keeping cloud data secure requires as much or more care and control than data stored on premises (even if these controls are facilitated and simplified in cloud environments).
This article is intended to show some of the key precautions to consider in the cloud migration journey.
Considerations when starting the migration journey
There are many reasons why a company migrates data and systems to cloud environments.
They range from scalability issues (the ability to quickly resize the environment to meet increased demand, for example), to financial visibility, i.e. the possibilities these environments offer with regard to expense control.
In fact, there are other points to consider in this migration journey that include, besides financial and scalability issues, ensuring service availability, reliability, business continuity (recovery and backup) and other security related topics.
In this regard, it is important to note, first, that most cloud services have a contract-defined shared responsibility model in which, broadly speaking, the provider is responsible for “the cloud” itself and all the structure required for its operation, such as management software (including, depending on hiring model, databases, and networking tools) and infrastructure. The company that hires the service (also depending on the hiring model) is responsible for what is “in the cloud”: customer data, operating systems, applications, identity and access management, among other things — in some models, like Software as a Service (SaaS), the customer is solely responsible for identity management and access control.
Best practices
As we have seen, vendors and customers have different responsibilities with regards to the security of the environment and data saved in the cloud; in addition, with a few variations, it is possible to identify most of these responsibilities, allowing to pinpoint some valuable best practices for cloud service migration, regardless of the service or vendor that is being hired. Here are some of them.
Manage access using a bastion account: Some services allow to manage data and tool access permissions through an intermediate account, which, at each login, requires the user to identify their role within the organization for access to be granted For example, a technician responsible for analyzing logs for a service should, prior to getting access to those logs, log in to the cloud service management system with a bastion account. He will then be required to choose one of several possible profiles according to his role in the company. If the choice is incorrect, it may generate an alert for the system administrator, who will follow the adequate procedure for that case. Depending on the service, it is possible to limit the number of incorrect retries, change profile names, or create different triggers to alert the administrator.
Use multiple authentication factors: All cloud services allow for the use of multiple authentication factors, adding an additional layer of security to accounts. Supported authentication types include virtual devices (applications that generate algorithm-based numeric codes), U2F security keys (hardware devices that, like virtual devices, generate algorithm-based numeric codes), among others. Using this security layer is strongly recommended, as well as giving preference to physical tokens.
Keep a close eye on the root account: Most services offer a root account, with full access permission to all service features. By its nature, this account needs to be under constant monitoring, and it should have a strong password, multiple authentication factors enabled, and strict usage.
Apply basic security recommendations: Among the tools offered by cloud services is a checklist of basic security actions that is available for free — other checks and recommendations are usually offered in bundled service packages. Their execution is recommended.
Correctly configure repository access management: Configuration of repositories where data will be saved is done manually, including its data access control (for example, defining which users will have access to which repository and whether this repository is public or not on the Internet). Possible accesses include deleting, listing or writing information in these repositories, which makes clear the need for full attention when configuring these tools. Errors in this process are considered operational and may lead to exposure of sensitive data (and are the cause of cloud data leaks in most cases).
Maintain a dedicated team for monitoring, managing and optimizing logs: More than monitoring logs, it is important to keep a team able to use this information with intelligence. The least to know — in addition to the features being used — includes what type of logging is available for each feature and whether it is enabled or not. Log analysis also needs to go beyond the simple monitoring and anomaly identification. Collected information can be used to optimize logs by adding missing information and removing unnecessary information, adding proactivity to incident response activity and making it less reactive.
Just the first step
Despite their broad scope, ranging from the early stages of configuration to the operation of cloud environments, the recommendations in this article are just a sample of the initial precautions needed to maintain information security in these environments.
Given that companies are constantly evolving entities, it is expected that the structures maintained by these companies will also undergo changes in order to keep pace with these developments. This means that this work of maintaining an environment (whether on premises or in the cloud) is not something ready and finished, but a process that must be continuous and constantly evolving.
* this article was developed from the lecture “AWS Identity Services Overview: Enabling and Securing Your Cloud Journey,” by the author at 2019 AWS Summit São Paulo, June / 2019
