Just as you would expect, this is essentially the Rosetta Stone of PCI. All the confusion, all the gray areas that weren’t clear, all the ambiguous references to technology and technical specifications – cleared up with one section that the Council did not want you to ever see. So, without fail, I give you – Requirement 13.

Requirement 13: It’s somebody else’s problem.

13.1 PCI Merchants and Service Providers, under no circumstances, should take responsibility for sound information security practices and satisfactory compliance status.

13.1.1 PCI Compliance is the QSA’s problem. Never admit that you’re doing anything wrong, or that your practices are not sound.

13.1.2 If a passing ROC cannot be obtained from your QSA, attempt to discredit him/her and their organization.

13.1.3 If a passing ROC is obtained, but is completely bogus (see section 13.2.2, “Rubber Stamping”), and an incident/compromise occurs, attempt to discredit him/her and their organization.

13.2 Qualified Security Assessors will claim to be objective, but in actuality will be subjective based on prior knowledge, perception of customer, and QSA consulting firm contracts and business needs.

13.2.1 PCI Compliance is the customer’s problem. Never imply that anyone but the customer is directly and wholly responsible for all facets of PCI compliance, regardless of whether the QSA has a clue about the technology, business processes, or CHD flow.

13.2.2 As long as sufficient “evidence” of controls can be provided, keeping the customer happy and paying the bills should be the QSA’s primary concern. This is often referred to as “rubber stamping,” and is often encountered when merchants and service providers prioritize compliance over actual security measures that meet best practices.

13.2.3 Neither the PCI Council nor the payment card brands will offer the slightest assistance throughout the course of the PCI assessment. Verbal “blame shifting” is acceptable when clients demand specific answers.

13.2.4 In the case that a client is compromised, or experiences a breach of CHD, a QSA must never admit fault. Disavow all knowledge of the technical or procedural shortcomings that may have led to the breach, and strongly insinuate that the client may have been “hiding” things during the assessment.

Well. Hope this clears things up.

Rick asked me to help get the word out on this charity event – essentially a fund-raising effort to help Matthew’s family, which is being hosted in association with the DC404 September meeting. I will be out of town, but anyone who can contribute or attend is encouraged to. I checked out the lineup, it looks excellent – so attend if you can!

Site is here: http://www.shoecon.org/

1. Why are users still clicking on random attachments? Especially if the email is from someone they do not know, have never heard of, or purports to be one of their long-lost friends on Facebook?! This is undoubtedly one of the world’s greatest mysteries – how do we cure stupid? Many cars of convicted drunk drivers are equipped with alcohol sensors that detect blood alcohol level before they will properly start. Can we implement something similar for chronic offenders that hack, slash, and click their way to digital Armageddon? Is there a class of people out there that just cannot be trusted to use computers responsibly? This is similar to smoking in public for me – your exhaled smoke can have a negative effect on my health. Well, when these kinds of folks’ systems join the ranks of a bot army, it affects us, as well.

2. For all the intrusion detection systems I encounter in organizations, I estimate that 65% are used very little, even going so far as to call them “shelfware”. In addition, most staff using IDS today, that I encounter, are not properly customizing rule sets or even venturing to create their own rules, trusting the default rule sets and updates later provided by the vendor. So here’s the mystery – why the $%&! would you spend 5-6 figures (or more) on equipment that can act as cornerstones of your network monitoring capabilities and a) not get trained properly on how to use the stuff to its potential, and b) just ignore it after a period of time? I’ve seen this same phenomenon occur with other gear, but never so often as IDS.

3. So you’ve made an “investment” in antivirus. Who gives a shit? The stuff is CRAP, and it is BROKEN. The mystery – why are you not clamoring for, nay, DEMANDING, a whitelist solution? NOW!!?? With the proliferation of malware today, you are dealing with a new variant added to a “blacklist” every few seconds. Sounds really sustainable. Yep.

4. Here’s another doozie – the gradual desensitization of the public. In fact, this could be the greatest mystery on this list – how can TJ Maxx lose millions of credit card numbers, go through a scandalous public debacle, and actually see its share price go UP? The media has helped desensitize the public, unfortunately – “ho hum, another big data breach”. And we as security professionals have now come to realize that outrage is ephemeral. Ouch.

• First, let me say that the course was atrocious. Horrible. Here’s why: the instructor. Not the material, per se (although there is a lot of room for improvement), but the instructor and his teaching style. He had no style. He was dry, he was stumped on questions at least 10 times per day, and he offered no real-world examples or concrete guidance that attendees could truly benefit from.
• The guidance overall was very literal in some areas, but usually vague. So assessors leaving this class are not getting a lot of “lessons learned” or “here is the best way to do this or look at this” kind of advice.
• The range of backgrounds and skill sets in the class were as varied as I’ve ever seen. This could be viewed as a positive OR a negative, depending on your perspective, but the frightening thing was the very obvious lack of knowledge some folks had, and some of the questions asked were flat out stupid. Yes, I said it, and I mean to be a bit derogatory. If you are asking some of the questions I heard in this class, you need to be studying up for Security+ at best.
• The test was easy. Really easy.

What’s the take away? Well, I have some thoughts, maybe a little advice. Here goes.

First, we really need to start interviewing payment card assessors.

Ask for resumes. Do an actual interview. Ask about real experience with the same technologies in use within the organization. If you don’t like someone, or don’t feel they are a good fit, ASK FOR SOMEONE ELSE or TALK TO A DIFFERENT CONSULTING FIRM! Why is this hard?!

Second, do not let a non-technical manager do the interview or make the call alone. In fact, as some of you know, I am not a fan of “GRC fanboys” running security teams in general, as they tend to be full of shit. “governance blah blah blah” and “controls blah blah blah” do not a true security architecture make. I have about had it with folks who hide behind “frameworks” and paperwork. If the audit team or compliance team makes the decision (and they tend to be a little less technical overall), ensure technical folks are involved to help call BS on would-be assessors who roll buzzword-style.

Third, ask for samples.

Although no one is going to share a formal compliance report with you, some examples of audit reports and writing should be available for assessors and consulting firms. IF they won’t provide this, just move on. Don’t waste your time.

The term “enemy” is probably a little strong. However, there is really almost no standardization here. You’re on your own to validate someone’s credentials, and it is obvious to me that consulting firms are hiring some very “green” or less experienced people to do this work. Don’t fall victim to these people, as they can have a huge impact on your business and compliance programs.

A final note: One class attendee, who can only be described as a douchebag, actually described himself as a “Master Security Architect”. If you have any desire to get respect from your peers, or maintain the semblance of a social life, do not ever refer to yourself as a “Master Security Architect”. Gawd.

• Data breach lessons learned: We need more “from the trenches” stories and data, and I personally will be looking for more of these.
• Shifts in security technology: In particular, advances in DLP and movement toward application whitelisting and away from traditional “blacklist” AV.
• Advances in virtualization and cloud: I would like to see some good, definitive solutions and thoughts here this year instead of mostly hype. I think I will, since I know things are progressing in the industry.
• New directions in compliance and privacy/breach notification: Just to keep up, more than anything.

I’ll also be scouring the vendor area for good info, too – last year was wretched. Just nothing new or interesting that grabbed my attention, not to mention the lack of people at the conference in general.

See you there!

1. Politics: If the security organization is impotent due to political issues, and has no a) budget, b) support from executives and business unit management, and c) plan, it is very likely doomed to failure.
2. Lack of monitoring capabilities: We need more eyes and ears. From NIDS to HIDS to File Integrity Monitoring to Network Flow Analysis to Log Management, we need a better approach to what is happening in the environment. Not only that, but too many organizations buy stuff and forget about it – if you don’t have daily SOPs around your monitoring tools and capabilities, you will end up with shelfware, and that just sucks.
3. Lack of technical skills: Way too many infosec folks are happy to slap that “CISSP” on their business cards or email signatures. Great. Can you actually DO anything though? I truly feel that a base skillset for anyone in infosec operations has to include some scripting, firewall and router ACL creation and management, a grasp on scanning and vulnerability management, patching and configuration management skills, reading and understanding packets, and responding to incidents. Sure, there are specialties. But who gives a $*@ about your cutting edge Appsec skills when no one on the team can even lock down a box appropriately? C’mon. And you managers who hide behind “policy” and “governance” and go to 10 meetings a day to keep looking busy? Heh – chances are you suck. The day is coming when you will, and should be, obsolete. Yeah, we’re all trying to be better “business people”, but you still need to have a technical skill set to even PRETEND to keep up with this game.
4. Focus on the “cutting edge”: Got Web app firewalls? DLP? Awesome! But if you have no system hardening program, or lack a robust patch management process, you are really missing the boat. It’s been consistently proven that the basics like patching and config management, when implemented and maintained rigorously, could have stopped a vast percentage of data breaches. One exception – the time for whitelisting has come. Death to blacklist AV!
5. Managing to compliance: Sad to say, but I have seen this really emerge in the last 3-4 years. Organizations are stopping at the check box. And that’s a tragedy, since we all know that compliance != security. I say that with a hint of sarcasm, since it’s pretty damn obvious that we all DON’T know this, or people wouldn’t be doing things this way.

Not a complete list, at all. Just the major things I see consistently across organizations in pretty much every vertical.

Information Security should not report to IT.

Before the ever-cynical infosec crowd stops reading and throws this out the window, let me explain why I feel this way. Information security really has several key functions to perform – security operations (in whatever capacity that may take), security audit and analysis (could be related to compliance, but also ensuring policy is set and followed), and security-related governance, ie working with the entire organization to ensure information is protected with input from all business units and departments. Did you catch that last part? It’s important.

When infosec reports to IT, it is in essence, aligned with IT. It is tied to IT budgets, politics, reporting constraints, other priorities, etc. This is exactly wrong. With organizations’ data rapidly becoming the most important asset (behind their people, of course), the need to impartially manage the security and risk mitigation of that data should not be tied to IT…nor ANY ONE GROUP. What this means, in the most simple fashion, is that it is time for information security, with or without an official CISO or CSO, to report directly to the CEO and/or the board (preferably the latter). Here are a few common places I see infosec reporting into, and the most obvious pitfalls that relate to this governance/org structure:

• CFO/Finance: This is not too common, but I’ve encountered it a few times. The benefit is that you don’t report to IT, so the organization likely recognizes the potential conflict and/or need to separate information security from the larger quagmire that is Information Technology in general. However, CFOs have their own agendas, and although they may align with the organization as a whole in most cases, not always. Sometimes, CFOs can’t see the forest for the trees, and become blindly focused on saving money at all costs. This doesn’t jive with the world of information security, where you may well need budget unexpectedly due to changing threat landscapes.
• IT VP/Director/Manager: The most common case. I’ve already explained why this should change, but another point to consider is the mysteriously self-serving nature of IT organizations. Although they talk the talk about “supporting the business”, many IT professionals could honestly care less about business issues, and just want to play with the new toys. Bad, bad, bad for security in so many ways.
• Internal Audit (VP/Director): This actually tends to be the most closely aligned with the CEO/BoD in quite a few cases, as the internal audit department usually has some degree of impartiality. However, there’s a big caveat. Many audit departments have compliance at the top of their list, and compliance != security, as we all know. The biggest pitfall here is shortchanging security initiatives when they’re halfway completed since the checkbox is already checked on the auditor’s list.

I’m not much of one for absolutes, in just about anything really, but I am 100% behind this one. We need to see this trend happen – CISOs and CSOs need complete severance from ANY one group in the organization, as they have to work with them all. Closely aligned with much of IT, yes. Under its thumb? Not just no, but hell no.

PS – For the most hilarious security org chart EVAH check this out: http://www.themetalith.com/images/hsorgchartoriginal.gif

I took a look at the SC Magazine 2010 Data Breach survey found here. I’ll comment on a few points in this survey, as I am generally getting more and more skeptical of the validity of responses to these surveys, or generally questioning some of their usefulness. All images are taken directly from the survey page.

No shocker here. Compliance is the big driver. And it looks like “negative brand impact” is another one. However, this brings up a point, in my mind at least – why aren’t organizations doing this to “enhance security” or “adhere to security best practices”? Are all organizations like spoiled children who continually ask “Awww, do I HAVE to?” I understand money is involved, but it boggles my mind that companies do not understand the intrinsic need to not shit all over employees, customers, and partners by losing something entrusted to them.

Here’s another one that begs a question – how could even 7% of respondents NOT KNOW the answer to this? And “Yes, but not enough” seems like a cop-out answer that is “safe”. Either you have a cohesive plan, or you do not. Or you live under a rock and answer “Don’t Know”. Apparently, SC Magazine can reach you under said rock. Bravo.

Some additional nuggets of awesomeness (these graphs I only found in the magazine article):

• The company is preventing the data from being stolen, exposed, or lost. The responses? 91.2% agree, 4% disagree, and 4.5% neither agree or disagree. Two things – those numbers add up to 99.7% (where’s the other .3%?) and what kind of dumbass doesn’t have an opinion on the matter? To Mr. I don’t Know What the Hell is Going On…this Bud’s For You.
• Most and Least Helpful in detailing safeguards to protect customer data stored electronically. Holy nonsensical results, Batman – check this out!
  SOX was the most helpful to 28.1% in 2009. WHAT!!!! HOW? There IS no detail.
  GLBA was the most helpful to 16.3% in 2009. See comment above.
  HIPAA was the most helpful to 30.3% in 2009. Maybe you have no CLUE as a healthcare CISO, and you did a knee-jerk response on “your” compliance thingie. But really?
• Departments involved with this plan [breach response] to ensure that it is carried out properly. And HR is not even on the list. Internal folks don’t steal data?

So to bring this full circle with the opening paragraph and title of the post – did SC Magazine publish this useless bit of drivel to get some attention; in other words, use a “buzzword”? I say yes. For less “fluffy” infosec publishing, check out Bill Brenner and crew at CSO or Marcia Savage and the folks at Information Security. And yes, I know what they say about opinions.

]]> http://daveshackleford.com/?feed=rss2&p=301 0 http://daveshackleford.com/?p=293 http://daveshackleford.com/?p=293#comments Fri, 22 Jan 2010 23:25:50 +0000 admin http://daveshackleford.com/?p=293 All IT professionals, regardless of specialty, face a number of challenges. Some, if not all, of these will affect most IT professionals in some way or another throughout their career:

• Lack of budget, IT is considered “overhead”
• Lack of respect from other business units, we’re only one step removed from R2-D2
• Lack of social skills, you spilled Mountain Dew on your too-short pants at the meeting
• Politics, the smiley well-dressed guy that wears too much cologne with the football analogies is better-liked than you

There’s also a bevy of more specific technical challenges that could plague IT folks (this list is almost infinite):

• You are trying to integrate new platforms into the environment
• You are trying to keep legacy systems afloat
• You are trying to communicate with the mainframe people, who DO in fact resemble R2-D2
• Upgrading/replacing systems
• Upgrading/replacing applications
• Managing users, scripts, logs, storage, networks, devices, etc etc etc.

Security people have a challenge that is 100% unique to their discipline: we have adversaries.

Now I know some of you in areas other than security will argue that you have adversaries, too. If security is even a tiny part of your job description, then you may be right. But the burden of fending off adversaries, both internal and external, falls squarely on the shoulders of information security teams. This lends an entirely new dimension to the concerns that plague everyone else:

• We cannot prioritize new functionality over security and stability. Ever. Lest adversaries take advantage of this and exploit vulnerabilities.
• Things like coding languages employed, platforms chosen, and applications deployed really need consideration not from what they offer us, but for how breakable they are.
• The concept of time is more relevant to us than anyone – our priorities can, and should, change as the threat landscape does. We have opponents, some coordinated and others standalone, actively trying to come up with new ways to cause us harm. This means we need to ensure these new methods they’re employing will be as ineffectual as possible, all the time.

This is an over-simplification at best. However, it’s an oft-overlooked factor that tends to be forgotten in the day-to-day dynamics of our interactions.

OK, OK, that was pessimistic sounding. I do have some thoughts in general on this year in security. Here we go:

• Compliance will be a hot topic again this year. PCI is growing (MasterCard Level 2 peeps, talking to YOU). HIPAA is being changed, legislators are looking at breach disclosure and other topics, etc.
• DLP – love it or hate it – will get more mature and could become even more relevant with tie-ins to e-Discovery and compliance mandates. Trust me, I hate buzzwords more than most, but I think the notion of keyword searches and data fingerprinting have merit. Just early in the evolution.
• Howard Schmidt will do almost nothing. Oh sure, he may *talk* and stuff…but I don’t see anything changing this year. The government is just way too bureaucratic and bloated to change quickly. Not his fault, but I don’t think he’ll be the infosec savior by any means.
• Cloud computing will start to become more tangible, and we WILL have to secure that beeyotch.
• On a related (sort of) note, virtualization security will leave the “Chicken Little” phase and assume a normal place as YAICTS (Yet Another Infrastructure Component To Secure).
• We will have to really address some of the major “gray area issues” in security. For example, the whole PI license for computer forensics issue…WTF?
• Please please please please PLEASE – can we stop being such geeks and embrace risk management as the cornerstone of information security? I’m all for packets, hacking tools, and the like, too…but businesspeople still look at security folks often times like the 17 year-old that still plays with Legos. We talk all this bullshit about wanting to be more accepted with business folks, but many of us don’t really walk the walk. And no, I do NOT think metrics are the answer. <shudder>.

Some other general thoughts (not security):

• It is officially time to stop clipping your phone to your belt. You are not Batman. In fact, not even Robin.
• All movie critics suck. Why do we listen to them at all? I, for one, do not need my movies to be deep and meaningful all the time.

And off we go.