Step 1: Protect

Protect is a passive process because we set up systems to defend against threats using whatever security mechanisms are best for that defense—data encryption, for instance. Even if the data can be seen, it can’t be understood; thus, it’s worthless to the attacker. Data protected.

Of all the core cloud security attributes we cover here, protect is the easiest to pull off. What’s frustrating is that the protections most cloud-based systems need are not difficult to set up. Also, remember that cloud security is the best computer security in the world. Cloud provider security and cloud security in general get the lion’s share of R&D budgets, which means these technologies can provide the most innovative and thus the best security approaches and mechanisms available today.

What’s missing is the people aspect. Most breaches can be traced to human error, which is unsurprising. After all, cloud computing is a complex technology that’s still relatively new to most cloud practitioners. A certain number of errors are bound to happen in any learning curve. However, when you look at the incidents, it’s the simple stuff that gets screwed up. For example, some breach postmortems show that security engineers worked around default security configurations (which are typically very secure) to expose systems and data that are difficult to expose. In other words, they worked extra hard to find a way to accidentally expose sensitive data and processes. Not that I’m asserting any malicious intent. It’s just an example of people who know enough about cloud security to be dangerous who were promoted to their level of incompetence. With the current skills shortage, it’s a more prevalent problem than management might realize…until it’s too late. For instance, leaving outbound traffic unrestricted, which in many cases is the default. Or, some worse mistakes, such as disabling monitoring or logging, opening ICMP access, misunderstanding storage access configurations, or failing to manage credentials and keys.

Many of the cloud breach incidents I see are things that you can’t make up, and almost all link back to dumb mistakes that someone could have easily avoided. Of course, cloud computing gets the blame. If there are major cloud breaches or breaches in general, I’m on speed dial for most business reporters who ask for SME (small- and medium-sized enterprises) quotes around a recent breach. The most common question asked is: “Does this [enter breach name here] call into question cloud computing as an option for enterprise IT?” I then explain (again) that cloud security uses a shared responsibility model, where everyone must be well trained and make a conscious effort to not make common errors. With cloud security being the best security available, the focus on cloud protection needs to be on the humans who oversee cloud protection. We seem to have some growing pains in that department.

Protect requires that you take precautions with all your cloud-based assets and don’t do dumb things. Don’t leave data exposed or misconfigure security settings or do other generally stupid but known things that cause cloud breaches. A security engineer certification from any public cloud provider will quickly get you a six-figure job because not enough people know how to configure clouds and cloud security systems to protect assets, including data and processes. Books have been written about how to protect cloud-based assets in general, as well as for specific public cloud providers. Invest in a few. Where cloud security is concerned, encourage learning, and invest in knowledge.

Step 2: Detect

How do you find and stop attacks on your cloud-based systems? The cloud security system must be smart enough to constantly monitor and interpret things that are happening, have already happened, or are about to happen and then raise the alarm that a breach attempt is underway and prompt the system and/or humans to take evasive actions.

Detecting a breach means being proactive. The system finds states and behaviors that may indicate a breach attempt, or it monitors the shady actions of potential bad actors who might do or be doing something to our systems and data. This could be the increased use of CPU resources as access attempts are made that fall out of set thresholds and then doing some additional detecting to determine whether the threat is real or just one of the hundred anomalies that occur daily on cloud-based systems. The detect step can also use observability as a defensive weapon for cloud security (we discuss observability later in this chapter).

Detect is becoming the best cloud security asset that most enterprises choose not to employ. Systems that detect are more costly to set up (such as observability, covered later) and require deep knowledge of all the systems you’re protecting. You can’t detect anomalies in a system or data store that you don’t understand. The best insider advice I can impart about where to make cloud security investments is to invest in systems that can detect trouble or systems that can be proactive. It’s the only means we’ll have to stop new cloud security threats that will arise in the next few years.

Keep in mind that detection is more complicated in both hybrid and multicloud deployments. As you’ll discover in this chapter, cross-environment observability is key, considering that many times, these environments are separate silos, and it is often time consuming to try to track down what is going on in one system and how it is impacting the other. Security breaches can exploit these gaps.

Step 3: Respond

How do you respond to a detected attack or threat? There are many options. The system could simply disconnect and block an IP address, then back up systems and data just in case they are breached, turn off systems and data storage to stop an attack, or, my personal favorite, take punitive actions to go after the system that’s trying to breach. This means attacking back, which could become a more normalized approach than it is today.

Again, there are passive and proactive responses. For example, a passive response could automatically block an IP address, which seems more proactive. It’s done without much forethought, and it acts on other areas that may be vulnerable to a detected attack. This approach is passive because it normally takes place outside of the security system; it’s just something that’s triggered at the firewall and may or may not communicate back to the core cloud security processes and mechanisms. It may not even know that it’s responding to an attack or even let a human know that it’s occurring. This is an old-school-style cloud security response.

Proactive responses are much more effective and fun. A proactive response takes direct action that can take the fight to the attacker. For instance, the system could respond by tracing the origin of the attack and then work itself around mechanisms that may be hiding IP addresses. Once found, the system observes how the attack is being carried out and can even provide “bait systems” that exist in a virtual sandbox to help further identify the bad actors. When a profile is complete, the system stops access (obviously), interprets the knowledge of how the bad actors executed the attack, and automatically adjusts accordingly, often using AI-assisted processes.

The results? We learn more about the attacker and the attack, and the system adjusts our defenses so future attacks that fall within the same parameters are more likely to be spotted and stopped. Of course, many types of responses can occur. The system can change the encryption key, back up core data, force password changes and MFA for the users and external systems, update firewalls, and do any number of security tricks (do an online search for “cloud security threat tips” for the most recent information).

Step 4: Track

Keep a detailed log of everything that happens, including breach attempts as well as normal operations. It’s pointless to gather massive amounts of data unless we understand how to filter the data to work around the “noise data” or overly detailed data. The objective here is to provide enough monitoring and security operations data that it can be mined by observability systems, including some that may leverage AI. We discuss observability in more detail later in this chapter, but for now, understand that it’s key to cloud security’s future success. Observability can look at long-term monitoring data to denote behavior and identify patterns that can build better defenses for our cloud computing systems and data. As you learn later in this chapter, observability used with security is the key to taking security to the next level.

Data Encryption

Encryption is fundamental to any security system. It hides stored or in-transit (in-flight) information and requires an authorized key for users to unlock that data. This is how we ensure our data cannot be viewed by anyone who breaches the cloud, although that’s an extremely rare occurrence. Data encryption itself is not infallible, although it’s a good insurance policy to protect data access.

Encryption is critical to cloud computing and cloud security because we physically place our data on a system that we don’t physically control. If data encryption did not work, enterprises would not send their data to any public cloud.

Identity-Based Security

Second only to encryption is the ability to leverage identity-based or identity and access management (IAM) security. Everything and everyone receive a unique identity that allows or disallows access to specific fine-grained resources that also have a unique identity. Because users, APIs, storage systems, databases, data, and so on, have an identity, we have complete control over how they interact. We establish parameters to control how they work, what they can do, and how they function. IAM systems typically use directory services to track and manage these identities as a separate function from the security system.

IAM was not invented just for cloud computing, but they are complex distributed systems with many endpoints. You must configure cloud security systems to the specific needs of systems deployed in the cloud. Most traditional role-based security systems cannot deal with this kind of complexity.

Again, IAM is not perfect, but it’s currently the best security model you can deploy to cloud-based systems. The core advantage is that it’s extensible. The flexibility of IAM can deal with and adapt to complex cloud deployments such as multiclouds that manage three to six public cloud providers, thousands of applications, hundreds of databases, and hundreds of thousands of APIs.

Also, you should consider zero-trust network access (ZTNA). This cloud security solution provides secured remote access control policies. This approach and technology set differ from virtual private networks (VPNs) in that they grant access privileges to specific applications or services. VPNs, in contrast, grant access to the entire network, which can create more security risks. As the world becomes more work-at-home, this could be better technology to leverage, by cloud insiders.

Security Automation

Automation has always been a part of security, but cloud computing takes security automation to the next level. We can define behavior as well as status rules and policies. This capability is the only feasible path to success if you work with a dynamic set of systems in a constantly changing environment, which is the case with most cloud-based systems.

Again, the ability to react to security issues using automation becomes a game-changer for cloud computing security and security in general. Security automation allows us to harvest the powers of observability and AI. The three combined take security evolution a giant leap forward. We talk about security automation in more detail later in this chapter.

AI/ML Integration

Artificial intelligence and machine learning are changing the world. Cloud security is along for the ride. If you have trouble differentiating the terms, think of AI as a system that can teach computers to think like a human—for example, Siri or Alexa or Hey Google. ML is an application of AI that Siri, Alexa, and Hey Google use to develop their knowledge and intelligence ongoing.

Combined with security automation, AI has a special place in the world of cloud security. The ability to emulate learning, which is what AI does well, allows cloud security systems to proactively adapt and adjust to changes in security threats.

AI and ML were mostly science fiction for the last 40 years because they existed only in very advanced and expensive systems. I used them to create simulation systems in the 1980s. The price of AI dropped dramatically a few years ago, which put AI capabilities within reach for more pragmatic uses such as operations and security. These days AI and ML are feature-rich and almost free. Cloud security systems can now take full advantage of AI.

Remove Focus from Non-Cloud Systems

One of the biggest mistakes I see made is the failure to include non-cloud systems into security domains and frameworks. The result? Our public cloud deployments have great security. Everything is encrypted, we leverage identity-based security, we have advanced security observability systems in place, and we are sitting pretty. However, most of our company data and processes still reside on non-cloud systems such as legacy and traditional computing platforms that exist in corporate data centers. The systems running at the highest security risks are also the most neglected because all the good security thinking and technology went into the cloud-based systems. The non-cloud systems are the ones breached most often.

You need only look through the major breaches of the last 10 years to discover that clouds are rarely involved. Hackers found neglected legacy systems that presented much easier targets. I guess you can say that cloud made all systems less secure because it removed the focus from older systems to the point that they could be easily breached.

Figure 7-2 depicts how much native (isolated) security is done today, and I suspect this won’t change much in the next three to five years. Note how each type of system (cloud, legacy, and edge) has its native security layers that only deal with that specific type of platform.

Of course, the situation is never as simple as Figure 7-2 depicts. There may be two to five different types of security for each platform. Multicloud typically deploys with native security for each type of cloud (AWS, Google, Microsoft, and so on). Native database security also introduces more complexity, as do brand-name native network security, native container security, and so on. Although you can certainly deploy native security systems for each platform based on best practices and recommendations for those platforms, the complexity and silos you create lead to higher security risks.

The solution is to consider security as a more holistic endeavor, which isn’t easy. All parts of the architecture need to be holistically managed using cross-cloud and cross-platform security systems, observability, and orchestration that may or may not abstract native security (if needed). As we see later in this chapter, this dashboard-type security umbrella that covers all enterprise IT architecture is the cloud computing security evolution that will enable scalable security.

Failure to Manage Complexity

We’ve already beat the complexity issue to death in our discussion of multicloud, where complexity is the negative result. Security has the same systemic problem. The more platforms, systems, services, and native security systems that operate at the same time, the more complexity, which leads to more security risks. These risks come in the form of human and system errors because the sheer number of systems that need to be secured becomes more difficult to manage if you do them one-by-one or platform-by-platform, which is largely what we do today. More complexity, more breaches. Not good.

In Figure 7-3, notice how complexity, risk, and costs rise with more systems under management that must be secured. This figure depicts a multicloud deployment, but you could add legacy, edge, ERP, CRM, and other more traditional systems as well. The default response is to secure them using whatever native security is at hand, so the number of security systems and approaches builds more complexity and thus more risk and cost.

The reality is that complexity can’t be avoided, so it must be managed. The trick is to deal with complexity by removing as many moving parts as you can, such as native security systems. Combine them into more holistic security that can leverage the concepts and approaches of abstraction, orchestration, automation, and observability. Do this cross-platform at a logical layer that exists above all the platforms that need to be secured that include cloud but not only cloud.

Little Focus on BC/DR

Business continuity and disaster recovery (a.k.a. BC/DR). An old IT supervisor of mine told me to “back up anything that you don’t want to lose.” In those days, we used mag tape storage for offline backups, and it took hours to back up a single gigabyte of data. Of course, the one time someone on my team failed to back up data at the end of the day, we had a hard drive crash. Over a day’s worth of transactions were lost and had to be manually re-entered into the database.

These days, backup is an automated and seamless process. Indeed, as I write this book, each keystroke gets recorded on a cloud service, and I’m unlikely to lose anything if there is a system failure. BC/DR systems are cheap, but they often get left out of the discussion in security planning meetings, specifically cloud security planning meetings.

Many of the attacks these days will go after your data, and that fact makes backup a core security component. Ransomware attacks, for example, just encrypt your data in place and then demand that a fee be paid to buy the key that will unencrypt your data. Because many enterprises don’t bother to back up data to safe data storage units, the only recourse is to pay the ransom. However, sometimes the backups are encrypted as well if they are stored where the bad actors can access them.

I often see good cloud security programs with state-of-the-art approaches that lack a well-planned and/or implemented backup and recovery function. In many instances, customers assume that public cloud providers take care of backup and recovery. Beyond some basic systems maintenance and recovery services, public cloud providers do not babysit your data. If you accidentally remove your data, or your data gets corrupted, or someone encrypts it and demands money, you’re on your own. BC/DR needs to be systemic to all cloud security deployments. Unfortunately, it’s often overlooked or deployed with fatal flaws.

The most common word that follows the term BC/DR is plan. As in, have a BC/DR plan. Make it as bulletproof as possible.

Lack of Security Talent

Back to the talent thing. Many enterprises build and operate cloud security systems without qualified talent. The argument I often hear is, “We can’t find the right security talent, but we need to deploy the cloud systems.” So, they deploy the cloud systems knowing they lack the cloud security talent who would know how to best protect their systems. An unfortunate follow-up to this argument? Too often it’s some version of, “We were breached! Now what?”

There is a huge talent shortage when it comes to cloud computing in general and cloud security specifically. I suspect we’ll have a few ebbs and flows around supply and demand, but too many jobs will chase too few qualified cloud security candidates for the next few years. The impact of this shortage is depicted in Figure 7-4, where the demand for security talent rises over time. When supply can’t keep up with demand, the risk of a breach rises. More simple math.

We continue to build cloud systems that include cloud security (obviously), but we don’t have the on-staff security talent to make the critical decisions during the planning and implementation phases, or to effectively operate these systems ongoing. What we end up with are cloud solutions that resemble Figure 7-2, the siloed security defaults offered by providers because no one on staff knows how to design a systemic security system. Often, security pros on staff have a certification in cloud security for a specific cloud provider, but they’re lost when it’s time to look at solutions for other cloud platforms or other platforms in general. Or the longtime security pro who understands little or nothing about cloud security attempts to force-fit their go-to cloud security solutions into cloud deployments. After all, most security providers now claim to support cloud deployments due to the massive amount of cloud washing. Why wouldn’t it work?

My advice here is to get the talent you need. Either identify someone on staff who’s looking for new cloud opportunities and provide the education they need to grow into the cloud security role you need, or wait for the right person to show up in the outside talent pool. Don’t force forward progress without a good handle on cloud security, or all security for that matter. I understand that the inability to access qualified security skills will hinder progress while your timelines won’t change due to the talent shortages. However, the alternative sucks. Poorly designed and implemented cloud security solutions must be fixed down the road. That is unless a major breach takes out the company before the massive overhaul can be done. Taking the time to train and develop in-house talent in cloud security internships or waiting for the right outside hire will cost less in the long run. Oftentimes, much, much less. This is the part where leaders need to make tough calls.

The Movement to Cross-Cloud Security

As you can see in Figure 7-5, the move to cross-cloud security is the crucial first step to mostly non-native security. The use of multicloud drives the need for this configuration (as we covered earlier in this book), which drives the need for cross-cloud operations, governance, FinOps, and security.

Figure 7-5 shows how this will work. Notice the common layer of security that hosts security orchestration, observability (discussed later), access management, and directory services. It can perform common tasks in the upper layer (on the left) but can also incorporate native security systems (if needed). This allows us to leverage the best of both worlds, native and non-native. However, the use of native security layers doesn’t add complexity because we use them through abstraction and automation. We normalize security complexity using the cross-cloud security layer as well. The result of a successful supercloud/metacloud implementation is a command center that can control every part of the enterprise’s systems architecture. Welcome to the new bridge of your enterprise ship.

Security Peer-to-Peer Authentication

The growth of blockchain and Web 3 concepts (which we’re not going to discuss here) provides new opportunities for the future of cloud computing security. Blockchain successfully fueled the growth of the cryptocurrency market because it does not rely on a centralized technology stack and directory, but instead uses distributed ledgers that must agree with each other for a transaction to take place. A transaction must satisfy its peers before the transaction is allowed, which makes this pretty darn secure because the transaction trusts many through consensus rather than trusts a single entity that could be compromised.

I’m on many panels and podcasts that predict blockchain or something like blockchain will be the new standard for cloud security. Perhaps all security for that matter. Certain aspects of blockchain are already sneaking into cloud security systems, including new cross-cloud security systems that are available today. Many of the cloud security providers will likely replicate this model at some point. It just makes good sense. The peer-to-peer authentication approach seems to be the way to go for current and future cloud security.

Security Abstraction and Automation

We’ve talked a lot about abstraction and automation already, so the mention here is to make sure you understand that abstraction and automation have an application in cross-platform cloud security as well. Mostly we’ll see both concepts employed in cross-cloud and cross-platform security systems that need to simplify complex security using abstraction and provide automation to remove as many humans from the processes as possible. These become the saving graces of how to make many things work better. We talk more about automation toward the end of this chapter.

Security Intelligence (AI)

We can weaponize AI for pretty much everything these days, and security is no different. AI enables security layers to learn as they encounter breach attempts (both at the native and cross-platform layers), learn security operations over time, leverage observability to determine insights, and employ AI to interpret what it all means.

The idea is to set up these security systems to learn from the data gathered ongoing. As the systems learn, they gain insights into how to deal with normal and abnormal events encountered during security operations. For example, they have the ability to spot breach attempts using nonstandard approaches such as looking for CPU saturation that could indicate a cloud-based system is being employed for an attack. Ordinarily, this “red flag” could go unnoticed because cloud operations typically deal with straightforward performance issues, but there are many observable cases where breaches can be detected using an overarching intelligence that considers everything and learns as it goes.

Security Observability

We cover observability in the context of cloud security later in this chapter, so we don’t get too deep into it now. However, know that observability is key to cross-platform and non-native security. When we gather data for all systems in a security domain, which may span many platforms, we must pay attention to what that data means. Insights, trends, and analysis will help predict future security events that need to be managed or can provide raw learning data from past security events that may not have been detected at the time. As we learn how to figure things out in more proactive ways and focus on the intelligence-gathering features of systemic cloud security, observability will become the major league weapon for cloud computing security. We will no longer just react to events and hope to get to them in time. The crossed-fingers approach won’t work long term.

The Importance of Observability

Thus far, we’ve covered observability in the context of operations. The more we understand the insights we gain, the better we can do many things. This includes FinOps, operations, governance, and, yes, security. Observability for cloud security is the same as observability for anything else. We continuously gather data from everywhere and make sense of it by understanding any emerging security threats or those that may be more likely to emerge.

Figure 7-6 depicts an overview of observability and security, and the important features that allow you to put this concept to good use. These include

• What’s happening? What’s the current state of the systems? This covers security-related data and systems-related data as well—for example, the status of CPU saturation, I/O saturation, overall system performance, and network saturation. Anything that will lead to a trend, which leads to insights around that trend.

• What’s likely to happen? Based on current and past data, what is likely to happen in the future? Deep analytics and AI can provide insights into this data.

• How to defend? Based on what the system knows is occurring, or is likely to occur, what are the best courses of action? For example, the system could deny an IP address or move data access from one cloud server to another to confuse the attackers.

• How will it happen? What are the likely attack vectors and mechanisms that will be leveraged? These are solid leads to educate AI-assisted guesses.

• How can we stop this event in the future? What did we learn about this event, and what does it reveal when we include past and current data? What can be done to stop this from recurring in the future?

It’s interesting to see how observability works and why traditional security folks often avoid it when it’s time to deal with cloud security. It’s much more costly and time consuming to set up security observability systems, and the cost is often higher than the perceived cost of risk. Again, the ability to be proactive and leverage the concept of observability to defend your cloud-based systems is the only productive way cloud security will evolve. If you can’t afford it now, build it into the next budget and keep the focus on security observability goals. You’re looking at the future of cloud security.

Pattern Searching

Observability and proactive cloud security approaches find and track patterns. These could be patterns that indicate normal operations or patterns that indicate something is about to happen—for example, a breach attempt. Deep analytics and/or AI can find patterns and create insights to build appropriate responses to the patterns. Observability as a security tool provides the ability to monitor data and create actionable patterns, which is foundational to proactive security.

Most of today’s cloud security systems don’t search for patterns. This is something many other CloudOps tools and cloud operations teams now do, looking for the same proactive benefits. In this instance, cloud security teams could learn something from cloud operations teams regarding how data can become patterns and what those patterns mean to core cloud security systems. It’s most important to learn how to find patterns and understand what they mean, and then determine what can be done to avoid negative events that may occur as a result. The result of effective pattern searching will be proactive cloud computing security that continuously learns and improves.

AI

AI is now systemic to all that’s proactive. Yesterday’s too-expensive technology is today’s most efficient and effective key to all proactive security systems that must monitor and interpret mountains of data. One of the huge advantages of leveraging AI is that we don’t have to deal with data on the data’s terms. It’s humanly impossible to use manual processes to find patterns in the amount of data our systems gather and track these days. The patterns are difficult to understand even with advanced data analytics. AI can find meaning in data that we humans can’t see or sense. AI can then learn from the data and become better at understanding the data as time progresses.

AI still needs to be regarded with its limitations as well as its usefulness. AI systems don’t come to conclusions on their own; they must be trained. This training is done by humans who point the AI systems at data that can teach the AI system how to spot the patterns and trends they need to be proactive.

Things can also go wrong if you don’t understand how to properly train an AI system. Improperly trained AI could result in erroneous conclusions that fool the system into believing it’s protected when it’s very much not. Humans require a certain amount of expertise to properly train and drive AI systems. You and your team must navigate a clear learning curve to understand and implement effective AI-enabled cloud security.