Category: fail

Theme breakage, help?

The blog header image is repeating because of something in the stylesheets. I can’t see where the bug is. If someone can help out, I’d be much obliged.

Expanded to add: It appears that there’s a computed “repeat” on the bg img which is the header, but why that repeat is being computed is unclear to me, and attempts to insert explicit no-repeats in various ways have not over-ridden the behavior.

The Plural of Anecdote is Anecdotes

Over at, there’s a story which starts:

Medical-data blackmail is becoming more common as more health care providers adopt electronic health records systems and store patient data digitally. (“Hackers demand ransom to keep medical records private“)

The trouble with this opening sentence is that it has nothing to do with the story. It’s a throw-away assertion. There’s no evidence offered up. There are lots of alternate hypotheses, such as more health care providers are talking to their attorneys about blackmail. Maybe it’s true, but the article totally fails to make a case.

A flame about flame

CNET ran a truly ridiculous article last week titled
“Flame can sabotage computers by deleting files, says Symantec”. And if that’s not goofy enough, the post opens with

The virus can not only steal data but disrupt computers by removing critical files, says a Symantec researcher.

ZOMG! A virus that deletes files! Now that is cutting edge technology! It’s shit articles like this that reifies the belief that the security industry in general and the AV industry in specific is filled with people who are completely out of touch with the rest of the world.

“These guys have the capability to delete everything on the computer,” Thakur said, according to Reuters. “This is not something that is theoretical. It is absolutely there.”

ProTip to Symantec and Reuters, viruses have been doing this since at least the 80s. Are you really that desperate for yet another story that this is the level that this is the sort of thing you feel is worthy of a press release and news article. How about you save that time and effort and instead focus on making a product that works better.

A Letter from Sid CRISC – ious

In the comments to “Why I Don’t Like CRISC” where I challenge ISACA to show us in valid scale and in publicly available models, the risk reduction of COBIT adoption, reader Sid starts to get it, but then kinda devolves into a defense of COBIT or something.  But it’s a great comment, and I wanted to address his comments and clarify my position a bit.  Sid writes:


Just imagine (or try at your own risk) this –

Step 1. Carry out risk assessment
Step 2. In your organisation, boycott all COBiT recommendations / requirements for 3-6 months
Step 3. Carry out risk assessment again

Do you see increase in risk? If Yes, then you will agree that adoption of Cobit has reduced the risk for you so far.

You might argue that its ‘a Control’ that ultimately reduces risk & not Cobit.. however I sincerely feel that ‘effectiveness’ of the control can be greatly improved by adopting cobit governance framework & Improvement of controls can be translated into reduced risk.

I can go on writting about how cobit also governs your risk universe, but I am sure you are experienced enough to understand these overlapping concepts without getting much confused.

Nice try, Sid!  However, remember my beef is that Information Risk Management isn’t mature enough.  Thus I’ve asked for “valid scales” (i.e. not multiplication or division using ordinal values) and publicly available models (because the state of our public models best mirrors the maturity of the overall population of risk analysts).

And that’s my point, even if I *give* you the fact that we can make proper point predictions for a complex adaptive system (which I would argue we can’t, thus nullifying every IT risk approach I’ve ever seen), there isn’t a publicly available model that can do Steps One and Three in a defensible manner.  Yet ISACA seems hell-bent on pushing forth some sort of certification (money talks?).  This despite the inability of our industry to even use the correct numerical scales in risk assessment, more or less actually performing risk assessment in a means that can be even used to govern on a strategic level, or even showing an ability to identify key determinants in a population.

Seriously, if you can’t put two analysts with the same information in two separate rooms and have them arrive at the same conclusions given the same data – how can you possibly “certify” anything other than “this person is smart enough to know there isn’t an answer”?


I want to make one thing clear.  My beef isn’t with ISACA, it’s not with COBIT, it’s not with audit.  I think all three of these things are awesome to some degree for some reasons.  And especially, Sid, my beef isn’t COBIT – I’m a big process weenie these days because the data we do have (See Visible Ops for Security) suggests that maturity is  a risk reducing determinant.  However, this is like a doctor telling a fat person that they should exercise based on vague association with a published study of some bias.  How much, what kind, and absolute effectiveness compared to existing lifestyle is (and esp. how to change lifestyle if that is a cause) is still very much a guess.  It’s an expert (if I can call myself an expert) opinion, not a scientific fact.

In the same way your assertion about COBIT fails reasoned scrutiny.  First, there is the element of “luck”.  In what data we do have, we know that while there is a pretty even spread in frequency of representation in data breaches between determined and random attackers.  That latter aspect means that it’s entirely likely that we could dump COBIT and NOT see an increase in outcomes (whether this is an increase in risk is another philosophical argument for another day).

Second, maybe it’s my “lack of experience” but I will admit that I am very confused these days as to a proper definition of IT Security Governance.  Here’s why; there are many definitions (formal, informal) I’ve read about what ITSec G is.  If you argue that it is simply the assignment of responsibility, that’s fine.  If you want to call it a means to mature an organization to reduce risk (as you do above), then we have to apply proper scrutiny towards maturity models, and how the outcomes of those models influence risk assessment outcomes (the wonderful part of your comment there is the absolute recognition of this).  If you want to call it a means to maturity or if ITSec G is an enumeration of the actual processes that “must” be done, then we get to ask “why”.  And once that happens, well, I’m from Missouri – you have to show me.  And then we’re back into risk modeling, which, of course, we’re simply very immature at.

Any way I look at it, Sid, I can’t see how we’re ready for a certification around Information Risk Management.

Side Note: My problem with IT Security Governance is this: If at any point there needs to be some measuring and modeling done to create justification of codified IT Security Governance, then the Governance documentation is really just a model that says “here’s how the world should work” and as a model requires measuring, falsification, and comparative analytics. In other words, it’s just management.  In this case, the management of IT risk, which sounds like a nice way of saying “risk management”.

Smoke, Fire and SSL

Where there’s smoke, there’s fire, goes the adage.

And in the case of an allegedly-theoretical exploit outlined in a new paper by Chris Soghoian and Sid Stamm (the compelled certificate creation attack), the presence of a product whose only use it to exploit it probably indicates that there’s more going on than one would like there, too.  As Wired’s Threat Level notes:

Normally when a user visits a secure website, such as Bank of America, Gmail, PayPal or eBay, the browser examines the website’s certificate to verify its authenticity.

At a recent wiretapping convention, however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications — without breaking the encryption — by using forged security certificates, instead of the real ones that websites use to verify secure connections. To use the appliance, the government would need to acquire a forged certificate from any one of more than 100 trusted Certificate Authorities.

The attack is a classic man-in-the-middle attack, where Alice thinks she is talking directly to Bob, but instead Mallory found a way to get in the middle and pass the messages back and forth without Alice or Bob knowing she was there.

The existence of a marketed product indicates the vulnerability is likely being exploited by more than just information-hungry governments, according to leading encryption expert Matt Blaze, a computer science professor at University of Pennsylvania.

As the paper explains,
While not known to most users, the CAs are one of the weakest links in the SSL public key infrastructure, a problem amplified by the fact that the major web browsers trust hundreds of different firms to issue certificates. Each of these firms can be compelled by their national government to issue a certificate for any particular website that all web browsers will trust without warning. Thus, users around the world are put in a position where their browser entrusts their private data, indirectly, to a large number of governments (both foreign and domestic) whom these individuals would never ordinarily trust.
The assumption that people are taught with SSL is that if the certificate is valid (meaning it is not expired and matches the hostname of the site they’re visiting) and trusted (meaning either they or a Certificate Authority vouch for its authenticity) then the connection is secure from eavesdropping.
The problem is that the decision of whom to trust is being made by people who may or may not share the same security interests as the browser user.  For example, if the United States’ own National Security Agency (NSA) were to compel a CA such as GoDaddy or Verisign or any of 264 CA’s to issue such a certificate within the guise of a National Security Letter, the CA would not only be compelled to comply, but would also be enjoined from ever talking about or acknowledging that they had been required to do so.
The NSA would insist (and might even believe) that they were doing it in the name of “keeping us safe,” but the people they’re targeting would probably feel differently.  Cybercriminals would likewise argue that they’re keeping their income streams safe.  Either way, outsourcing trust has come back to hurt the user.
Thus, the current system of Trustworthy Certificate Authorities has now scaled to the point of failure.  The entities whom we’ve engaged to determine who is or isn’t trustworthy have increasingly shown to have limited ability to deliver in that role.  The only way to be sure that a connection is trustworthy is to keep the trust relationship aligned with the people you actually know and do trust–i.e. run your own private CA and manage your own certificates.  That’s obviously beyond the capabilities of all but a very tiny fraction of the SSL-using world and of limited usefulness other than ensuring relatively secure transport between a closed set of sources.
In the long run, something else is needed.  I don’t know what, but hopefully Soghoian and Stamm’s paper will continue to help drive the discussion.
(Updated to clarify original links)

Well that didn't take long…

The Guardian has reported the first official incident of misuse of full-body scanner information

The police have issued a warning for harassment against an airport worker after he allegedly took a photo of a female colleague as she went through a full-body scanner at Heathrow airport.

The incident, which occurred at terminal 5 on 10 March, is believed to be the first time an airport worker has been formally disciplined for misusing the scanners.

Here was the chance to set the standard for abuse and all he got was a warning.  Adjust privacy expectations accordingly.  And it doesn’t sound like the co-worker is taking it as well as Shah Rukh did.