Mordaxus asks us to stop with the cutesy names for attacks over at Emergent Chaos today.

Using cutesy terms is jargon at its worst. It creates a group of insiders and outsiders, where there insiders can wrap their minds around the problem and the outsiders can’t. We need to have security understood by non-experts. We need less jargon, not more.

This lack of clarity hurts people. The State of California recently defeated an proposed anti-pretexting law because the MPAA argued that there were legitimate uses for it. It’s harder to defend impersonation and fraud when it is called impersonation and fraud. Cutesiness is euphemism.

Don’t be a cutesy monkey. Use precise language. Use powerful language. Don’t let the bad guys get away with defending the indefensible, as Orwell put it, with euphemism. While you’re at it, read or re-read Orwell’s essay.

Simultaneously, Dutcher Stiles over at Another Set of Teeth points out a similar variation on what really comes down to the need to feel “special” when adding an IT flavor to crime:

The real meaty threats and red flags associated with them are a bit more nuanced, and have been hashed out in the fraud investigation field for years. Computer crime is just crime. Vandals are vandals. The computer security industry seems to be genuinely befuddled when encountering a threat that doesn’t have a 8P8C modular connector jack.

I think that the same could be said of the issue of specialized security models. I’m not talking about Bell-LaPadula or Denning’s Lattice (which should be a must-understand for anyone designing “secure” processes), etc. I think our work lives would actually be a lot less interesting if we as an industry would understand and apply the math that underlies so much of what we allegedly do.

Rather, I’m talking about the Quest for the Perfect (Threat|Risk) Model. While I applaud the efforts being made in this space as an area of general interest, what I find in practice is that it doesn’t matter how good our models are because the Information Security industry as a whole has destroyed its credibility after ten years (and counting) of FUD backed by pure, hard anecdote.

Instead, I’m finding (and I work at an engineering/manufacturing company–yymv) that analysis models which are taken from (and trusted by) “The Business” can generally be mapped pretty easily to a security-specific model with accuracy that’s within the error bounds of whatever data I have anyway. Now, rather than arguing about the validity of my model, we can focus on gaining consensus on the validity of the scores, and that’s usually a minor adjustment, then get moving on the risk management plan and control framework design. Less work for me. Less arguing with the customer/target. More trust and genuine buy-in, rather than compliance or resistance.

I’ll provide two examples, both taken from the Digital Six Sigma quality framework. First, I’ve begun using Failure Mode Effect Analysis to do my Threat Modeling. Is it perfect? No. Does it capture enough of the information I need to provide a trusted explanation to an audience who don’t necessarily believe in the need for additional security controls? Much of the time. At the very least, it provides a comfortable framework so they’ll engage me rather than going into hiding.

Second (and I know this has been mentioned elsewhere in the world), instead of talking about vulnerabilities within the Software Development Lifecycle, I just talk generically about them as a post-release defect which contributes to the Cost Of Poor Quality. That’s something which is meaningful and whose costs can be inferred back onto the organization that produced them. And since Qwality is important around here, it gets traction with the developers in a way that “security matters…really” never quite did.

So when thinking about how to explain risk issues to The Business, ask yourself: Would I rather be perfect or understood?

[…] Brief discussion on being understood vs. the perfect risk analysis over on Chandler’s blog and Emergent Chaos. This mirrors a current conversation on the Securitymetrics.org mailing list (note to Chandler, don’t just tease us - write about your approaches -  it would be a much better read than Yet Another NAC Article). […]