Cloud security if often cloudy because it’s not on premise where you can control it easier.
That means you may have powerful user IDs in the cloud that your security team knows nothing about, which means….
Well, you know what it means.
I did an audit recently at a company that had strong controls around adding system IDs to the anything on the network .
I define a system ID as an ID that usually has elevated privileges and is not assigned to a specific user; it is assigned to a host, process, service, etc. So instead of JON316 that identifies a user named JON, you have an ID like BACKUP, which is used to run backups, serve as a firefighter ID, etc.
This company required all system IDs be registered in a security database and approved by the requester’s manager and the security team prior to use. Every admin or analyst with an network or application authority was trained to check the database before providing the ID any access to any resource on the network.
And that was the one thing that their controls and training did not address: system IDs OFF the network.
I was auditing a new cloud database implementation and found that only 2 of the system IDs used in the cloud were approved and registered in the database. The rest were not.
So how did this happen?
The 2 user IDs that were approved and registered connected the on-premise network at the company to the cloud. One of them copied data from a network database to the cloud, and the other one allowed the cloud processes to be monitored from the company network.
The other IDs were only used in the cloud and never connected to the company network. So none of those user IDs were approved or registered.
These IDs were powerful IDs, some with full access to the entire cloud and it’s many layers.
Some of these IDs were used by the cloud provider’s systems, and others could be used by company admins to administer the cloud.
I suggest you take a look at your security policies and your systems in the cloud to ensure this isn’t happening at a company near you.
Tone at the Top
This incident also indicates a tone at the top problem. While technically the admins that created the unregistered IDs followed policy (these IDs didn’t connect to the company network, so no approval needed), a security mindset requires ALL system IDs to be approved and vetted, especially those with elevated IDs.
If security is not a critical element that is considered at every step of an implementation, a tone at the top problem exists.
Or that tone never filtered down to the admins and analysts.
It also indicates that security policies and procedures need to be constantly reviewed and updated to address situations that were not possible before or were just plainly left out.
Have you done any audits of cloud implementations at your company? What have you found, good or bad?
Please share your experiences or concerns in the Comments.