Are you the cloud security person, or cloudsec/cloudops, as it’s often called? The person who controls the cloud deployment, including all security such as IAM (identity and access management), encryption services, and application and user authentication? I have some observations about cloud security to share.
First, enterprises typically don’t have a good-fitting security solution. For most of the security solutions I’ve seen in the cloud, it appears that companies have turned on native public cloud security, done some iterations, and called it a day.
Second, security isn’t seen as something to be continuously improved through technology. Indeed, once a cloud system is secured, enterprise IT is reluctant to change or upgrade security. That by itself is a risk. However, by continuously improving your security systems, using best practices, tools, and yes, easy hacks, you’ll be at a much lower risk for a breach.
What are the hacks? You’ll be surprised at how obvious they are even though most are often not attempted.
Hack 1: Directory integration. I’m often taken aback by security systems that are silos. In other words, they don’t share user and identifying data about people, systems, and devices. IAM systems share this data via directory services. Most charged with cloud security either don’t employ IAM or do so without providing the automated sharing of information using a directory system.
Without directory integration, if somebody retires and is removed from the directory system for the on-premises systems, he or she wouldn’t be automatically removed from the security system in the cloud. You would have to change the information in two places.
Hack 2: Governance integration. Service and resource governance systems need to work together, but most don’t. For example, consider the benefit of being able to monitor potential misuse of a storage system if someone repeatedly violated governance policies. This person is likely an elevated security risk, and perhaps should be locked out.
Hack 3: Automated security testing. Most of you who use devops toolchains understand the value of automated testing tools, but many are still avoiding automated security testing as part of the devops toolchain.
However, when security testing is part of the automated testing systems, you’re able to find issues at the code and data levels, before they go into production. Applications moving through the toolchain are likely to be five times more secure than those that use passive security testing or no security testing at all.
Give a couple of these a try and see what you think.