Rise of the Rogue Cloud: The Fundamental Security Mistake Enterprises Make and How to Correct It
Development teams, especially at the world’s largest organizations, move at a lightning pace. Not just to keep their businesses competitive, but also to keep their jobs.
Knowing that, it’s easy to predict what happens when it takes a network user’s IT team two weeks to stand up a testing environment, or when—surprise!—nobody knows how long it could take. This could be because the organization never developed a clear process for providing on-demand computing resources, or because the company is dealing with a patchwork DNS, DHCP, and IPAM solution set that makes streamlining a process like that—let alone automating it—nearly impossible.
Network users who need compute are notorious for circumventing IT to get it autonomously (they charge it to their personal credit cards, then expense later). You can’t blame them, because they’re paid to get stuff done. Minding security isn’t in their job description.
This is a problem, especially when the Finance department’s expense controller finds out before the IT team that the organization has a rogue cloud service.
On a well-organized network that leverages a foundation like Enterprise DNS (short for “enterprise-grade, streamlined suite of DNS, DHCP, and IPAM solutions”), devices are covered by a unified, secure system. On a rogue cloud, nobody knows what’s going on. Sure, AWS and Azure come with more firewalls than someone can count but utilizing them correctly slows down testing processes. Naturally, these firewalls get indiscriminately disabled by the same users that circumvented IT in the first place.
Adding to the problem is the fact that most in-a-rush users who set up these clouds do so in a hurry, and often don’t bother to follow basic security best practices, like strong password selection. Shadow IT is a security nightmare.
As soon as something bad makes it onto a rogue cloud, it gets direct (Read more...)
*** This is a Security Bloggers Network syndicated blog from InfoSec Resources authored by Scott Penney. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/YqytzIl4zXg/