Arguing FOR Security Through Obscurity

We should all be questioning the received wisdom and best practices of security. Why? Because aggregate spending on security expertise and products is now massive, but the bad guys are still getting away with it most of the time.

"Uphill battle" is not an apt way of putting it. You know, you can usually see the top of a hill.

Maybe we're fighting the wrong battles altogether.

Consider the great pejorative of infosec, "security through obscurity."

Everyone knows that security through obscurity is not just bad, but downright irresponsible. The canonical illustration of this comes from cryptanalysis: rolling your own crypto scheme is almost always a bad idea, with a result that is considerably weaker than what you get with a publicly known, well-understood encryption scheme. Kerckhoffs's principle, a rule of thumb for cryptosystems saying that your system should be secure even if everything but the key is public knowledge, first appeared in print way back in 1883.



But lately, when designing security for really hard-to-secure things -- like everyday things used by millions of regular people -- I've found myself saying about our defensive measures, "Let's not talk about this." What on Earth am I doing?

Economic warfare is what I'm doing. But not in the way you're thinking. There's an old principle in security that I'm sure you know: if you make a system more expensive (in time or resources) to break into than the reward gained from doing so, you've built a damn fine defensive barrier. And it's obvious that secrets take effort to unearth, through reverse engineering or intelligence gathering, for instance.

The reason this doesn't usually apply to crypto is that cryptanalysis is historically a game played by nation states, where the reward gained from undermining a system is so great that it justifies an extraordinarily expensive intelligence effort. 

But some of the R&D projects at Critical Assets Labs have been going even farther into the territory of economic warfare, in the service of practical security for everyday things. In today's world, riddled with security problems, we are continually applying the security principles of warfare and statecraft, like Kerckhoffs's, where they don't apply. At this place in history, we are really good at securing very special things, based on a security model perfected with the castle keep: we put the really big prizes behind the most layers of security. At the center of those rings of security, only specially authorized people, with special training, have access, and if they see a stranger, it's okay to stab him.


The problem today is that practically everyone has special access to something -- bank accounts, email accounts, corporate assets -- and we need to secure those things, but they're not really crown jewels. And we can't treat everyone like castle guards. If a castle guard doesn't follow the right security procedure, you throw him in the dungeon to teach him a lesson. Those rules don't apply to everyday security. Put in the jargon of the net: consumer security education doesn't scale.

Ultimately, consumer security solutions that require training are not solutions. They're actually security problems. (Does anyone really think that we can train a majority of people to look for the "green bar" on ssl sites? or that anyone on Earth is going to notice when their online banking login skips that step where they're supposed to look for their special photo? Seriously?)

Solving those training problems takes the defenders' money and time, so from an economic warfare standpoint, when you go down that road, the advantage actually shifts, by default...

 to the attacker!

As we make our research findings known, through this blog, papers, and conferences, and as our R&D comes to market (through product roll-outs and licensing to partners), we will be demonstrating how one of the ways in which we are raising the defensive bar is through uncertainty, the helpmeet of obscurity.

Today's most well-deployed defensive tools - antivirus, anti-malware, DLP, and application aware firewalls, present no uncertainty to attackers. It's easy to test your malware against every antivirus package before you release. It's easy to tell when you've penetrated a firewall.

We think that the next generation of defensive security will work by breaking the attack development cycle, and breaking the connections between exploit and payment.

Reflecting on ICS/SCADA Software and Hardware Security Vulnerabilities

On a fairly regular basis someone will send me a link about a newly disclosed vulnerability in ICS/SCADA control system software or hardware and ask me what I think about it.  Recent examples include backdoor remote access embedded into hardware with trivial authentication and weak cryptography, systems that are left unpatched due to lack of vendor support, control system software and hardware with a myriad of security holes and vulnerabilities, etc.  The list is long, and seems to be increasing at an alarming rate.  My guess is because there are an increasing number of security researchers who are actively trying to get the message out about the insecurity of these systems.  Many of these, like trivial authentication and lack of patch management, are dirty little secrets that are not surprising to those that work in the industry.  What is different is the press and attention they are receiving of late.

I won't comment on the motives of these researchers, but some of them definitely have a vested interest in the attention it draws to the security problems in ICS/SCADA, in the hopes that it will generate buzz and attention to their company and to the security problems in general with the ICS/SCADA equipment.  Nevertheless, these vulnerabilities and problems do exist, are pervasive, and neither the industry nor the vendors seem to be acting very quickly to correct the situation.  Trying to correct these security issues after the fact just doesn't work very well.  As security professionals, we understand that security must be integrated into the entire development life-cycle of hardware and software.  

So who is responsible for the security of these systems and what can we do?  ICS/SCADA manufacturers and integrators need to step up their game and create solutions that meet security best practice standards, at the very least. If they want to continue providing products and services in the Electrical Energy Sector (or many other SCADA environments), they also need to be able to demonstrate that their products are not only secure but are compliant with, and facilitate compliance with, NERC CIP and other regulatory standards.

End user entities of ICS/SCADA hardware and software need to "Trust, but verify", to coin a phrase.  These entities should be asking questions.  Lots of questions.  Create and ask for validation and verification testing that the equipment, designs, and other solutions are going to meet your operational, security, and compliance requirements.  Do this early in the process of selection and procurement.  Engage with your vendors and let them know your concerns and find out what their path forward is for creating and supporting security throughout the life-cycle of their products.

If you aren't comfortable with putting your vendors to task, enlist the services of a company like Critical Assets.  We can help you develop design selection and testing criteria that meets your specific needs as well as facilitate testing in your facility or ours.  Ensuring that your ICS/SCADA hardware and software is secure, compliant, and operational can be a difficult task, but it can be done and there is help available.