The evolution of computing technology has dramatically increased the speed at which companies are able to innovate. Organizations that are slow to adopt this technology may soon be replaced by innovators who take advantage of all that is offered. For example, Blockbuster was thriving with its video rental stores across the U.S., yet its business could not survive competition from the likes of Netflix, Hulu and Amazon Prime Video. Those innovators rely heavily on new technologies to deliver video services via streaming over the Internet, eliminating all of Blockbuster’s costly and inefficient DVD delivery methods.
In recent years, the new trends of artificial intelligence (AI) and machine learning (ML) via cloud computing services pose wider threats to many more industries. For example, stock brokers may eventually become irrelevant when online services offer best-case scenarios for investing, using ML technology that matches investor profiles to well-tested strategies. The resulting recommendations will be far more accurate and cheaper to deliver than those coming from the current human consultancy method. Similarly, a radiologist who needs 13 years of high-level education to read and diagnose diseases from X-Ray images may soon be replaced by someone with far less formal education who can leverage ML technology.
For companies, the question is shifting from should they adopt these new technologies, to how they can adopt them more quickly. The public cloud offerings from AWS, Azure and Google offer great platforms for a company to start its technology transition. There is in fact a rush to this transition, as evidenced by the massive growth in public cloud migration. This, however, has led to new potential security problems resulting from improperly planning and executing the cloud migration.
Major Data Breaches
When it comes to cybersecurity, there are several areas that need attention. One that stands out is the ability to protect your cloud identity and access management (IAM) system. The IAM system is a strong control and can protect your data and resources when properly managed. If improperly managed, there can be severe data losses. Here are a few examples of data breaches caused mainly by poor IAM management:
- 2013: The NSA/Snowden data breach, in which an insider who had full access to many internal systems, shared top secret data with other organizations. A lengthy forensic investigation ended without a solid conclusion due to the lack of auditing records during the events. Snowden would have had a hard time executing the breach if the NSA had enforced auditing controls and proper IAM access control with multi-factor authentication (MFA).
- 2014: Codespaces.com went out of business, when its cloud services and data hosted on AWS was hijacked and destroyed by the hacker because of an unfulfilled ransom request. This is another case of no MFA enforcement.
- 2017: The Equifax data breach, in which attackers accessed a database that contained unencrypted credentials that they then used to access other internal databases, resulting in a leak of the records of an estimated 147 million people. This is also a case of privileged accounts without MFA. Enabling MFA could have prevented the hacker from accessing other systems by merely using stolen passwords.
- 2019: Facebook’s 540 million-user data breach, in which user accounts were stored in an open access S3 bucket by third parties who had access to the data. If Facebook had followed AWS S3 bucket policy for access control best practices, the breach would never have happened. AWS policy stipulates the S3 bucket should not have open access to everyone. An S3 bucket that stores data must have a policy that limits access only to its rightful owners.
Golden Keys to Cloud Kingdoms
One of the benefits of the cloud is its ability to help your organization deploy your cloud applications quickly, and store data redundantly. Agility is the goal, but to achieve this, your application, operations and security teams may need the next level of training and preparation to adapt to the nature of cloud services. However, typical early cloud adopters tended to start with a proof of concept (PoC) by someone in the organization. The PoC would then turn into something larger, with applications and data. But there would be no formal enterprise process to strategize and assign proper access control policies to the resources in the cloud. It is often the case that a new cloud deployment is fully owned by a small group of people, if not just one or two, who have full access to all cloud resources. These people hold the golden keys to your cloud kingdoms.
DevOps and DevSecOps
DevOps and DevSecOps are the new models of rapid development and innovation in the cloud. These models demand that software developers either transform into full-stack developers or work very closely with operations (DevOps) or security and operations staff (DevSecOps). The end goal is that developers and their supporting operations and security counterparts will join forces to create some automation scripts to quickly and securely deploy applications, along with infrastructure and tools, in the cloud. Sometimes the new cloud-aware developers prefer to work and control their cloud applications and infrastructure independently with no consultancy from other operations or security experts within the firm. This can lead to a violation of the least privilege principle of the cybersecurity rule.
You will be amazed at how quickly your infrastructure and applications deploy with automation via these new models. However, DevOps systems and processes, if not implemented properly, can pose security risks when access permissions are provided with unnecessary privileges. It is also extremely dangerous if your infrastructure and data can be destroyed instantly, either by an operational mistake or by an attacker who hijacked your high privileged DevOps access credentials.
DevOps or DevSecOps are the new models you should adopt for your organization, but they must have proper IAM controls and procedures in order to operate efficiently and securely. This is an area that should not be overlooked by management.
The New King: The Cloud Administrator
The process to create new cloud accounts in AWS, Azure and Google is fairly simple. You use your corporate email address, a credit card for payment method and billing information, etc., and you are instantly in the cloud. At this point, you are also the sole administrator of your cloud account, the king of your empty cloud kingdom. You will decide how to grow your cloud kingdom quickly with applications and databases. You will soon need to delegate your role to other cloud knights, who also have permissions to bring up and shut down your cloud resources. You and your new cloud knights will prefer to keep it simple, since dealing with fine-grained access controls to resources requires lots more work and effort. Therefore, your cloud knights are now in fact new cloud kings.
As your application and resource deployments grow in the cloud, that small group of cloud administrators will not be able to keep up with the workload. They will need an even larger group of administrators with the same set of permissions. One typical approach uses a Microsoft Azure Active Directory (AD) administrators’ group (ADAG) to control access to cloud administrators via the role-based access control method. People in this ADAG can typically share access to the group emails, which were used to create the cloud accounts. They may use those emails to reset your cloud root accounts. Effectively, any of your cloud administrators can then reset a cloud account password via email. It now becomes harder to track who has access to the shared account, and you may begin to question the gaps in your cloud security model.
Protecting the Cloud King
Inevitably, you still need cloud administrators. The question now is how to protect those administrators from doing things unaccountably. It may come as a surprise to you and your administrators that their passwords are accessible to certain groups of people in your company. The following areas show how an access breach can happen via other system administrators.
Figure 1: Various system administrators can access your cloud accounts
The administrator of your email system can access other employee email accounts by resetting their email passwords. Remember that your cloud account must be created with a valid company email, which can be used to reset your cloud account password when needed. Therefore, your email administrator can access your cloud account.
Password Vault System
It is a best practice to store your high privileged account credentials in a password vault system using a commercial product such as BeyondTrust, CyberArk, HashiCorp Vault, etc. These password vaults provide access auditing and access control for passwords via a web interface or an API. However, the administrator of the password vault system can still access any other employee’s password, including ones for email and cloud accounts.
Microsoft Active Directory, or its cloud version Azure AD, are currently the most common deployments for directory systems. The administrator of these directory systems can access other employees’ email and cloud account passwords.
Multi-Factor Authentication (MFA) System
One popular recommendation from cloud providers is to enable MFA for your cloud account. This is generally a good approach, but it is not a panacea. Large companies with complex operations teams need to have access to the same cloud account. Assigning an individual cloud account with an MFA device will make it hard to share the access — e.g., the MFA code must be available at the time of the access request. In addition, sharing access is typically not a good practice unless you enforce a protocol to control the sharing with audit capability.
Multiparty Access Control (MAC)
Although it is a best practice to lock away your root account after its initial creation, there are cases where you will need to use it to perform certain activities. For example, in the AWS cloud, you must use a root user to create a CloudFront key pair. Besides root account users, high privileged users such as cloud power and administrator users can also do major changes — or damage — to your cloud resources if they have too much freedom in the cloud environment.
Multiparty access control is a method of protecting high privileged accounts by using multiple groups of people to keep part of the credential materials and maintain access to audit control logs. For example, one group will own the account email and password, while the other group will keep control of the MFA device. The challenge here is how the MFA group can audit access — e.g., all access requests must be submitted via email for audit trail purposes, and provisions to provide access to the MFA code 24/7. For large companies it is common for a 24/7 group to support other functions. You can leverage this group as the owner of the MFA device. However, this will require practice and training for the group to provide timely support to the MFA access code request.
By now you can see the complexity and importance of your cloud IAM systems. The principle of least privilege has survived the test of time in the cybersecurity industry. When it comes to cloud deployments, it is even more important to pay attention to this principle. On the one hand, you want the least privilege principle to apply to cloud operators. On the other hand, you want to be agile by giving your teams permissions to deploy multiple services in the cloud. Striking the right balance between security and agility will require a serious effort for any organization.