Best Practices for Cloud Security

There is no one perfect solution to Cloud security, in large part because the phrase means different things depending on whom you ask. Beyond individual interpretation, different systems provide vastly different controls for adjustment. While one cannot set detailed controls that apply in every situation, a broad set of base controls can be crafted that address the security of most cloud environments.

Data Sensitivity

Before you start securing any cloud system, you have to understand what data it contains. In most cases this is an easy exercise, but the more specific the system, the more time you may need to spend with a business owner to understand all their potential use cases.

An HRIS is obvious, it will contain PII for all employees. Some of the highest sensitivity of data with the most restrictions. However, depending on the jurisdiction there may be regulatory requirements regarding access as well (ex: GDPR).

Niche applications are often the most overlooked. An example might be that marketing has a service used for the “Brand Book”. Data which the company considers semi-public information and seemingly of little worry. Except that the same service with minimal data security will also be used for the new brand redesign which is considered extremely sensitive until release.

Controlling authentication & authorization

Regardless of the size or complexity of the system, authentication and authorization are the next steps. In the “good ol’ days” of the intranet, you could be reasonably confident that everyone connected was a corporate employee. However, when everything is on the internet “Accessible to everyone” is only a selling point for the marketing website.

The first control is authentication: who is connecting to the system and how they are proving their identity. This is table stakes for everyone in security, but is often the first thing to fall by the wayside when given to busy and overworked IT Helpdesk teams. Maybe the password reset process is a weakness, maybe IT doesn’t do a perfect job cleaning up every outgoing employee, or maybe those employees are using a terrible password because the system has no password policy controls.

Any solution that centralizes authentication will provide huge wins in solving this problem. That might be a cloud based SSO provider (here at BeyondID we’re big fans of Okta) or it may be an LDAP/AD integration. Not only does it work to eliminate one of the most obvious security issues, but it also provides a better user experience (fewer passwords). Win/Win.

After authentication is addressed, the second most common area of security sprawl is authorization. The control of who has access to what once they are properly authenticated. In the name of user convenience, many systems allow users to share data, links, or access amongst themselves. Of course, this convenience comes at the expense of control. Rarely will users purposefully mis-share data, but also rarely do end-users understand the full implications of their actions within a large and complex system. Where possible, standardization should be imposed through education, monitoring, and/or the removal of sharing controls. Many SSO providers can be configured to grant new employees access to necessary data on their 1st day. If users have access to what they need already, they will not need to ask for shares from “helpful” coworkers.

In the mix of authorization and permissions, is data classification. Not only should files (or folders) be tagged accordingly, but the users should be educated about the data classification system. The better someone understands how the data is classified and what that means, the less likely they are to make risky changes.

3rd Party Integrations

No cloud service exists alone. The entire purpose of standards like OpenID Connect, REST APIs, and SCIM is to connect otherwise disparate cloud services to each other. Some of the integration web will be in the form of clean and easy to understand systems such as Enterprise Service Buses, but many will be direct system-to-system connections. This has been made even more complex by the app store-ification of many large platforms.

Many of these services are seen as only mildly useful without their entire ecosystems of applications. Regardless of what name the integrations go by, each one of these “apps” is a new security threat that should be evaluated the same as any new cloud service. Even if two connecting services are already approved, is the movement of data between the two systems acceptable? Chat is often seen as a very low data risk service, until it becomes interconnected with dozens of high security systems. While an attacker may not be able to use chat alone to directly compromise any system, it can become a tool for pivoting into sensitive systems from a “trusted” source.

Role Accounts

Role accounts are a necessary evil for most cloud services. Integration with external systems must be tied to a particular user, with very few services supporting the concept of a non-human (or non-licensed) account. During the growth of companies, role accounts typically do not get created due to the additional cost. The more expensive per seat a system is (Ex: any CRM suite), the less likely any dedicated accounts were created. Finding these “overloaded” user accounts may be obvious (Ex: your Salesforce admin is adding new leads from the website 24 hours a day, 7 days a week), but often will be much more subtle. Close monitoring of authentication logs can be a great source of automated activity. The worst time to find out about a critical connection of infrastructure is when that expert has just left the company and their accounts are disabled.

Managing these accounts can be a challenge in and of themselves, which will probably be left to the IT Department. Though they will need guidance on when new role accounts should be created. If the company is big enough (and/or the service cheap enough) a new role account can be created for every integration. For everyone else, there will be some line at which an integration just isn’t worth the extra cost of additional licenses. Having that line defined upfront, along with making sure all integration setup processes are well documented will significantly alleviate any confusion, and change risk, down the line.

Auditing, Monitoring & SIEM

For the most basic of cloud services, someone may need to be tasked to either manually review logs or export them by hand. Fortunately, as cloud services mature, they typically improve upon their monitoring capabilities. This eventually reaches a natural plateau, of sorts, with integration into SIEM systems. At that point the ongoing monitoring of a cloud system should become a standardized process. All event logs from all end systems are pulled into the SIEM of choice.

Optimally, SIEM data will be processed by a SOAR, or other security-automation tool, in real time. Alerts should be set up on both specific single items along with broader patterns and connections. A user who is required to authenticate via SSO, should show the same client IP address for all authentication actions for a single session. However, the world is imperfect and alerting on IP mismatches alone may lead to a large number of false alerts. Utilizing other information such as user cell phone IP addresses (from chat systems) and IP Geolocation technologies, should be able to assist in refining alerts. The triggering of an alert does not always require a human being paged. For example, if authentication is a concern (ex: cookie theft), then utilize your SSO or end-services API for session invalidation.

Billing & Unusual Behavior

Understanding costs is a critical piece of any service selection process, but commonly not something that receives attention from the security team. However, it should bear some amount of scrutiny to at least understand the billing model and potential risks associated. In the average cloud services where costs are directly tied to the user count it is easy to predict and monitor. However, for services that bill on usage (e.g. AWS or VoIP systems) ongoing monitoring of current usage may provide an early alert to compromise. Attackers who opt to utilize credentials for theft of service may end up being quite expensive for the company if not contained quickly.

Keeping an eye on billing is just one of many forms of behavioral monitoring. Anything that can be quantified and alerted upon should be considered for monitoring – even if there is no direct threat. Any behavior out of the norm may be an indicator of compromise. Just as a database server sending gigabits per second of data to the internet would raise a red flag, a user sharing dozens of SharePoint documents per hour should warrant attention.


The final area of discussion is that of education. Most will agree that security education is important, however getting that education properly dispersed… well therein lies the problem. A yearly seminar may meet compliance requirements, but is easy to tune out. The best way to teach users about security is dependent on an organization’s needs, and in fact may vary based on the needs of its individual business units.

The average person does not think like an attacker. They do not walk into a store, look at the security cameras, and notice the blind spots. Thinking in that way is the Security Team’s job. What you can do however, is bring more awareness to these folks. They do NOT have to be the weakest link.

Catering the training to different job functions will help them grasp what affects them the most.

A developer of a web app should be thinking about what happens if a submitted field is filled with junk data, whereas someone in finance needs to be worried about vendor payment information swaps.

Keeping everyone informed of the latest security information should not be hour long presentations. Rather, dispersing the information as little nuggets of wisdom, provided regularly (security vitamins, if you will) will make all our lives a bit easier, and safer.

In the end

Cloud security is a large and diverse topic. There is a lot to do, and it is constantly changing. However, it is not impossible. And it is not the sole realm of the “Security Team”. Everyone in a company has something to contribute when it comes to security in the cloud; the size of the contribution is not important, everyone pitching in is. An end user may see something, or a business system owner may understand something that the Security Team was totally unaware of as a potential issue.

Each business needs to evaluate the data and systems that are of most risk (or value) and move forward from there. Some solutions, like SSO and SIEM, provide an excellent starting point for relatively low cost. As nothing business, nor in the cloud stands still, so too should the company’s security stance remain constantly evolving.

Contact BeyondID for all your cloud security needs today.

Picture of BeyondID

Leave a Reply

Your email address will not be published. Required fields are marked *

Signup for our newsetter