I recently had the pleasure of participating in a panel discussion at the Cyber Security Summit USA in Denver, CO, on the topic of cloud INsecurity. The panel needed to cover the common pitfalls that organizations make when moving to the cloud and how to avoid them. Joined by several distinguished panelists from the security industry, we tackled some key questions and I wanted to share the key takeaways with those who were not so fortunate to join us live during the event.
1. What is the number one risk customers miss in moving to the cloud?
Nobody wants to be on the news because they missed mitigating the number one risk in moving to the cloud and caused a breach that leaked customer data. So naturally, I get asked this question often. I flip flop between two answers: shadow IT and lack of IT staff training.
In the context of our topic, shadow IT is the phenomenon whereby employees who are not getting what they need from their own IT department take it upon themselves to set up storage or compute infrastructure at a public cloud provider, and deploy applications or store data in the cloud.
Assuming you have a very capable and well funded security team, they can only protect what they know they own. But when employees deploy their own cloud presence, they don’t necessarily have the skills or the tools to make sure that deployment is secure and remains secure over time. Quite often, cloud instances are forgotten at the end of a project and whatever web servers might have been deployed become outdated and vulnerable with nobody responsible for patching them. The company as a whole ends up dealing with a data leakage or an intrusion because of an attack surface the IT department did not even know existed.
My second answer is the lack of IT staff training. Quite often, IT staff finds itself dealing with a mandated cloud exposure without ever having been trained on the security aspects of moving to the cloud. Most of the training focuses on the cloud service provider and what security tools it may have, like setting up access lists, but little training goes into what kind of threats does a cloud deployment expose us to, and what capabilities do our existing security tools have that could expand to the cloud.
2. How dangerous is “Shadow IT” and what are the ways we can better integrate shadow IT into our cloud adoption strategy?
This is a key question in my mind. We have to recognize that IT staff is always under pressure to deliver on business transformation initiatives and they will always be stretched thin. Shadow IT is here to stay, so we need a strategy to include it in the cloud adoption journey.
Most of the time with shadow IT, some group in the company needs to quickly deploy an application or storage onto the cloud. In order for IT to somewhat retain control over the security posture of the entire network presence, they need to provide templates and tools that would enable a secure deployment. For instance, deploying a new VPC should automatically deploy a virtual firewall with all the necessary configuration to restrict access to the VPC to known sources, secure the campus to cloud connection with a site to site VPN, and add the newly acquired IP addresses to a scanning solution to make sure the VPC never deviates from an acceptable posture.
3. How do we need to update our policies, contracts and vendor risk assessments to take into account cloud resources?
Yes, the journey to the cloud opens additional risks with third party vendors that were not present in a data center deployment. For example, let’s assume you are deploying a SaaS application to the public cloud. Most security assessments would focus on testing the APIs exposed by the application. But time and again, various cyber incidents have proven that supply chain attacks are very devastating. So you must ensure the integrity of the third party libraries used (are updates signed and delivered securely? does the provider have good secure development practices?) and ensure that the posture of the vendors providing internal services is at the level expected.
4. What are some new and emerging threats that are “Cloud native”?
The public cloud has clearly made some types of threats more potent. The first one is phishing for credentials. The adoption of SaaS application for email and file sharing in particular, in addition to the implementation of single-sign-on access control, we see a lot of phishing attacks aiming at collecting user credentials. The second threat is access privilege abuse. Many applications deployed on familiar cloud platforms request and obtain access to privileged personal information by luring users to believe they are legitimate requests from trusted application. The third type of threat is the prevalence of cryptomining attacks targeting insecure docker instances or server instances. The fourth is the non-stop scanning of public cloud IPs hunting for non secured data troves in hopes of monetization through ransom notes.
5. What questions should organizations be asking their security providers as they look at services for the Cloud?
One of the most important decisions people make when adopting a cloud strategy is to pick a vendor of choice to guide them through the transition. This vendor must master both networking and security to be a viable option. In my mind, here are the main questions to ask your vendors:
- Can I have centralized visibility? Nobody moves to the cloud and leaves a data center behind. For the foreseeable future, you have to deal with a hybrid environment with potentially multiple cloud providers in addition to your data center. It is important for the chosen vendor to provide a single pane of glass for the entire network.
- Can I apply business policies across DC and multiple clouds? For the same reason above, you will want to craft and deploy policies based on business entities and applications, not based on physical deployment criteria. Where an application is running in your data center or a public cloud, the same policies should apply seamlessly.
- Do you handle new deployments the same way in the Data Center or the cloud? In other words, you want to make sure that the security services are available for both physical hardware deployment in the DC as well as a virtual, or containerized version for the cloud.
- What are the gaps your solution does not cover? The proverbial elephant in the room must be uncovered. Each vendor should be able to articulate the security gaps in their offering that you need to handle through a different vendor. That is usually a good time to check for openness of the architecture, its reliance on open APIs to integrate other solutions.
By Mounir Hahad
Published with permission from forums.juniper.net/t5/Blogs/ct-p/blogs