I got an email and a voicemail today from somebody selling compliance products.

The introduction was “I got your contact information off a Security Focus email list.  Buy our products.”

Obviously, the  sales guy didn’t read my blog and what I really think about compliance.  I think there are greener pastures out there to find. =)

Voicemail, however, is a disturbing trend.  Usually we play this little game where they send me email, I flag it as spam, and it goes away.  Now they’re calling me leaving voicemail.  What next, flowers at work?

Spammers beware:  If you start buying me presents, I’m getting a restraining order.  =)

• Puzzles v/s Mysteries
• Even Better Spam
• More Vendor Craziness
• Some Thoughts on Comments to My Blog…
• Once Again, I’m not a Bank!

I don’t think we should attach the word “requirement” to any controls in a framework or catalog of controls. I wish we could use the word “needs” instead.

While it’s a subtle distinction, it implies that there needs to be some wetware involved in order to translate the catalog of controls into real requirements that an engineer (security or otherwise) can build to. Until we do that, we’re only frustrating the people who have to implement.

• Some Random Thoughts on C&A SOPs
• In Search of a Better Catalog of Controls
• An Open Letter to NIST About SP 800-30
• Always Behind
• Opportunity Costs and the 20 Critical Security Controls

I finally got an EZPass for the Dulles Tollroad.  It cut my commute down from 45 minutes to 25 minutes–it’s complete magic.

However, in amongst all the other material that comes with the transponder there is a privacy policy about disclosure of your EZPass records.  Go read it and you’ll understand when I say this:  Don’t put a bulleted list of people in your privacy policy unless you disclose PII to them because it’s too easy to misunderstand!!

I had to read the policy at least 3 times before I realized that they only release with a court order.   I guess we should just chalk it up as a lesson learned in “don’t write it this way”.

• Do You Know What FISMA Is?
• RealID V/S Court Security Improvement Act of 2007
• Remembering Accreditation
• When the News Breaks, We Fix it…
• Civilians Ask “What’s With All the Privacy Act Kerfluffle?”

I’m doing Security Awareness and Training.  This is aimed at the average user, so for me to be taking it, it’s like a Navy destroyer taking on a zodiac.

I’m not going to name the organization that this training was for, because they probably don’t want the rest of the world to know.  There’s a reason for this:  the training sucked.

It was 2 people talking behind a podium without any good presentation skills.  Even for security content which is slow sometimes, this was a new low.  The sad part is that it was some really smart people trying to teach their audience too much and in such a disorganized fashion that they ended up confusing most of them.

Mike’s version of what Security Awareness and Training should be for the average user:

• You have no privacy on our network or computers
• Doing this list of things will get you sent to a federal prison
• Doing this list of things will get you fired
• If you suspect something is strange, call the help desk
• If you have any security-specific questions, here is how you can reach me to ask
• Don’t do anything that seems stupid at the time, if you have to ask if it’s OK to do, then the answer is probably “no”.
• Have a nice day

Notice I don’t believe in trying to educate users what a firewall is, the basics of CIA, none of that.  They won’t remember it, just like I try to forget everything I know about asset depreciation and the other fine points of counting beans.

• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• White Professional Male Turned CISSP Seeks Mega-Sized Security Management Model
• What’s Missing in the way the Government does Security?
• Data Centers and Hair Driers
• Inside the Obama Administration’s Cyber Security Agenda

Compliance is a Dead-End

Compliance is aimed at one thing: limiting risks to the organization that writes or enforces the standard.  How’s that for “Bottom Line up Front” writing?

I’ve been a critic of approaching FISMA with an eye toward compliance, and I just recently started to look at PCI.  I’ve started to come around to a different way of thinking.  It all makes perfect sense for the people who write or enforce the standard–they’re cutting their losses and making the non-compliant organization take the blame.  It’s risk management done in a very effective Macchiavellian style.

For an organization looking to improve their security posture, taking a compliance-based approach will eventually implode on itself.  Why?  Because compliance is binary–you are or you’re not.  Risk management is not binary, it’s OK to say “well, we don’t meet the standard here, but we don’t really need to.”

If you base your security on compliance, you are spending too much of your time, people, and money on places where you shouldn’t be, and not enough on where you should be.  In engineering words, you have had your solution dictated to you by a compliance framework.

The endgame of all compliance is either CYA, finger-pointing, or both.  Look at how data breaches with both PCI and the government get spun in the press: “$Foo organization was not compliant with $Bar standard.”  As Adam Shostack says, “Data Breaches are Good for You”, the one caveat being “except when you are caught out of compliance and smeared by the enforcers of the compliance framework”.

I remember a post to the Policy, Standards, Regulations, and Compliance list from Mark Curphey back in the neolithic age of last year about “Do organizations care about compliance or do they care about being caught out of compliance?”  It makes more sense now that I look at it.

On the other side of the coin, what I believe in is risk management.  Risk management realizes that we cannot be compliant with any framework because frameworks are made for a “one size fits all” world.  Sometimes you have to break the rules to follow the rules, and there isn’t room for that in a compliance world.

• When Acceptable Risk is Not Acceptable
• Core Belief #2 — Risk Management Uber Alles
• My 2 Obsessions this Week
• Dictating Common Sense
• An Open Letter to NIST About SP 800-30

I’ve had 6 incidents over the past month.  Nothing earth-shattering, but it makes me wonder why so many, when I’ve been relatively quiet incident-wise for the past 6 months.

All things considered, there are 2 reasons why I’m investigating more incidents lately.

First cause is personnel turnover.  We’re a managed services provider, which means operations.  Typically, most of our slots are for entry-level server and network administrators.  We have had a high level of turnover in the past couple of months.

Second cause is me.  People now know to come to me when they suspect a security incident–my shameless internal self-promotion is working somewhat.  That means that out of the 6 incidents, there were really only 3 that were valid, the rest were just suspicious activity.

• A Visit from DCAA
• Carnegie Mellon’s Guide to MSSPs
• Turning Routers into Firewalls
• GSA Looking for a Few Good Tools
• Categories of Security Controls in Outsourcing