On civil discourse

In penance for the somewhat unpleasant tone of my last post, I offer this for your consideration.

A few months ago I was at an event where I exchanged pleasantries and made small talk with someone who is, shall we say, "not well respected" is some circles.  I was later asked why I didn't just ignore the person.  At the time I just shrugged it off, but here are a few reasons why I try to engage people, even when it takes some effort.

First, there's the decency/civility issue.  The fact that someone else is a raging [insert preferred expletive/epithet here] does not give me permission to act like a [said expletive/epithet].  I realize that both "common courtesy" and "common decency" are almost as rare as common sense, but that does not excuse me from exercising them.

Second, just because someone is a [one of those] doesn't mean they aren't capable of intelligent conversation or providing a unique perspective on an issue.  While it is generally more pleasant to learn from friends, it is often more insightful to view issues from a different perspective.

Third, the world is full of [them], learning to deal with [them] rationally is a necessity.

There certainly are some people who have crossed some line, ones who have established a pattern of behavior, or otherwise proven themselves beyond the range of civil discourse.  At this point, avoiding them is usually better than arguing with them- you will either end up giving them exposure, making yourself look like a [you know], or both, if you mess with them.

Finally, there are some people who deserve to be called out.  Just make sure you have examined the skeletons in your closet carefully and thoroughly before taking this step.

Now, if only I could follow my own advice better...

 

Jack

 

P.S. Don't believe any of this? OK, then try acting civil and consider it a social engineering exercise.  The older I get, the less I care about motivation and the more I care about results.

Making sausage, one hearing at a time

John Godfrey Saxe once said "Laws, like sausages, cease to inspire respect in proportion as we know how they are made."  [No, it was not Otto von Bismark; and yes, that is the quote]  I can't say much for "inspiring respect", but watching the creation of Massachusetts' 201 CMR 17.00 has been more like being a vegan and having to watch the manufacture of blood pudding.

Warning: harsh and unpleasant opinions and observations ahead.

On Tuesday I attended the latest public hearing on the data protection regulations, and it was not pretty.  First up, the hearing was moved at the last minute- to a larger room, but still nowhere near large enough.  It was pretty pathetic given the interest in 201CMR17.00 and previous hearings' overflow attendance, I had hoped they would be prepared.  Instead, dozens were left standing and the room quickly became uncomfortably hot and stuffy.  To me, this showed a lack of respect for the attendees and citizens of the Commonwealth.  Maybe it was part of OCABR's plan to keep the proceedings short, if so, it didn't work.  Sure, a handful of people decided not to speak at the end, but a lot of us did testify.  That's where it got ugly, and it got ugly fast.

First up was Scott Schafer, Chief of the Consumer Protection Division of the Mass. Attorney General's Public Protection & Advocacy Bureau.  That title should give you a heads-up for what's coming.  Mr. Shafer read a prepared statement that could only have come from an unholy alliance of Commonwealth PR flaks and attorneys.  He spoke for quite a while without saying much- but it appears the AG's office likes the latest version of the regs, undoubtedly because they are vague enough to prevent the AG's office from ever having to prosecute except in the most egregious cases.  I was particularly impressed with his lack of awareness of the data loss landscape, highlighted by his reference to the TJX breach putting thousands of consumers' records at risk.  First, 96 million is a lot of thousands.  Second, fraudulent charges were made on compromised accounts- but he's just an attorney and so can't be expected to respect the significance of linguistic subtleties.  Not that the difference between "at risk" and "exploited" is subtle.  [Note that once again I am forced to give someone the benefit of the doubt by assuming them ignorant, because to assume otherwise would mean the statements were intentionally misleading].

Speaking of uninformed, many speakers who followed Mr. Shafer raised their objections to the exclusion of many Commonwealth agencies and offices from 201 CMR 17.00.  Much weeping about it, actually.  Too bad the whiners were so oblivious to the regulatory landscape that they were unaware of Executive Order 504, mandating security and confidentiality of personal information for the Executive agencies of the Commonwealth.  It is my understanding that EO 504 has not been repeatedly weakened or delayed, state agencies are dealing with it now.

There were actually several speakers with very specific concerns over definitions, requesting clarifications and tuning of individual sections of the regulations.  Those in this group have my respect, even when I disagree with them.

Of course we had a few of the "I'm here to be heard but have nothing to say, look at me, look at me" minority you get at any gathering of people.  At least none of these bloviators said "where are the TV cameras?"  Well, not aloud.  [There weren't any].

Another set of speakers fell into the category of "we need an exemption for our industry".  There were a handful of these, I had no sympathy for any- except the public service orgs, and I doubt they will get any relief.

I did testify, if you read my last post on the topic you will have a good idea what I said.  I highlighted a few of the key weakenings of the regs that concerned me, such as

• Removal of the requirement to monitor the CISP
• Removal of the requirement to minimize the amount of PII retained
• Removal of the requirement to identify and classify PII
• Removal of the requirement to have a written PII access policy
• Evisceration of the encryption requirements
• And misleading information regarding encryption in the FAQ issued by OCABR

Then I reminded everyone that 201CMR17.00 was mandated by 93H, which was stuck in legislative stupor until the TJX incident- and I asked if full compliance with 201CMR17.00 would have prevented that breach.  My answer was no, the initial compromise vector was WEP, and with the weakened encryption requirements WEP could be argued to be adequate.  I then opined that 201 would not have prevented the Heartland or Hannaford breaches, and pointed out the lack of web application security guidelines to protect PII.  I reminded the panel of the credit and debit cards re-issued in recent months, all due to breaches.  I raised the 263,471,744 lost records (as of that morning) on the Privacy Rights loss list- not counting the "unknown number of records" incidents on that list.  I suggested that the lack of strong guidelines, the lack of established penalties, and the repeated changes and delays made for a lack of real risk for non-compliance with their risk-based scheme.

In closing, I may have indulged in a bit of hype and hyperbole by saying that the regulations provide enough leeway and plausible deniability that they would simply be a regulatory and policy-writing burden on those who do business in the Commonwealth, without significantly improving security- and if that was the case, the Commonwealth was wasting time and money by imposing a needless and pointless burden on business.  I ended by observing that security is hard, and negligence is easy- until you suffer a failure.

One later speaker remarked that he disagreed with me and said that he was confident that any business making a good faith effort at compliance with 201 CMR 17.00 would be more secure.  I really wished I had a unicorn to give him.  While what he said was technically true- we are where we are because organizations have repeatedly failed to make "good faith" efforts at security.  "Good faith" without a big stick backing it up is nothing but unicorn droppings.

 

Jack

An insightful pair of reports

Where do you get information on products for your environment?  There are a lot of options- in fact there is no shortage of people with opinions who will happily share.  Now, the hard bit- Where do you get information you can rely on for products for your environment?  There are a lot of analyst firms, labs, websites, magazines, etc. that generate product comparisons, product evaluations, market analysis, and even the ubiquitous "shootouts" (which generally make we want to shoot something- or someone).  Sadly, most of it is crap for a variety of reasons: tainted (or at least made suspect) by vendor sponsorships, failure to define parameters and procedures, misconfiguration of tested systems, a fundamental misunderstanding of the products/market segment, and so on.  Some reports crank out a lot of data, but return very little information, and nothing which you can act on.  Sometimes you can parse the raw data yourself and come up with better conclusions, or at least more relevant to your needs.

There are very good resources available, but you need to do a lot of filtering to find reliable sources of useful information.  That is why personal recommendations are so valuable, and part of the appeal of real-world gatherings such as user groups, and virtual water coolers such as the Security Blogger's Network and the Security Twits- because real people are behind the answers.

These thoughts were triggered when I was fortunate enough to get previews of two reports released this week by NSS Labs. I hate to sound like a fanboy, but they have really put some thought into their analyses on endpoint security for web threats.  Actually, the full title is "Endpoint Security, Socially Engineered Malware Protection, Comparative Test Results.  That's a mouthful.  There are two similar reports, one for consumer products, and one for corporate products.  These are not "Anti-virus shootouts" or anything vague.  The reports define a specific problem (web-based malware downloads) and define their testing methodology, including steps to insure consistent testing.  The testing cycles were repeated, and they used live systems for testing, not canned data sets.  When the tests were complete and validated, the data showed some interesting things.  Both general and specific conclusions come from the tests.  Global observations include the increasing importance of reputation-based services in the cloud, and that no matter what anyone says, anti-malware packages are not "commodities", there are significant differences in performance between the tested systems.  That leads to the specific, the products which performed best dramatically outperformed the worst for the specific threats tested.  The consumer products report is available free (registration required), the corporate products report is not free- but depending on your environment, the $1800 price tag could be trivial compared to the cost of making a mistake in purchasing endpoint protection products.  You can extrapolate some things from the consumer report, but the corporate version includes some additional observations on the ease of management, and there are real differences in performance between corporate and consumer products.

When you need information, be skeptical, but keep looking- there is good information out there.

 

Jack

DojoCon

A promising new security conference is coming up in early November, DojoCon.  It will be held on November 6 and 7, at Capitol College in Laurel, Maryland (just north of Washington, DC).

There is a great lineup of speakers, the registration is affordable, and on top of that- proceeds will benefit Hackers for Charity.  DojoCon is an extension of DojoSec, the great monthly security gathering established by Marcus Carey.

Unfortunately, I have a prior commitment and will not be able to make it, but I'll send the Sock Puppets down to deliver a donation in my absence.

 

Jack

Security and Fluffy Bathrobes

Toilets, auto emissions, Hunter S Thompson, all that 201 CMR 17.00 stuff, and now bathrobes- I know, but hear (read?) me out on this one.

I tend to be cheap about travel, all I usually want in a hotel room is a halfway decent bed, a functional shower, and relative cleanliness.  Occasionally, however, I stay someplace without a complimentary "Hookers and Truckers" floor show in the parking lot.  Sometimes, I end up staying in nicer places, and on rare occasions I stay in very nice places (this generally involves someone else's money, or a complimentary upgrade due to a colossal screw up by the hotel).  How do you know when you are in a "luxury" hotel (or at least a luxury suite)?  It isn't just the big things (big rooms, big TVs, big bathtubs, etc.) but the smaller things like mints on the pillow and the sure sign- the fluffy bathrobes.

So what's the point?  You (or someone) has shelled out a lot of money, and the hotel wants you to feel like you are really getting your money's worth- because they know if you don't, you will not do it again.  It is only fitting, if you spend a lot of money, you should know where it went and feel good about it.

Thankfully, the people who control security budgets don't expect to see where all that money has gone, nor do they expect to feel good about it... oh, wait.  But we already do a great job at keeping people informed and... um, strike two. 

It's different you say, they *have* to spend money on security.  No, they do not.  There may be a wide variety of factors which compel them to spend the money, but especially in this economic climate (hey, there's an area where some Global Warming is needed), financial pressures force some hard decisions.  No matter what the regulations say, if the choice is between making payroll (and thus existing into next week) and anything else, "anything else" better be pretty darn compelling.  Assuming your situation is not that dire, you should still think about the visibility of your security efforts, and whether the organization gets a good feeling from it.  I am not advocating that your IT and security team(s) start offering a bed-time turn-down service to the boss (actually, I strongly advise against that) but think about what visible benefits your organization gets from their IT and security budget.  If the answer is "not much", start thinking about how to change that.  Don't bore people with too much detail or too frequent updates, but find a way to make your work visible (in a good way, not just as the jerks who always say no).

 

Jack

Security Twits Road Trip III, the SecTorBus

We're doing it again, this time to the awesome Sector Security Education Conference in lovely Toronto, Ontario.  Last year the inaugural trip rolled from Boston to Dayton, via the DC area.  Then we did the (in)famous ShmooBus trip to Shmoocon earlier this year.

Tentative plans call for a departure from the Northern Virginia area, gathering Security Twits and others on the way to Boston, then heading into the Great White North.  [I REALLY hope it is not so white in early October].

We have learned a few things from the previous adventures, and thus we hope to make new and exciting mistakes this time.  I nothing else comes up, a border crossing should provide plenty of opportunity for entertainment.

Once again a big thank you goes to my employer, Astaro, for sponsoring the trip.

 

Jack

PCI, Compliance, and Security

[I am occasionally contributing to the Corporate Overlords' blog, including a version of the post below.  I am posting a version here, too, because the snark level on the official version was a bit low for my tastes].

Some people seem to be confused about compliance- some hate it, a few like it (I worry about these), and some really like to argue about it, especially when it comes to PCI-DSS.  PCI-DSS is the much-maligned Payment Card Industry Data Security Standard, a set of requirements for companies which process credit card data.  Full documentation is available from the PCI website.  The standard is currently 72 pages, not a quick read- and that may be part of the problem; an amazing number of people like to argue about it without ever actually reading the beast.  But then again, facts only serve to screw up a perfectly good uninformed rant.

I believe the root problem is that many people confuse being compliant with being secure.  While they may be complimentary goals, compliance and security are very different.  Being compliant with a "security" standard or regulation does not make you secure, and it's approaching the problem from the wrong direction- focusing your efforts on being secure, then aligning with your compliance requirements will result in a more secure, sustainable, and affordable environment.

Even people who should know better have been confused by this (or lied and claimed to be confused); recently Heartland CEO Robert Carr said in an interview with CSO Online that he believed PCI compliance meant that Heartland was "secure".  We all learned that Heartland wasn't secure when they suffered the "Largest Data Breach Ever".  The reactions to Mr. Carr's comments were strong and swift, Rich Mogull and Mike Rothman were among the many people who took exception to Mr. Carr's statements about compliance and security- and eloquent though their responses were, the controversy Mr. Carr's comments sparked only serves to highlight the problem.

Part of the confusion comes from the different security postures of organizations before they begin their compliance programs.  For a company with poor security and a lack of organizational awareness of security standards, becoming PCI- (or whatever)- compliant can introduce many positive changes and dramatically improve the overall security of the organization.  On the other hand, if an organization already has a well established and effective security posture, becoming compliant should be fairly easy, BUT, it could result in losing focus on security as attention shifts to compliance.  Worse still, if an organization has done a thorough risk assessment and focused their efforts accordingly, some regulations may require them to divert resources to addressing requirements which are not aligned with actual risk to the organization, effectively reducing their security.

Another problem with compliance is that while most security professionals understand that regulations define the minimum security standard, many outside of the field believe that compliance is all that you need to do to be secure- thus confusing a security baseline with a finish line.  Or, maybe they don't confuse them, but a scrap of paper gives them cover to say they have done "enough".

In the absence of standards and regulations it is often easier to grasp that security is a process, not something you "are" or "aren't", and should be tailored to fit the situation.  Unfortunately, it is also common for organizations to neglect security unless they are required to comply with some regulations or laws.

Finally, complaining about PCI, HIPAA, or any other regulation doesn't change the fact that we need to comply.  Go ahead and work to change the laws or regulations you find onerous- but complaining is no substitute for an ongoing assessment of your environment, securing it as appropriate, and mapping your security posture to meet compliance requirements.

 

Jack