If you were in an IT-related field 10 years ago, the term “Shadow IT” might strike fear into your heart. In case you missed it – or blocked out the bad memory – that’s when business SaaS emerged, enabling lines-of-business (LOB) teams to buy their own turnkey software solutions for the first time. Why was it called “Shadow” IT? Because IT security teams typically weren’t involved in the analysis or deployment of these Saas applications. IT security often didn’t find out about the apps until something went wrong and they were called in to help – and by that point, data, apps and accounts had sprawled across the cloud.
Frankensecurity
These apps were built externally, with no commonality. They had separate data stores and separate user stores. LOBs selected them, understandably, because the apps made their work easier. And yet, this created an unintentional set of security risks. Even small companies often had Frankenstein monsters’ worth of applications running, with no standardized methods of control. As often occurs, security innovation ramped up to meet this new threat, and common access control tools had to be bolted on after the fact. This included new/improved tools like single sign-on (SSO), Cloud Access Security Brokers (CASB), and multi-factor authentication (MFA), along with new standards like SAML, Oauth, etc. It was a lot of work for IT, a lot of risk for enterprises, and a reactive scramble rather than a proactive, thoughtful and efficient process.
The rise of PaaS
Shadow IT is officially behind us, thanks to standardization, plus tighter interaction between security teams and LOB. But Shadow IT 2.0 is looming, with the star of the show shifting from SaaS to PaaS (platform as a service). With the emergence of public cloud infrastructure, development teams can, for the first time, deploy, configure and manage their own application infrastructure – all without the need to ask permission from IT.
If that sounds like a big deal, that’s because it is. While the original Shadow IT was daunting, what’s happening now is on a larger scale. Instead of the accounting team downloading Expensify without telling IT, development teams are now heading to the cloud to adopt entire platforms upon which they can build the applications that collect, manage and protect customer data. This has the potential to be not only a replication of Shadow IT, but actually an amplification. The key word: potential. Because this doesn’t have to be Shadow IT 2.0 at all. This time around there’s an opportunity to make this new shift a really good thing for data privacy and overall security – if you play it right.
Thunder in the cloud
We probably don’t have to tell you that developers and IT security teams aren’t always aligned. They may all have optimal intentions, but those intentions are frequently in conflict – especially if they’re receiving different messages from the top. Again, developers no longer have to rely on IT to build out servers and virtual machines. Now they can rent as much cloud space as they need, plunge ahead with development, and IT is none the wiser. In addition, developers are often pressured to work quickly and release new features to customers as fast as possible, while IT security teams prioritize – you guessed it – security, compliance and risk mitigation.
Cloud infrastructure is a breeding ground for this type of misalignment. Its software-defined and code-based structure is a dream landscape for developer speed and flexibility, but “everything as code” environments exist both physically and conceptually outside the traditional bounds of IT security control.
A sunnier outlook
On this scale, misalignment and conflicted interests sound like game-ending disasters. Should you panic? In a word, nope. Most enterprises, likely including yours, already have the IT security expertise and development expertise to address these challenges. The solutions just might not currently exist on the same teams with the same people. But while these players might have different strategies and different objectives, those strategies and objectives can absolutely coexist – and for the first time, they can be actually be built in to products rather than bolted on later.
The first step is making sure the right hand knows what the left hand is doing. You’d be stunned at how many companies carry on with every individual and every team ticking every box and hitting every objective, patting themselves on the back while not realizing that they’re actually working against each other.
IT security teams know what to do to protect sensitive data.
Developer teams know how to do it with policy-as-code.
Put them together, and voila: Shadow IT 2.0 never happens. Instead, you get efficient, versatile, ultra-secure and hyper-tailored platforms that take you where you need to go. (For real!)
How will this avoid Frankensecurity?
If you happen to catch your developers before they go off on their own and start adopting PaaS, great! Get them aligned with data privacy and security goals, and make sure you level set expectations. (In other words, if your developers are currently evaluated based on speed and efficiency of customer-facing features, you’ll have to pivot to allow them to incorporate behind-the-scenes security objectives as well.)
Even better – unlike with the original Shadow IT, once your teams are aligned, this time you don’t have to wait for the industry to catch up. Modern policy-as-code authorization controls not only who can do what, but what can do what – ensuring mitigation of both user error and rogue service operations. When expectations are clear, you can build common policy directly into cloud apps and infrastructure, up front, enterprise-wide. This is possible thanks to the widespread use of declarative APIs to define how systems should interact and interrelate. Data may be distributed, but access can be controlled via these policy-as-code solutions. These solutions take intended security controls (which were historically enforced by firewalls, identity and access management, proxies, etc.) and codify that policy directly into the software or cloud infrastructure itself. This means you don’t have to worry about bolting on Frankensecurity after the fact.
If your developers are already deep into PaaS adoption, it’s not too late. Define expectations with IT security and give your developers clear instructions on what the outcomes need to be. Great programmers won’t have a problem coding security into existing platforms (and great platforms are already open source and very modification-friendly). The policy-as-code approach still works, since it can be added to existing apps and assigned to new apps as they come in.
The bottom line
Containerized apps and policy-as-code offer a level of security that couldn’t have been envisioned during the days of Shadow IT 1.0. Today, privacy and security can be ensured with a common, automated, API-based ruleset for context-based access control, without the operational overhead of custom entitlements engines working alongside countless unrelated tools and systems. That’s a major upgrade on the static, centralized, never-ending quagmire of yesterday’s role-based access solutions.
In the past, “authorization” policy was pretty good if it could truly limit who can get in, and what they can get out. Today, authorization has evolved. Now you can control who can get in, based on any context, but also: which specific services can run where; which app components can interact; where PCI protected data can live – and where it can never go; which services can talk to the Internet and which can’t; whether to accept inbound connections; what data can stream out of a database; and far, far more. When everything is an API call, policy-as-code becomes incredibly powerful and fully automated.
The bottom line: Some of this is familiar. It’s once again a shift that stems from the cloud, and it starts with IT control. But unlike the first time around, Shadow IT 2.0 doesn’t have to be a crisis. In fact, this time we have the learning, the skills, and the new tools to make the move to cloud-native both more productive and more secure.
