Standardizing Security

When you look back over the history of technology (including cybersecurity), there is a relentless march toward standardization.  Technologies start specialized, with high barriers to entry.  Over time the technology standardizes and commoditizes.  Standardization lowers costs and promotes scale, which ultimately fuels innovation and widespread adoption. 

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 [email protected].