However, since then, things have changed. Let’s revisit those predictions and make some new ones.

1. The Threat Landscape is Changing

2023: Not really.
2026: AI has entered the chat. 

For 2023 I wrote, “everybody will experience the same quality and quantity of attacks that we did in 2022. The technologies, personnel, and practices may change causing us to perceive security differently. However, the actual threats we face will remain mostly the same.”

For the most part, this prediction remains the same. The threat landscape in 2026 will be about the same as 2025, 2024, 2023, and so on. Malware is still a threat. Credential theft remains the primary focus of attackers. And hackers still have the upper hand in every way.

However, when we look at AI systems, there are tremendous changes in the threat landscape. Perhaps the most interesting of these threats are data poisoning attacks. These specifically target AI systems and large language models (LLMs) to produce flawed or misleading output. In 2024, NIST released an advisory about this kind of attack based on a study they conducted titled Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. This study is an interesting read. It is extremely thorough and even identifies some lingering cybersecurity challenges such as the dilemma of open versus closed systems.

The mitigating factor with this kind of treat is that it targets the AI platforms, and not the end users of those platforms. This limits the scope of this threat to a handful of AI platform providers, such as OpenAI, Google, Microsoft, etc. Furthermore, I could not to locate any confirmed instance of a data poisoning attack, however that does not mean it has not happened.

What is a larger issue are employees sending company data into AI platforms with no regard to the sensitivity of that data. This poses a complex challenge for organizations who want to enjoy the benefits of AI but need to protect sensitive data. It also poses a massive challenge for regulated systems under standards such as FedRAMP, CMMC, etc.

Fortunately, the industry is responding to this with ample technologies to manage, monitor, and control AI access as well as model context protocol (MCP) servers. Some examples of AI security providers in this space include Obsidian, Zenity, and Cyberhaven.

2. Executives Will Start Taking Security Seriously

2023: Probably not.
2026: No, and you can turn in your badge with security. 

For 2023, I wrote, “Information security is an esoteric threat to executives. They know it exists, but they cannot quantify it with clear consequences. They know it is serious, but they do not know how to dimmish the threat. They know harm is possible, but it is easy to dismiss it as somebody else’s problem.”

Around 2016 or so, I noticed that many executives would tune out the moment cybersecurity was mentioned. I had CEOs once tell me he was sick of security slowing down his company. Here we are a decade later and this attitude has only become more prevalent. A recent example of this attitude happened in early 2025 when the Trump administration wiped out the entire Department of Homeland Security’s Cyber Safety Review board. The message was unambiguous: security is unimportant. 

Executive indifference to security is a massive barrier for security startups. Leaders only care about security when it becomes a catastrophe. And all they really want is to find somebody to blame.

3. Companies will Commit to Stronger Security Defenses

2023: No, they will stick with “good enough” security
2026: Good enough is pretty good.

What I wrote for 2023 remains relevant. “It is not that executives do not care at all about security. They care up until the exact point they are on par with everybody else. This is the “good enough” approach to cybersecurity. Companies focus on doing what is an “industry standard” rather than doing what is necessary.”

Fortunately, “good enough” security is getting pretty good. One example of this was AWS’s recent announcement of their security agent product. This is a cool new AI technology that can scan an environment, locate vulnerabilities, and suggest improvements. While no AI agent will ever be as good as a skilled human penetration tester, for most organization, this agent is all they really need.

Another good example of how “good enough” has improved is Azure Sentinel. What used to be a mediocre SIEM and endpoint product, has evolved into a respectable security platform. Azure environments have Sentinel built-in, so Azure customers can access and use it easily.

4. We Will See a Megabreach that Cannot be Ignored

2023: We are already ignoring them.
2026: Megabreaches, what’s that?

I cannot even think of a megabreach from 2025 that had any significant impact. Apparently, Verizon had a massive leak in August, which they denied. Whatever. This is a classic “boy cried wolf” problem.

5. Security Staffing will See Improvements

2023: Not likely.
2026: Define “improvements.”  

For 2023 I said, “Cybersecurity does not have a staffing problem; it has a staffing crappy jobs problem. There are ample people out there who want to pontificate about all their grand theories of security. What nobody wants to do is actually run anything.”

The most significant change for 2026 is that AI is changing who companies are hiring. AI can do what a lot of security analysts and engineers once did. It even can write NGINX config scripts, which is something nobody can successfully do. (Yes, that’s a nerdy joke.)

AI can also do a lot of the grunt work industry analysts do, as Richard Stiennon has proved with his IT Harvest platform.

None of this is good news for job seekers. While the cratering US economy accounts for a lot the downsizing, AI is only making it worse. AI will never entirely replace humans, but organizations are testing the limits of that. Teams are being shrunk, and the remaining staff is expected to fill the gaps with AI tools.

This adds up to a bleak outlook for security staffing in 2026.

6. Cloud Eats Security

However, the ultimate prediction for 2026 is that security is everywhere, integrated into everything. In 2021, I identified a growing cybersecurity trend: Cloud Eats Security (also called “platformization”.) Cloud providers, like AWS, Azure, and GCP, and SaaS providers like Salesforce or ServiceNow, were (are) slowly consuming many of the traditional security capabilities (firewall, intrusion detection, vulnerability management, web-application firewalls, etc.)

The impact of this trend is that security is now integrated into the platforms companies use. Companies do not need to purchase individual point-solutions which demand complex and expensive integration efforts. However, even the point solutions are getting on board with this trend, making their products much simpler to roll out and fully integrated into cloud and SaaS offerings.

This was one of the reasons why Google paid $32B for Wiz in 2025. Wiz is a powerful platform that simplifies a lot of cloud security functions. Cloud security providers, like Cloudflare, are also rolling out new capabilities practically everyday. And some of those are free, such as Cloudflare Tunnels which allows anybody to securely host anything on the Internet.

To help monitor all these integrated systems, there are emerging AI-powered security operations products from companies such as AI Strike, Torq, and Dropzone AI.

If all this AI stuff seems unstoppable, and wildly insecure, well, it is. However, there are promising emerging technologies such as Automated Moving Target Defense.

And the final piece of this trend is the rise of automated, integrated managed security providers who can keep an eye on everything. In early 2025, I worked on an MSSP analysis project. I was stunned at how many MSSPs had fully embraced automation, AI, and the cloud in their offerings. Unless your organization is gigantic or a government agency, there is no reason to do security internally. Hire an MSSP. There are a lot of great ones out there that can further simplify security.

Conclusion

For 2026, I predict cybersecurity will continue down the path of more integration, more platformization, and more simplicity. This will not stop attackers, but it does swing the odds of success toward the defenders.

As for the attackers, like the rest of us, they are going to use AI to do their dirty work. And like the rest of us, they are going to generate a lot of pictures of cats playing pickleball. Which means defenders do not need some whiz-bang quantum oscillating over-thruster to stop them. They merely need to make the most of the security tools they already have.

NOTE: The companies mentioned in this blog are for examples only. I received no compensation for mentioning them nor do I endorse them or their technologies. 

The post 2026 Cybersecurity Predictions appeared first on Zenaciti.

PAN is not the first to try this strategy. Cisco, Symantec, and McAfee all tried, and all failed at building a platform of security products. Microsoft (MS) is well on their way toward a single security platform as well.

PAN’s strategy may be flawed, but the idea is not.

PAN correctly identifies that companies can benefit from a single, unified interface for security monitoring and management. However, their execution is the problem. PAN and MS are both building a Platform for Products. The PAN platform only manages other PAN products, and likewise for Microsoft. This makes these platforms limited and constrained.

What the security industry really needs is a Platform of Platforms (PoP).

What is a Platform of Platforms?

In an ideal world, cybersecurity teams would have a single portal where they could go to interact with their entire information security environment. This is a Platform of Platforms. A PoP would not necessarily manage every aspect of all those disparate products, but rather provide a simplified way to see their status, access key data, and perform routine functions. A PoP unites the entire security infrastructure into a single portal.

With a PoP, security teams could integrate any security product, whether it is PAN, Cisco, Wiz, MS, Crowdstrike, etc. into the platform. Those products would then publish a set of capabilities to the platform.

For example, the PoP would not manage an endpoint security product like Sentinel One. Yet, it could show a list of endpoints not secured along with other useful reports, such as malware blocked. It might also perform some common management functions, like kicking off a network-wide scan or search for a specific file-hash value.

The PoP is a window into endpoint security, but does not replace Sentinel One’s native management tools.

Now before you dismiss this idea, have you looked at ServiceNow or SalesForce lately? They are essentially PoPs.

PoP Drop

Naturally, you are shaking your head saying this is impossible. Ten years ago the management portals companies built for their products were completely closed. Now everybody uses an API, and those APIs are published (some publicly.) APIs are insanely powerful. They open up a product’s possibilities in ways most vendors cannot even imagine.

PoPs could use these APIs to interact with each product, to obtain data and execute functions. SIEM and XDR platforms have been building huge databases of functionality to accommodate a vast library of third party tools. This effort would only be slightly more complex than those efforts. Moreover, this is exactly the kind of problem AI could help solve.

Sounds like a SIEM

SIEMs are the closest relative to a PoP. The challenge with SIEMs is that they are focused exclusively on managing data from products. A PoP would go a step further to actually interact with a product’s native API. However, a SIEM would make a logical starting point to build a PoP. Some of the larger SIEM products are rapidly approaching a PoP-like functionality.

Who Runs PoP Town?

Naturally, the question is who owns or runs this PoP. No single security vendor could do this. Building a PoP would require a company with vast resources and a reasonably neutral position to the vast set of security products on the market.

This is why PAN’s platform is unlikely to succeed. It demands you buy completely into the Cult of Palo Alto Networks. PAN has made it clear they are not going to sell a platform that manages non-PAN products.

The obvious answer to who could do this is the cloud service providers: AWS, Microsoft, and GCP. They have the resources and are reasonably neutral to security products. AWS is already partially there with their Security Hub product. Azure has a security console now, but it is a clunky mess. And GCP has not been acquiring security companies for fun. They obviously have big ideas as well.

A PoP was part of my own vision for a product years ago. I envisioned a platform that could not only build itself but configure a disparate set of tools and provide a single management interface. My vision was too big for my funding, so I downgraded it into a compliance product.

PoP Benefits

The single greatest challenge in cybersecurity is and always has been complexity. The more complex a system is, the more difficult it is to protect it. Modern enterprise environments are insanely complex and insanely complex to secure.

The ultimate purpose of a PoP: create a simpler, more streamlined way to interact with the security architecture. Provide a single place where a diverse group of people, from leadership down to operations can access and interact with the security environment.

A PoP would not replace existing management consoles. Those would still have a place in a PoP environment. There are plenty of use-cases where administrators would need to drop down into a native console to perform administrative functions.

I fully admit that a PoP is a bit of a pipe-dream at this point. The effort necessary to build a viable, working PoP is extreme. However, this is yet another way that cloud providers could continue their consumption of the security industry (see Cloud Eats Security.)

NOTE: Since writing this blog in February of 2024 I have started seeing actual products making a run at this concept. Google’s acquisition of Wiz and Zscaler’s acquisition of Red Canary are two prominent examples of consolidation in the pursuit of an “all in one” style platform.

The post Platform of Platforms appeared first on Zenaciti.

A few years ago, I predicted that the large cloud service providers (CSP), like Azure, are slowly consuming security products and offering them as services.  This was not a prediction, but rather pointing out the obvious. This had been going on for years, starting with AWS offering web application firewall as a service.  With each passing year, the CSPs have expanded their security services.  For example, Microsoft added Sentinel, GCP built Chronicle, and AWS added GuardDuty.  Microsoft is particularly aggressive in bundling their security tools and capabilities into Azure and Office 365 platforms.

The CSPs already have the tools. They have the knowledge. They have the ability. Why not give customers free security as part of their hosting costs?

The free offering should be a complete defense in depth platform: endpoint security, vulnerability management, network firewall, intrusion detection, web application firewall, data encryption, identity management, and centralized log monitoring.  Unite them into a single console, offer them for free to any customer hosting workloads on the platform.

Why should they do this?

A Case for Free Cloud Security

While there are many reasons for free cloud security, there are three compelling ones that deserve attention:

1. It Would Show a Commitment to Security

CSPs are increasingly entangled in the security of their customers.  When there is a breach, customers are quick to blame the CSP.  AWS for example has a long history of being blamed for leaky data buckets, which is entirely unfair since they do not control the access rights.  Offering a complete suite of security tools, for free, would demonstrate a commitment to ensuring customers host their workloads securely. It also would allow the CSPs to integrate security tools into their templates and blueprints.

2. It Will Accelerate Cloud Adoption

Large and small companies routinely cite security concerns as a primary reason for not migrating to the cloud.  This 2019 story validates that thesis.  Offering free security would encourage a lot of companies (even enterprise sized ones) to move to the cloud.  Free security lowers the burden of relocating workloads to the cloud. It allows companies to more quickly build secure environments that can host sensitive workloads.  It may also convince companies that fear cloud adoption that it is safe.

3. It is Good Business

Free security would not come cheap for the CSPs but it would increase billings.  One of the things I noticed when I helped customers move workloads to the cloud, was that security drove additional spending.  Once an organization was comfortable with the security of their platform, they were comfortable moving more workloads into the cloud.  Moreover, there was a natural sprawl of usage. In one customer, I recall their AWS billings more than quadruped when we deployed strong security controls.

Free security makes cloud hosting more attractive to customers.  It also reduces a customer’s expenses. That frees up budget for more cloud spending on instances, databases, and other services.

Drawbacks

What about the existing security vendors?

Their business would erode.  Stand-alone security vendors like Crowdstrike, Qualys, or Palo Alto Networks would see some lost business. This means they would need to adapt to offer more advanced security capabilities beyond the baseline.  That is still good for the rest of us.

Can we trust CSPs with security?

We already do.  Our data is already at these CSPs.  You think all those SaaS application subscriptions you purchased are running on some Dell server in a data center?  They are running at AWS or Azure.  I have seen the security operations at these CSPs. They do a significantly better job at security than 99% of the organizations out there.  They have to, otherwise customers would abandon them.

It Creates Platform Lock-in

That already exists. For all the talk of “multi-cloud” strategies, extremely few organizations implement them.  Multi-cloud strategies are insanely expensive.  This would not fundamentally alter the lock-in issue.

There is No Way AWS Could Compete with the Likes of Palo Alto Networks

They do not have to. This is not about building the best security tool possible. This is about building a capable set of tools that can deliver a reasonably acceptable security baseline. Again, think Microsoft Defender. Is it the best AV on the market? No, but it is better than nothing.  For smaller to mid-sized organizations, it is completely adequate.  A free cloud security platform would offer an adequate set of tools, not top-of-the-line stuff.

What is Good for One, Is Good for All

There is one more compelling reason for cloud providers to offer security for free – it is the right thing to do.

Decades ago, the Bill and Melinda Gates Foundation began funding immunization efforts in developing nations.  Eliminating curable diseases was not only good for the people, it was good for all of us.

Microsoft did something similar.  It began bundling Defender Antivirus with Windows. Initially the product may have had weaknesses, but it spread anti-virus to the masses.  Entire strains of common malware disappeared.

Cloud providers are in a similar position.  They could make their platforms stronger and more desirable with a complete, bundled security platform.  Then small businesses, non-profits, and governments world-wide could operate more securely.  Which is good for us all.

AWS, Microsoft, and Google, you can make this happen.  Do it.  Do it for your own interests.  Do it for ours.

The post AWS, Azure, and Google: Make Security Free for All appeared first on Zenaciti.

You bought a froduct, a product that is really a feature or collection of features. Froducts are everywhere, but they are particularly pervasive in cloud and security market. Free flowing funds has fostered fertile field for founders flaunting froducts.

What is a Froduct?

For something to be a froduct, it must meet two criteria:

1. Limited Use. Security and cloud froducts target specific needs, such as compliance, data replication, or incident response.
2. Dependencies. Froducts depend on other technologies, systems, or people to work properly.

Froducts are not necessarily a bad thing.  In fact, many innovative technologies begin their life as a foduct.

One example of a successful froduct was Portshift. This Israeli company made a Kubernetes security product. Their product, like many container security products, was really a collection of existing Kubernetes and cloud capabilities. You could do almost everything Portshift did with existing open source tools. You also had to have a containerized application environment — limited uses, critical dependencies.

Portshift brought these features together into a product, racked up some wins, and got acquired. Investors put in $5 million and Cisco paid approximately $100 million for the company (the actual amounts remain undisclosed.) That is a 20x return on capital. A fabulous froduct finish.

While froducts are great for founders and investors (when they work), they are not always so good for customers. Froducts can create as many issues as they solve. Yes, you have security mesh on your containers, but who is going to define, manage, and monitor that? Container security mesh, like many other security froducts, is a great idea that is difficult to implement successfully. Froducts often make lofty promises of efficiency, security, and reliability, that are difficult to fully realize.

So where do all these froducts go?

Cloud Eat Froduct

In my recent analysis article, Cloud Eats Security, I described how the Cloud Service Providers (CSPs) such as AWS or Azure, are gobbling up security capabilities.

For example, consider Web Application Firewalls (WAF). A decade ago, WAF was a thriving market, with multiple big players like Imperva and F5. Now, WAF is a few clicks on your AWS, Azure, or Cloudflare console. There is really no reason to buy a WAF anymore.

Cloud providers are slowly gobbling up froducts. Bundling them up into their offerings and making them easier to implement. While their versions of these technologies may not be as good as the stand-alone ones, it does not matter. They are good enough. Like it or not, that is all most buyers want.

Go to Froduct Market

For every froduct that clocks in a 20x return, there are hundreds that merely burn investor cash. The core problem with these places is they have their go-to-market efforts completely wrong.

Security and cloud froduct companies keep struggling to solve security or cloud problems. They put out endless marketing fluff about hacking, peace of mind, and attack surface areas but fail to address the real question that buyers want to know: what business problem do you solve?

Security problems are small, nuanced, esoteric pixies that require lengthy explanation, education, and endurance to comprehend. In contrast business problems are lumbering leviathans that even the most clueless investor can understand. For example…

Business problem: we need money.

Security problem: we need to restrict access to specific users, with approved session tokens.

A security froduct might be innovative and effective, but if it creates any kind of impediment to revenue, then who cares. Startups with froducts need to look way beyond the cool thing they do and think about what those cloud service providers are doing.

Froduct Packaging

The reason AWS can get away with a subpar WAF is because the totality of AWS is more valuable than the individual components. AWS’s value is not in their security or compute capabilities, it is in the platform.

Or another way to say this, AWS does not solve compute problems (or security ones for that matter), they solve business problems with computing products.

Startups can use this same technique to make their languishing froduct more useful and valuable.

For example, which one of these product pitches do you think work better on a C-level executive with limited budget?

Our cloud deployed IAM product integrates with your on-premise Active Directory to synchronize user identities across cloud environments. It can reduce unauthorized access and protect data.

Our product keeps your people working earning revenue.

Do not sell the froduct, sell the better future the froduct (on some big platform) delivers. Froducts, packaged together, to solve large scale problems are irresistible to leaders who want to contain costs. Moreover, they alleviate pain.

So, what are some of these large, business problems? There are only a few of them.

1. People: expensive, fickle, smelly, hungry
2. Money: never enough of it
3. Time: never enough of it

If your froduct platform can replace people, save money, and/or reduce time to success, then you have a winner. If your froduct requires a company to hire more people, pay more money, or consumes more time, you have an uphill battle ahead of you.

Conclusion

When you go shopping for new security products, take the time to consider the dependencies.  You may be buying a froduct.  Likewise, products that integrate with existing platforms, like AWS or Azure, are naturally more effective since they can work on existing environments.

If you are a product company, then you must be able to place your product into the context of a customer’s environment.  Stop talking about the security challenges you address, and start talking about how you will improve the customer’s experience. You can still talk about those security benefits, but only after you and the customer are clear on the business problems you solve.

The post Rise of the Froduct appeared first on Zenaciti.

The client’s information security officer did not like my strategy.  I defended my approach adding that the cost of the investigation was not worth it.  Unpatched systems were the likely culprit.

My pitch was ineffective, and the company chose to hire a well-known incident response company instead.  They blew through a few hundred thousand dollars to uncover that their developers did not patch their servers, bots are quick to exploit vulnerable Apache installations, and their security tools are largely unmonitored and unmanaged.

This story highlights one of the more enduring challenges in information security: attack detection and response is complex, expensive, and seldom rewarding.  This company did not discover any giant conspiracies.  They were the victims of a garden variety attack.  The downtime and investigation were expensive and debilitating.  The culprit of the vulnerability was obvious: inconsistent system maintenance and weak security controls.

Challenges with Endpoint Security

While modern endpoint detection and response (XDR) products like Crowdstrike have come a long way at detecting, identifying, and stopping attacks, these platforms still demand a lot of care and feeding.  Companies spend millions each year desperately trying to stop and clean up after attacks.  Often this results in no insights, other than the organization has security vulnerabilities, like every other organization on earth.

What if none of this mattered?  What if, as I suggested to my client, you could destroy and rebuild an environment automatically based on a schedule or triggered input.  Attackers need time to infiltrate systems, move latterly, and exfiltrate data.  If compromised host(s) vanished every few hours, hacking the environment would become enormously difficult (although not impossible).

This is the premise behind Moving Target Defense (MTD). 

What is Moving Target Defense?

MTD, despite being a emerging technology, is not a new concept.  A group of security researchers wrote a detailed book on the topic in 2011: Moving Target Defense, Creating Asymmetric Uncertainty for Cyber Threats.  This book is a bit dense and written before container technologies existed.  However, these researchers had a sound premise, even if the technology at that time was not fully capable of realizing those ideas.

MTD products create a compute environment that is dynamic and non-persistent.  If a host or application is compromised, it is quickly destroyed and replaced with a known-good version from a trusted, read-only repository.

MTD currently comes in two flavors: infrastructure and endpoint.

The endpoint versions work internally within an operating system to randomize memory, isolate the core processor, and prevent unauthorized applications.  This makes the individual system more difficult to crack.  I am hesitant to call these products MTD, since they are merely endpoint products with specialized detection and protection capabilities.

Infrastructure versions work on a larger scale to constantly wipe and rebuild the components of an environment.  These technologies are particularly effective in containerized environments.  A properly architected Kubernetes or OpenShift environment, can become extremely resistant to attack using MTD.

In my opinion, I think it is a stretch to call endpoint products MTD.  These are merely XDR products with MTD-like features.  True MTD must happen at the infrastructure level.

What is so Great about MTD?

MTD is a profoundly effective defense because it is simple.  It shoves aside all the complexities of detection, response, and incident handling.  Rather than try to figure out how a system is hacked, MTD makes a hacked system irrelevant.

Moreover, MTD does not invalidate existing detection and response tools.  It reduces the dependency on these technologies and can augment MTD capabilities.  When MTD and XDR are paired together, the endpoint tools can trigger a rebuild based on the detection of an attack.

Why MTD Now?

The reason MTD has come of age is due to advancements in adjacent technologies.  In the past, traditional hardware environments could not handle the dynamic nature of MTD.  Virtualization brought MTD closer to reality, but was still clunky and unreliable.

With the advent of containerization, MTD not only becomes possible, but preferrable.  Individual containers or pods can be trashed and replaced in a blink.  If the application is architected properly and stores persistent state information in a database (and not on a filesystem) there is no functional limit to how often systems are refreshed.

As more companies move their compute workloads on to Kubernetes, Openshift, and other containerized platforms, MTD becomes a more viable security option.

Who Are the Players in MTD

There are few.  As of December 2022, there is one lone company (I could find) with an infrastructure MTD product: R6 Security, out of Palo Alto.  Their Phoenix platform works with Kubernetes as well as RedHat’s Openshift platform.  It can work on a schedule to refresh the environment or configured to interoperate with other container security tools.  I have seen this product in action, it is slick.

On the endpoint side, there is Morphisec. They claim to have a lightweight agent that performs core isolation, randomization, and other endpoint security enhancements.

What is the Future for MTD?

In a recent post on LinkedIn, Lawrence Pingree, Vice President of Emerging Technologies for Gartner announced that 2023 will be the year of Moving Target Defense (MTD). This is a bold claim for a nascent technology.  However, I think Pingree is right.  The conditions are right for this technology to take off.

With organizations moving more of their core workloads into containerized environments, it only makes sense to use MTD.  Moreover, MTD bundled with other security capabilities creates an extremely resilient environment.

However, now that Gartner has said MTD is hot, expect a lot of other security companies to suddenly “add” this capability to their product.

The Bad News about MTD

MTD is not a panacea that will solve every security problem everywhere forever.  There is one, big gotcha with MTD: application architecture.

For MTD to work properly, the application environment must be architected to handle constant change.  This means using rest APIs and microservices, rather than traditional monolithic applications.  It also means persistent information, cannot be stored within a container or on a filesystem.  It must be stored in a shared repository such as a database.  Moreover, state information must be isolated and protected, such that an attack could not break through the MTD layer, into the backend environment.

One fear I have about MTD is how it can break applications.  This is why many endpoint products with these features struggle for traction.  They offer all these novel memory and processor randomization tricks, that crashes regular applications.  They quickly devolve into a configuration mess of whitelisting specific functions, which kind of negates the whole point of MTD.

This is why I believe the future for MTD is in infrastructure products and not endpoint.

Conclusion

What captivates me most about MTD is that it disrupts the entire hacking environment.  Rather than trying to outsmart the hackers (which has consistently proven to fail) MTD devalues the hacker’s advantage.  It does not merely level the playing field, it wipes the field out and replaces it with a new, fresh, clean one eliminating all the hacker’s clever attacks.  MTD also forces an organization to architect their applications in a more modular, resilient manner.

MTD might not be the panacea that solves everything, but it has the potential to disrupt the security market as much as it disrupts the hacking environment.

The post Moving Target Defense Is Set to Disrupt Endpoint Security appeared first on Zenaciti.

Over the past 20 years, cybersecurity has played an unwinnable game. In this game, the attackers make all the rules, score all the points, and can quit anytime without losing.

Meanwhile, the defenders are encumbered with a cavalcade of rules, tools, and fools: insidious compliance rules that drag down progress, a messy assortment of security tools that never work together, and company executives that dismiss security as a nuisance inhibiting their success.

If you have ever had to implement enterprise information security you know that it is not merely difficult, it is profoundly difficult. However, what is the alternative? Companies must defend themselves. And so, security professionals diligently persevere. They buy new tech, hire more people, and fight enemies inside and out. After a while, the virtuousness of their perseverance becomes indistinguishable from insanity.

Beyond Human

The crux of this Unwinnable Game is that protecting modern IT systems exceeds human cognitive abilities. Information security, even for a modest sized organization, is insanely complex, volatile, and error-prone. This has left CISOs playing a game they can never win. See more about What is Wrong with CISOs.

If humans cannot handle security, then who or what can? Automation? Artificial Intelligence (AI)?

AI and automation both have tremendous potential to make security less complex and more reliable. Automation tools can repeatedly (and tirelessly) analyze data to identify outliers and potential attacks. AI can, theoretically, adapt to changing environments.

Unfortunately, these tools have massive hurdles to adoption.

First, implementing AI and automation are well beyond the technical capabilities of most security teams. Most security teams struggle to maintain basic hygiene. Expecting them to install, tune, and manage complex AI technologies is unrealistic.

Second, these tools demand standardization. Environments with disparate systems are impossible to automate and confound AI engines.

Lastly, AI engines demand vast amounts of data to build accurate propensity models. This means the engine must have both abnormal and normal data (and anything in between). Most security technologies discard or ignore normal data, favoring the abnormal. This is because the humans who manage those security products cannot handle the onslaught of both normal and abnormal data.

Introducing Platformization

This is the point when cloud providers, like AWS, Microsoft, and Google, as well as large SaaS providers, like SalesForce and ServiceNow join the chat. Cloud providers have huge advantages in regard to automation and AI. They are skilled at taking technologies and processes, and transforming them into standardized, easy to implement, and automated services. AWS has the people, purpose, and scale to build AI engines. Mostly, cloud providers have a huge advantage over the point players, like Crowdstrike or Splunk. Cloud providers can see everything, normal and abnormal. This makes them a logical place to implement security.

The reason computing workloads are moved to the cloud is because the cloud providers simplify complex technology into standardized services. Cloud and SaaS have already consumed entire markets, such as email. Ten years ago, if you needed an email server, you had to setup, manage, and secure your own. Today, with a few clicks and a script you can have an enterprise class email system at Microsoft or Google, pre-configured and secured correctly. There are few reasons to run your own mail server these days.

Security is no longer an add-on product. It is inside the platforms companies already use.

The New Cloud Order

By 2030, security will inside the platform, not outside it. These integrated services will extend out to endpoints and IoT devices as well. What we know today as the security industry, with thousands of vendors all selling point products will dramatically change. It will be more about integrating capabilities into existing cloud and SaaS platforms.

This trend is already in motion. The impact of this shift will be felt far and wide. Some of the things we can expect include:

• The demand for point security products will not disappear, rather it will move down-market to SMB and laggard industries that refuse to adopt the cloud.
• The market valuations for security point solutions will decline as they run out of customers.
• The demand for in-house security expertise will decline. With cloud services and AI doing much of the dirty work, in-house teams will have less to do. This will make the security roles less about twiddling with tools and more about managing risk posture throughout the organization. This will also fuel expansion in the managed security segment.
• Since everything in the cloud can be automated through an API, a new class of value-added resellers will emerge: automation integrators. These providers will repackage automations between different providers. They will offer pre-built architectures, with your preferred vendors (like ServiceNow or Salesforce) pre-integrated. With a few clicks you will be able to build an entire enterprise infrastructure with everything tightly integrated.
• The market for managed security providers (MSSP) will grow, however they must adapt to work with the cloud. The traditional MSSP, with a big SOC managing hardware devices, will be less relevant. MSSP will also move down-market into SMB environments. It will be less expensive and simpler for organizations to outsource security monitoring than attempting to do it in-house.
• Demand for stand-alone security awareness and application code scanning solutions will remain stable or increase. These services are difficult for cloud providers to adopt, due to the customized nature of them. However, security awareness training has already moved to cloud-delivery. Likewise, most application code scanners have SaaS delivered versions as well.
• Hardware security products must refocus on access, with tight integration to cloud services. Many of the hardware vendors, like Palo Alto Networks and Fortinet have already begun this transition.
• Compliance will be devalued. Compliant environments can be built, certified, and authorized through automated means. Compliance bodies will resist this at first, but the cloud providers will strong-arm them into adopting. You already see the beginnings of this, with the FedRAMP office push their standardized OSCAL language.
• Multi-cloud will become more difficult as cloud providers find more ways to create lock-in strategies. This will also increase the need for automation integrators, which can smooth out multi-cloud adoption complexities.
• Attacks and ransomware will shift focus to “softer” targets such as laptops and IoT devices.
• AI engines will become increasingly more capable at identifying new attacks. However, people will need to manage the response and remediation.
• Automation will extend to remediation tools. Cleaning up an intrusion will no longer require expensive engagements with outside consultants. Rather, automation tools will gather evidence, wipe out affected systems, and rebuild from known-good repositories.
• Risk management will become more important to companies, as they shift from a purely reactionary approach to that of controlling risks.
• Watch closely anybody AWS, Azure, Google, Salesforce, Service Now, Oracle, SAP etc. acquires. They will start vacuuming up technologies that will serve this change. AWS has already done a few.

Evidence

The evidence of this movement is already out there.

• Microsoft Azure has their own Security Event and Information Management (SIEM) product: Sentinel
• AWS has rolled out Guard Duty and WAF, rendering the need for standalone WAF or IDS/IPS less relevant.
• Google’s Chronicle integrates multiple security functions as well as some AI capabilities.
• At re:Invent 2022, AWS announced Security Lake a new SIEM product similar to Chronicle and Sentinel
• Google purchased Wiz, with the intention to integrate it into their cloud offerings.
• AWS announced Security Agent, an AI-based vulnerability identification and remediation tool.

Counterpoints

Of course, this trend will encounter resistance from all those vendors. Just as hardware vendors ignored the writing on the wall in the early 2000s, so too with the sea of booths at the RSA ignore the rising cloud waters around them. However, let’s consider some contrary points.

Cloud services are not as accurate or capable as dedicated point solutions.

This may be true, but it does not matter. The cost and complexity of implementing, optimizing, and managing point solutions is already higher than adopting cloud-native tools. Moreover, the quality of a product is largely irrelevant in the grand scheme of protecting a business. Most of the companies that experienced a large data breach possessed cutting edge security technologies. It is not the technology that protects a company, it is how the technology is implemented, managed, and monitored.

Cloud providers are incentivized to ignore or cover up security problems. You cannot have the fox guarding the henhouse!

Pushing the farm clichés aside, this is untrue. Cloud providers are under tremendous legal, regulatory, and reputational pressure to secure their services. For example, a few years back AWS took heat for customers with public S3 bucks. Even though this is a legitimate configuration, and customers are entirely responsible for setting this access, AWS still implemented improvements to lock down S3 buckets even more.

Furthermore, if you are going to entrust the entirety of your company’s data and processing to AWS, why can you not trust their security? Lastly, cloud providers are deeply incentivized to protect customer’s workloads for one less savory reason: lock-in. If a cloud platform is consistently having security issues, customers will leave and move to a competitor’s platform.

This is monopolistic, many organizations will reject using cloud-native security tools leaving a market for point-solution vendors.

Yes, some companies will resist, however this will not stop the cloud providers. Those companies that resist will be at a disadvantage. Security today is an insanely inefficient and error-prone precisely because there are too many tools which are difficult to interoperate. Automating and standardizing security is the only way to contain this expanding inefficiency. Those companies that resist, will lose the efficiency and effectiveness gains of those companies who do adopt the cloud-native security tools.

The follow-on question for this is: at what point do the cloud providers transform from merely providing a compute service, to being a utility. Where are the limits of their reach? That is a larger, complex question for another article.

Conclusion

Information security is stuck playing a game it will never win. However, unlike the sage wisdom of Wargames which suggested the only winning move is not to play, we do not have that choice. We must defend our data, our infrastructure, and our nations from cyberattacks.

Information security teams can win this game, if they leave defense to the robots. Only automation can adapt, react, and protect at the scale necessary to defend an enterprise. And only the cloud providers have the scale, resources, and motivation to be able to build these robots effectively.

This was originally published in December 2021 and revised a few times since then.

The post Cloud Eats Security appeared first on Zenaciti.

Despite my cynical introduction, I am a fervent believer in Zero Trust. Zero Trust environments are fundamentally more secure and resilient. What annoys me is the hype.  Whenever any technology or technique becomes popular, the marketeers overpromote, overpromise, and overstate the benefits (and understate the challenges).

If you know better, you know that Zero Trust is complex. With that in mind, let’s stick our hands into the Zero Trust hype machine, scrape the marketing goo off the gears, and see what makes Zero Trust really tick.

What is Zero Trust?

While many of you reading this already know what Zero Trust is and do not want to read yet another pandering explanation, indulge me for a moment.

Zero Trust is a ridiculously overhyped word these days that gets slapped on everything including products, features, cloud services, and entire companies. This is where the first problem lies: Zero Trust is not a product, not a service you subscribe to, and definitely not a company. 

Zero Trust is an architectural design approach.  I prefer the word, Zero Trust Architecture (ZTA).  Zero Trust is something baked into every part of your infrastructure and applications.

The alternative to ZTA is Castle Defense Architectures (CDA).  CDA was how most of us built corporate networks in the past: strong perimeter, soft interior.  This typically manifested with a NGFW at the perimeter, with some internal monitoring inside the trusted zone.

Concisely, CDA explicitly trusts some things, while ZTA trusts nothing.  Apple devices are a good hardware example of a ZTA, as are cloud providers like AWS and Azure.

ZTA is inherently more secure because, to state the obvious, nothing is trusted.

Where Zero Trust Comes Unglued

Unfortunately, Zero Trust is difficult to adopt, challenging to maintain, and perpetually locked in a tug-of-war with those pesky humans and their penchant for doing dumb things.  In other words, it is like everything else in security.

Furthermore, Zero Trust is different for application environments versus corporate environments.  To keep things simple, I am going to focus on application environments.  Corporate environments with all their laptops, printers, and other technical detritus face the same challenges, just in a larger scale.

Let’s unpack these three ZTA challenges.

Start Vulnerable

Ever spent time with developers?  These are not people who like a lot of restrictions.  Developers need freedom, and rightly so. Building apps requires the freedom to tinker and test out multiple designs. This makes it difficult to implement the restrictions necessary for ZTA environment in the middle of development.

Most organizations develop applications in “full-trust” environments that have no access restrictions or security controls. Only after the environment is built, do security and DevOps teams attempt to impose security controls on the environment.

This approach creates a positive inclusion coefficient.  That is a fancy sounding way to say it is difficult to find all the holes.  This is because the environment starts in a vulnerable state and to get it to a secure state, engineers must locate all the possible vectors of compromise.  The number of exploit vectors grows in a non-linear manner (possibly exponentially) with greater complexity.

However, if the devs embrace ZTA and make tuning security controls an integral part of the development process this creates a negative inclusion coefficient.  Rather than trying to identify the vast number of ways an environment might be exploited, devs focus on the smaller amount of access rights necessary to keep things running correctly.

However, even if you start with a ZTA you still must maintain it.

Stay Vulnerable

Application environments (as well as corporate networks) are not static. New features, component updates, expanded access, patches, new devices, new employees, additional customers…the list of possible changes is long and dynamic.

This gets us back to that positive inclusion problem.  The more things change, the more difficult it becomes to maintain the complex access rights of ZTA.  If you have ever managed a corporate perimeter firewall, you know exactly what I mean.  You start with everything locked down and secure. Then little by little, over time, access becomes loosened. It starts with some third-party vendor requiring a bunch of weird ports for their crappy software. Next it is an update to some internal system that needs a group of people to have unrestricted admin rights.  Then it is the CEO’s pet project that demands a dangerous “any-any” rule.  In a brief time, the NGFW is essentially useless.

Oh, and incidentally, this is why breaches happen.

To solve this problem, you must have “custodians” of the environment, who can monitor for issues and maintain the security controls.

Now, scan through all that marketing blather from ZTA companies. Do you see the word “custodian” in any of them?  Of course not, because imagine a product pitch that said: Our product will secure your business and give you a tedious job that is profoundly unrewarding, and if you make a mistake, you will be fired and humiliated!

Which drops us into the lap of the third challenge.

Stop Being Human

Humans make mistakes.  I do not think that is a remarkably controversial statement.  Human error is the Achilles Heel of Zero Trust.

Remember back when AWS was getting all that negative press about S3 buckets being public on the Internet? AWS S3, like most of AWS, is a Zero Trust service.  When you setup an S3 bucket, it has no rights.  It starts in a secure state.  Humans must overtly reconfigure S3 to be public.  This happens all the time.  This is how S3 buckets become sources of attacks.  It is not AWS’s fault.  Their service follows ZTA practices. It is the humans operating those services who make mistakes.

Those pesky humans. They create the problems and they also can solve the problems. The answer to this is to require identity validation at every stage, which is great…except when it gets turned off because of all those pesky humans.

The Bigger Picture

If all this feels depressing, then allow me to quote Gale from Raising Arizona, I’d rather light a candle than curse your darkness.*  There is a way out of this ZTA muck and it does not require robbing a store or putting a panty on your head.

The answer is frustratingly simple and immensely complex: Zero Trust is a strategic business challenge, not a technical challenge.

The technology of Zero Trust is everywhere, inside everything.  If you are making Zero Trust a technology project, then it will probably get watered down and sputter out in the long run.  Zero Trust is a cultural or business problem.  Zero Trust must be embedded into all your code, all your teams, all your people, and all your designs.  You cannot buy a Zero Trust thing, slap it on your stuff, and then proudly proclaim your application as secure.

Your organization’s ability to adopt Zero Trust is more a factor of your organizational culture than what technologies you use.  If your leaders truly embrace Zero Trust vision, specifically the need to automate everything, then you have a good chance at being successful.  If you are still doing things manually and/or allowing vendors to control your architecture, it will be a rough ride.

Getting Past the Zero Trust Hype

So now what?  To get past the hype, you need to honestly consider some key prerequisites to Zero Trust:

• Is your environment in the cloud (AWS, Azure, etc.)?  ZTA is practically impossible in old-school on-premise environments.
• Have you automated your architecture? Build, test, inventory? Better get on that HI!  No point in twiddling with ZTA tech until you have a fully automated environment, because manually managing access rights is a nightmare. And you might be carried off by a twister.
• Have a bunch of third-party dependencies in your environment. Do you know exactly what access they need?
• Do you have real-time asset inventory? This must be an inventory of everything, and not some spreadsheet on the IT admin’s desktop.
• Can you automate the testing of access rights, vulnerabilities, and configuration? This cannot be dependent on some unhappy dude clicking the correct buttons at 4:00am.  It must be automated.
• Is user (and system) identity validated at every point in your app data flow? It must be.
• Do you have a team of people who can effectively run the environment 24/7? Why burn zillions building an app only to put it in the hands of underappreciated, overworked, and chronically devalued IT admins. The people who run app environments are as important (if not more so) than the people who build them.
• Is your leadership have the vision to adopt Zero Trust?

That last item is the clincher.  Your team (and leadership) must commit to ZTA.  Do not waste your time twiddling with Zero Trust technologies if your team will bypass the security and cut corners at a moment’s notice.

When you peel back the Zero Trust hype what remains is something non-technical: vision.  Does your team have the tenacity and commitment to build, maintain, and monitor a Zero Trust environment? Is security engrained into your culture at every level?

If so, then go get some of those cool Zero Trust tools. If not, then all the tech, subscriptions, fancy words, and promises in the world are not going to plug those holes.

Well, okay then.

* Yeah, I know. That quote is originally from Eleanor Roosevelt and not Gale.  Raising Arizona was funnier.

The post Beware of Zero Trust Hype appeared first on Zenaciti.