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.

Consider something as common as television. For decades, there were only 3 channels with limited content. This was because broadcasting TV signals was expensive and highly specialized. In the 1980s, cable TV standardized the transmission of signals over coaxial and fiber cables, unleashing innovation and deregulation. Today, we have hundreds of channels and vast choice. Standardization (as well as technology improvements) made that happen.

From shipping containers to application containers, standardization is a necessity for innovation and scale.  

Non-Standard Security

For all the innovation in information security, there is little to no standardization.  There are some technical standards, like STIX and TAXII for intelligence sharing.  However, these are limited in their scope.  Security has no standards to govern the configuration, documentation, and auditing of security controls. This is where all the problems live. 

Now, you may think that compliance standards, like PCI or FedRAMP provide a standardized way to implement security. Yeah, no. Compliance frameworks describe an ideal state in generic terms.  Compliance tells you that you must have a control, it does nothing to help you deploy, configure, manage, or audit that control.  Furthermore, it is (relatively) easy for an organization to skirt around compliance requirements and still pass an audit. This is because audits remain a subjective assessment from a person.  

The sheer vastness of the security technology universe also complicates standardization .  Take a moment and visualize the vendor expo at RSA Conference or BlackHat. What you see are thousands of security vendors. Yet, each vendor only solves a fraction of an organization’s security needs.  SIEM vendors focus on logs and analysis needs, endpoint security defends against ransomware and viruses, GRC vendors create work for people. Each vendor only plays one part in an organization’s entire security program.  Nothing holds this mess together.  

What we have is a chaotic mess of security tech with no standardized way to configure and validate security controls. Consequently, security is entrusted to people who make mistakes and vendors who have agendas. 

This mess has real world implications, namely breaches.  The root cause in every breach is misconfigured or missing security controls (which ultimately is human error).  The recent Colonial Pipeline attack was the result of attackers stealing a single password to a dormant VPN account.  Multi-factor authentication, robust network malware, stronger endpoint controls, and zero trust access would have all worked to stop this ransomware attack cold.  However, those controls either did not exist or were not configured properly. There is probably some former security person from Colonial Pipeline furiously posting to Twitter: “I warned them this would happen, but they ignored me!!!” 

If there was a standard way to implement, configure, and validate security, then an organization like Colonial Pipeline could have implemented all these appropriate controls without depending on people to do it correctly (which they obviously did not).  They could simply follow a script. 

However, I am not suggesting eliminating or consolidating all those security technologies.  Rather, I am suggesting a standardized way to configure and validate security controls. Or in other words, a universal “language” that abstracts the configuration, validation, and documentation of security controls from specific vendor tools.   This is similar to how Hashicorp’s Terraform, AWS’s Cloudformation, or RedHat’s Ansible work.  These are languages (or platforms) that build and configure cloud services and infrastructure.  While they can play a part in security, they are not specifically for security.   

So, why not a security language?  Let’s take a look at what this language could be. 

Introducing SeCON?   

For lack of a better name, we can call this proposed language SeCON (security configuration object notation.)  At least until somebody comes up with a better name. 

So what would this “SeCON” language do? 

• Define a Dictionary of Security Controls:  SeCON would establish a standard set of security controls that any organization can use, such as endpoint security, firewalls, SIEMs, vulnerability scanners, and so forth. 
• Configuration: It would have a common way to define how a security control is setup and configured.  Things like IP address, DNS names, authentication methods, and certificates. 
• Policies:  It would have a common language to define policies for security controls.  For example, it could have a native set of firewall, routing, and scanning type policies.  Since this may not be sufficient for the universe of security tools, it could also offer a way to embed native configuration language. This would allow the language to accommodate the unique policy or configuration aspects of each tool.    
• Documentation:  SeCON would also provide a method to document the control’s configuration.  In the same structure where configuration and policies are defined, there would be text structures to attach how the control is configured and why. 
• Testing: Lastly, there would be a way to read a configuration file and then test a specific instance of a control to see if it meets the configuration parameters.  This provides a “closed loop” system where the same language that configures a tool, also has the power to validate that configuration at a later date.   

More Barriers

Obviously, this standardized security language would have some significant hurdles to overcome.  Here are a few to consider.   

• Adoption:  Vendors would need to adopt their products to accommodate this language.  However, if a vendor publishes an API, then it would be relatively simple to map the language to specific API commands. 
• Platform: SeCON would need some platform that can execute all these rules and commands.  Ideally, cloud vendors, like AWS could adopt this language into their existing scripting languages like CloudFormation.  However, I am sure there are some technical details I am not considering that may make this difficult.
• Resources:  Standards such as this require a lot of work to define, build, and promote.  To make this a reality would take money and backing.  Support from cloud service providers or standards bodies like NIST would be critical to success.
• Complexity:  This is stating the obvious, but security is complex.  Its not as simple as provisioning a virtual machine or a container.  It is this complexity that makes a language like this necessary. 

The Promise of SeCON

I admit, this language is merely an idea…and possibly an outlandish one.  However, I remain a firm believer that the root cause of all security problems is configuration.  Ransomware attacks are successful not because their malware is particularly innovative.  Rather, organizations continue to rest the security of their company on the inconsistencies and inadequacies of people.  If we can close that gap, it will become more difficult to exploit vulnerabilities because there will be fewer of them in the first place. 

The promise of a standardized language for security would also mean decoupling security configurations from the idiosyncrasies of each platform.  It would not matter whether you had a Fortinet or a Palo Alto, McAfee or Crowdstrike.  If they all worked with the same language, you could standardize across them all.  This would give you, as a user of those technologies, greater freedom to change to a different technology without the arduous cut over from the old tech to the new one.  This is no different than how technologies use Bluetooth, TLS, or NTFS.  It does not matter what brand of tech you have.  They all conform to the same standards. 

The real benefit is the standardization itself.  Once security is standardized, it can be applied universally, consistently, and deviations detected quickly.  Using a single tool, you could theoretically deploy, configure, monitor, manage, and document your security infrastructure.  As your enterprise expands, you can use the same standardized language to modify your security infrastructure. 

A standard security language could deliver massive scale while improving the consistency of security controls. 

Conclusion

If security is ever going to get ahead of the threats, we must stop twiddling knobs and relying on humans to configure everything properly.  A standard security language could revolutionize how security is applied and managed.  It could finally make sense of the messy vendor space. 

What do you think?  What am I missing?  Share your feedback here, or you can always email me at andrew.plato@zenaciti.com.  

The post Standardizing Security appeared first on Zenaciti.