In the heady days of the 1970s, no one passed through the doors of Studio 54 without famously being vetted by the trendy club’s bouncers – and with good reason. Not only did the disco want to attract only the hippest or most desirable of celebrities and glitterati, it also wanted to protect them, ensuring that “bad actors” couldn’t penetrate the club’s walls and expose the goings-on inside. Organizations embracing the cloud could take a page from Studio 54’s book by ascertaining identity and controlling access.
The list of companies and organizations that have had data compromised through unsecured cloud storage systems is long and illustrious, but at least one common thread through all is access was available due to poor identity access management (IAM) practices. AWS and other cloud storage providers usually turn over a bucket to a customer in a locked down condition, but changes made by the end user often result in the data going from safe to exposed with a single keystroke.
Sarah Squire, senior technical architect at Ping Identity, describes poorly managed IAM and the cloud as a huge problem with blame for the situation being split between cloud providers and the customers.
“In an effort to give their customers lots of options, cloud providers like AWS and Azure have actually given their customers an ample amount of rope with which to hang themselves. Cloud identity policies in AWS look like words you know – user, credential, token – but there are many edge cases that organizations routinely get wrong – is a continuous integration system that needs to be able to update in production a “user”? Should it have “credentials?” she asks.
Complicating matters further is when organizations have their data spread across several platforms such as public and private cloud services and in-house repositories, says Dr. Rao Papolu, founder, chairman and CEO at Cavirin. In the “old days” when servers, storage and everything else were kept in the company data center, admins only had to deal with giving access to a single network core, generally using a lightweight directory access protocol (LDAP) like Microsoft Active Directory to decide who is or who is not authorized to enter the database.
The advent of the cloud greatly complicates this situation by adding several network cores that can be accessed and now must be more appropriately managed.
“For each cloud service you use from a different cloud provider, there is another network core that is going to have its own LDAP. So the biggest issue when incorporating public or private cloud services is how the LDAP for the rest of your implementation is going to interact with the cloud LDAPs. Allowing each to have its own means that users will have to log separately into each cloud service, or use a Single-Sign-On solution that has its own vulnerabilities,” says Papolu.
Karthik Lakshminarayanan, director of product management for Google Cloud Identity, says there is no doubt implementing strong IAM is a problem, but his recommendations to ensuring this is done properly is to start by first understanding how a company currently functions and its overall security capabilities so as to not overwhelm the organization prior to laying out an IAM security plan.
“Google has a saying: ‘Meet the customer where they are,’” he says.
For example, if a company is using and is most familiar with the legacy security software they are using, it’s better to allow them to keep what they know, but support it with something better.
“Eighty to 90 percent of companies still use password-based authentication, but to move to the cloud they have to move past this. So we lay Google Identity in front of whatever the company already has,” he said.
This allows the company’s workers to keep what is familiar by simply making it safer, Lakshminarayanan says, and helps with the fact that once security becomes a roadblock to productivity workers start looking for a way to circumvent the controls that keep the company’s data safe.
Squire agrees, noting, “Using a vendor IAM system on top of your cloud rather than trying to configure the native security settings is a much safer option.”
Who sees what
Once proper IAM is in place the next question is deciding who should have access to what and from where. In some cases a misconfigured server actually has the correct security on board, but so many people have been given authorized access it becomes easy for a malicious actor to gain access, say through a phishing scam. By limiting the number of people to only those with a valid reason for accessing the data the attack surface is reduced.
“The short answer would be as severely as possible. Looking at this from the perspective of the value of data. Opening access to someone is much the same as giving them the combination to a company safe. It should only be given to those employees who must get into that safe to do their jobs,” Papolu says.
Squire brings up the point that company culture can play a role in how many people are given access. In firms that keep an eye on their API traffic and have immediate notifications for unusual or risky activity, more people tend to be given the keys to the data.
“Other companies prefer to err on the side of too little access – breaches and insider threats are very common these days, and the best way to prevent them is through a methodology of least privilege. Each end of the spectrum has its pluses and minuses. It’s usually a decision that the CEO and CISO make together,” she says.
Then there is the major no-no of allowing access to the storage sites to customers or third-parties where there is no control, says Rod Soto, director of security research at JASK.
Once everything is in place the organization must actively manage what is going on with its cloud-based content. One of the most glaring problems in this area is cloud service providers must manage their customers’ expectations. There is the strong, and sometimes incorrect, belief that the cloud is inherently secure and the big-name companies managing the cloud systems are handling all things cybersecurity in relation to their data. While this is true to some extent the company also has to do its share of work. Admins cannot kick back and pay no attention.
“Organizations think that they’re secure because they are on clouds with good security teams. It’s true that AWS, Google Cloud, and Azure have great security teams, but that doesn’t stop your organization from creating critical vulnerabilities in your own configuration,” she says.
For example, Squire pointed out user error cases where organizations accidentally leave the root keys for their instance sitting on their cloud, which allows an attacker to not only create an account with administrator access but to delete the existing administrators, she says.
Those with large amounts of data in the cloud are also apt to not so much forget what they have stored, but let slip the fact that infrequently accessed data still needs to be protected. This normally happens when data reaches the end of the active portion of its lifecycle, becomes dormant and is moved into an archive.
This does not mean security and IAM become any less important.
“The relevance of IAM comes when that less-expensive archival storage is also less-well-protected. Nothing says that just because data is dormant that it is any less classified, or no longer requiring privacy. Yet large quantities of such data are sometimes placed in unsecured AWS S3 buckets without appropriate security being maintained,” Papolu says.
The final stage of IAM management is ensuring that when a person with access to the company’s cloud leaves the company their access rights are removed. While canceling access to the regular corporate network is a well-practiced part of this scenario, admins have to remember to cover all their bases.
Squire suggests simply implementing a protocol that includes this access, while Papolu points out there are now automated systems that can help.
“Offboarding is probably one of the most prevalent and dangerous issues facing many organizations. It is easy to say that it must be part of the exit process, but how to enforce that remains the challenge. Many companies are automating the process using software that will, for example, not release the employee’s final check until they are successfully removed from all systems,” he says.
Bug bounty hunters on the case
One area that has not gained much attention is leveraging bug bounty hunters to help companies protect their data in the cloud. Because these white hats are always on the lookout for vulnerabilities and the normal course of the job has them searching in the dark corners of the web.
Casey Ellis, CTO of Bugcrowd, says, if properly incentivized, bug bounty hunters would be on the lookout for misconfigured servers, credentials or datasets found on the dark web that could indicate an open server has been discovered and compromised.
“We allow and encourage our customers to create bonuses for specific areas,” he says, although so far this is not common in the cloud space.
Another layer of potential security involves using machine learning to help relieve admins from having to create rules governing access for the possibly hundreds of people who require access to the cloud. Identity Analytics (IdA), provides a risk-based approach for managing system identities and access. Instead of static rules, IdA uses dynamic risk scores and advanced analytics to derive key indicators for automating account provisioning, de-provisioning, authentication and privileged access management. IdA enables organizations to implement intelligent IAM that can keep pace with rapidly changing business needs as companies pursue digital transformation, says Leslie Lambert, Gurucul’s chief security and strategy officer.
The fact that identity and access management in a cloud storage environment, or even on-premises, is a problem is no secret as can be seen by the huge number of misconfigured storage buckets seemingly littering the cloud like so many discarded beer cans after a fraternity party. Consequently, the need for companies to properly implement IAM has never been stronger.
Lakshminarayanan says this methodology is similar to what is used with corporate mobile devices that can be configured to check the user’s location, determine whether or not the data being accessed is within their normal parameters, and even see if the wireless network being used is safe.
“The sheer scale of today’s IAM requirements has evolved beyond the scope of rules-based systems,” Lambert says, further clarifying the need for machine learning to play a role.