RedLock is now a part of Palo Alto Networks - READ MORE
RedTalk: Cloud vs On-Premise Security What's the Difference?
< Back

RedTalk: Cloud Security vs On-Premise Security What’s the Difference?

by   |   08.30.18, 6:00 AM

Understanding the differences between on-premise and cloud security matters because research shows public cloud security incidents to date have largely been the customer’s fault. While the debate use to be focused on which was more secure: cloud or on-prem, progressive CISO’s and their teams are now wisely focused on solving a new question:

"What are the key differences between cloud and on-premise from a visibility and control perspective and what people, platforms and processes do we need to invest in to address them?”

From our perspective, the differences primarily hinge on shared responsibility and APIs. Understanding these two area and their subtle nuances should be the critical first step in maturing any cloud program. Let’s start with definitions and a brief history of both.

Analyzing the Differences: On-Premise Security

When it comes to on-premise environments, what’s one thing that organizations undoubtedly own end-to-end without exception? Security. There is no question that what happens in most organization’s on-premise environment is owned 100% by the security team. There are existing people, processes and platforms to address every part of the CIA triad and a greatly reduced amount of finger pointing as to who is responsible for what. Now consider traditional security tooling. Unlike public cloud, which we’ll discuss in detail next, web application firewalls (WAF), Next Gen FWs and nearly every other security tool are not typically interconnected by an underlying API fabric or unified console. In fact, most on-premise security platforms do not even utilize APIs. And given the lack of APIs, most on-prem environments have little to no automation. In contrast to public cloud environments, on-prem is almost always IT-driven and security governed.

Analyzing the Differences: Cloud Security

Given that AWS was founded in 2006 (that’s twelve years ago!) public cloud is no longer a new and untested frontier. In many ways public cloud is the evolved sibling of your on-premise environment with a big security catch: organizations need to share the security responsibility with the cloud provider. Further adding to the organizational risk equation was that with public cloud also came the proliferation of APIs. APIs are synonymous with cloud because they are essential for automation and orchestration which both enable scale as well as the ability to keep up with the constant pace of disruption in today’s business climate. API’s also add a new layer of complexity and risk as traditional security tools are completely unaware of how they operate. Given the ‘push button’ ease of cloud platforms, developers have eagerly taken matters into their own hands by constructing their own data centers in AWS, Azure and GCP— largely outside the purview of both IT and security teams.




- Responsible for security end to end - Shared security responsibility
- Disconnected security tools; not typically driven by APIs - Interconnected, API-driven security tools
- Static resources, perimeter-based security boundaries - Dynamic resources, ephemeral security boundaries
- Rarely automated - Can be highly automated
- IT-driven - Developer-driven

Figure 1 - Differences: On-Premise Security vs. Cloud Security

Why the Differences Matter between Cloud Security vs On-Premise Security: Shared Responsibility

“Through 2020 95% of cloud security failures will be the customer’s fault.”
- Gartner

Put another way, through 2020, only 5% of cloud security failures will be the providers fault (it does happen). At RedLock, we are adherents to the Pareto principle (80/20 rule) and believe a fundamental understanding of the shared responsibility model is key as this is the risk differentiator when compared to on-prem environments. Once the shared responsibility model is understood, clearly documented, agreed to and communicated in an organizational RACI, we recommend conducting a risk assessment informed by a thorough understanding of security in the cloud (NIST 800-144). No matter which cloud model an organization chooses, SaaS, PaaS or IaaS, it is always accountable for the data put into the cloud. Accountability cannot be outsourced (sorry!).

Why the Differences Matter: Interconnected, API-driven security tools

Attempts to utilize legacy on-premise security tools that don’t take advantage of the API-driven nature of cloud and that are not natively part of the cloud provider's infrastructure will, in our experience, break DevOps. Think about it: developers are coding to the cloud providers APIs and legacy security tools that cyber teams put between developers and the cloud provider are only going to add unnecessary complexity. Put simply: enterprises are struggling to lift and shift legacy security tools as they don’t speak the language of APIs. This means there is a major gap in terms of visibility and control. This is why we recommend evaluating cloud friendly security tools that utilize native cloud provider APIs only and are not with a single cloud vendor but rather support the most diverse set of providers. Look for security tools that at a minimum support Amazon, Google and Microsoft clouds.

Why the Differences Matter: Dynamic resources and ephemeral security boundaries

If there is another term that public cloud has brought into the popular lexicon outside of API, then its the word ephemeral. As an example of perhaps the most dynamic and ephemeral of resources, Google Cloud Functions serves as an excellent illustration. There are no servers to provision, patch or touch, it simply executes code in response to events and then it's gone without a trace. The security boundary is largely driven by Identity and Access Management (IAM) roles and traditional security tools such as firewalls, WAF, IDS/IPS are largely anachronistic in this scenario. Compare this to servers that most typically run in on-prem data centers, the aforementioned security stack works quite well as the resource is static, never changing its IP address or physical location. Interestingly enough, RedLock research indicates that the average lifespan of a cloud resource is only two hours and seven minutes. Compare this with on-prem where lifespans are typically measured in years!

Why the Differences Matter: Developers Own Your Cloud

While security and IT teams are uncomfortable with it, the vast majority of cloud environments are managed by software engineering as they have been using cloud for years. This is a powerful opportunity for security teams to build cloud-friendly security tooling and requirements into the development pipeline (commonly referred to as DevSecOps or Secure CI/CD) as well as a better relationship with development. When security teams move from mandates and hypotheticals to collaborative partners with DevOps, security begins to morph into DevSecOps.


Considering that a vast majority of cloud security incidents to date have been failures to implement proper in-cloud visibility tools, controls and process on the customers’ part, security teams are wise to focus on the differences between on-prem and cloud. Once a risk assessment has been completed, organizations then need to complete a tools capability assessment as it’s highly likely that existing on-premise tools will simply not work with rapidly evolving native cloud provider APIs. Attempting to layer in these legacy tools will result in unnecessary complexity and reduced visibility — hampering both your development team's efforts to rapidly release software, as well as security teams efforts to integrate into the development pipeline.

Next Steps

This is where cloud-agnostic security tools such as the RedLock Cloud 360 Platform can help. RedLock leverages 100+ native cloud provider APIs to continuously aggregate volumes of configuration, user activity, host vulnerability and network traffic data without impeding DevOps. RedLock provides a single location where security and DevOps teams can gain visibility across Google, Azure and AWS while freeing these teams from the care and feeding of homegrown, open source or native cloud provider tools.

Related Posts