Wednesday, January 09, 2013

Cybersec-cliché: process

Among other things, Bruce Schneier is famous for saying that "security is a process". His point wasn't about process so much as products. Customers buy security products (like anti-virus, firewalls, and IPS) thinking they are a magic pill that will stop hackers. They aren't a magic pill, of course, their efficacy depends a lot on how these products are used, the "process".

But, "process" isn't a magic pill, either. Process cannot make up for product deficiencies Process cannot make up for the lack of skills and education in IT organizations. Indeed, the under-skilled use process to mask their own inadequacies. Process often becomes it's own worst enemy, sucking up resources to feed itself rather than making forward progress toward a goal.

Process has become a cliché: what value the idea once had has been destroyed by its overuse.

I mention this because recently I've seen a bunch of articles/posts attacking "process" and I wanted to jump on the bandwagon. The new phrase is now "security is not a process". Though of course, once we finally convince people the value of this idea, it, too, will have become a useless cliché.

Update: Note the excellent comment below from @JPGoldberg on why he uses this cliché. I think the point is that even though something has become a cliché doesn't mean it's lost all value when used correctly.

3 comments:

I continue to use Schneier's cliché at multiple opportunities. Here's why.

I work for a company that makes a password manager. This product is designed to change people's daily behavior. It's not a product to install and forget; it is a product to install and use. And so emphasizing these change in behavior remains a good thing IMO.

As with any product, it is not absolutely 100% perfect out of the gate. We issue improvements and fixes, including security updates. Because this is a mass market product, our customers are not security professionals. Security updates scare some of them. And so trotting out "security is a process" is helpful in getting people to understand that it is a good thing that we release security updates.

So sure, I agree that products matter. But even with the best of products people need to keep their products up to date. That is a process.

Security is still a process for me. We are an IT Service company and sell certain security services built into our general offerings. The customers expect more than just a product behind the service offering. When I look then inside, the product itself is worthless without the right embedding into the different processes. Finally you will not improve over time, if you think that just upgrading a product gives you enough security.

The process that people believe in is Certification and Accreditation, or as I call it, Certification Engineering. In essence we have productized the process around a mediocre baseline standard rather than practice any real security engineering. We have an army of people trained to recognize whether a setting is set according to the baseline and they can format a report correctly, but they have no idea what the context or impact of those settings really are. Rather than truly assess risk, every network must have the same settings and same products installed, no matter what it is connected to. Vogons following orders signed in triplicate to be sure. The standards are not kept up to date, and they don't cover every setting, so networks are getting easier to get into, not harder. The process should be different with each network or system, based on what it does and resources it needs. Security and Network Engineering need to constantly change, but process is keeping held to mid 1990's architecture in too many cases. It would be nice to make an adversary have to work around something other than the latest AV/IDS signature or some OS memory architecture. A process should include ways to use products and engineering to make a system functional and adversary actions easily identifiable...even if all you had was a firewall.