Branden Williams' Security Convergence Blog

VeriSign has a new webcast! On a day where I was not feeling totally top notch, Melissa & I recorded this for your consumption. Here's a synopsis of the webcast.

Security in retail is hard. Retailers have never heavily invested in information security, and with threats increasing and the available investment money dwindling, many retailers are going to be in for an interesting ride. The consulting group at VeriSign realizes that security is not a one-size-fits-all problem. Each company requires a custom solution to maximize their results. This presentation outlines two distinct approaches, one from security and one from compliance, and gives some helpful tips to start your own process to bolster your security.

If you are interested, simply send an email to retailsecurityinfo@verisign.com and ask for the free link to the Retail Security Followup Webinar!

Posted by Branden Williams at 6:04 AM | Permalink | Comments (0)

But we already knew that. I mean, with shows like the Big Bang Theory and Two & A Half Men, who can deny his genius?

Anyway...

For those of you that own televisions and have already realized his genius, you probably know that at the end of his shows there is a 2-4 second blip where he displays his vanity card. Every episode has a unique one, and as most things, the first ones were pretty tame, and they get more and more out there with each passing week (see this blog and Herding Cats in the ISSA Journal for additional examples).

Vanity card #221 struck me as something we see in the compliance and security industries. The first part, anyway, it goes off on a tangent that is unrelated.

We have once again arrived at a moment in history where the truth can be defined as "that which you can make other people believe." The methodology for creating that belief is repetition. Say something enough times and it becomes, for millions of people, the truth.

Think about your last compliance or security assessment. Two plus two equals three. Did you expect to find everything totally peachy, but in reality found some nasty holes that nobody really knew about? Two plus two equals three. Did Joe the firewall engineer go on vacation and while he was out, an auditor happened by to review some active firewall configurations? Two plus two equals three. No problem, right? Two plus two equals three. We've passed these types of reviews before without an issue. Two plus two equals three. But after further review, you find several suspicious firewall rules that open up certain ports for certain individuals in certain sensitive areas.

Or how about this? Two plus two equals three. You walk into an assessment meeting with an assumption about a process because you have been told by multiple people that X process works Y way. Two plus two equals three. But then a savvy assessor (or maybe just a bored one) starts asking questions in a certain way that ends up revealing a major gap that went undetected for months, or years. Two plus two equals three. How did this happen? Two plus two equals three. Exactly like Chuck Lorre said it would. Two plus two equals three. Truth became what one person could get another to believe. Two plus two equals three. Why? Two plus two equals three. Maybe it's apathy? Two plus two equals three. Maybe it's a lack of understanding? Two plus two equals three. Every situation is different.

While Chuck refers to things that are not related to information security, the basic principle of his post rings true. Trust, but verify. The phrase, "But, I didn't know!" only goes so far, and won't help you after a breach.

By the way, how much is two plus two?

Posted by Branden Williams at 6:06 AM | Permalink | Comments (0)

CIO Australia recently posted an article suggesting that data breach notification laws drive compliance. Bob Russo is quoted quite a bit in the article, but there is a part that is missing. It's not Bob's fault, he is speaking from the Council's perspective. He hit the bullseye.

But what Bob does not say is what is really driving compliance.

I've been doing PCI/CISP compliance work since 2004, not quite two years AFTER the September 26, 2002 filing of California's SB 1386--the first State Data Breach Law. Unfortunately, many companies did not pay too much attention to it until several years later when other states started passing similar laws, especially when Minnesota passed the Plastic Card Security Act in 2007. Being in the trenches dealing with companies, I can definitely say that before 2007, the feeling in the PCI world was "We'll get to it... if we ever do." By 2007, I had a list of clients that had failed their annual assessment three or more years in a row, with little to no improvement year over year¹.

During 2007, however, we saw a dramatic uptick in the reported compliance rates of Merchants² of all levels. Let's think back to 2007. Is it data breach laws that caused this uptick? It could have, but that's a significant 4 year delay (allowing for some variance).

What else happened in 2007?

Visa announced their Compliance Acceleration Program! Remember that? The original plan was that fines would start if compliance was not reported by September 30, 2007. Visa later offered a three month rebate if compliance was met by December 31, 2007. Not to mention, if you were subject to Tiered Interchange, you did not qualify for the best available tier!

Holy crap, talk about lighting a fire!

One of our customers figured out that their cost of non-compliance was $40 million in lost rebates! WOW! That's a motivator if I've ever heard of one--especially if your compliance costs are under $80 million over 2 years! Presumably, your maintenance costs should be SIGNIFICANTLY lower (especially if you purchased VeriSign's PCI Program Management offering!). Shameful plug?

If anything has pushed compliance, fines (or a real threat of) seem to be the main motivating factor, not laws.

Now, one difference between the US and the rest of the world that could make a difference is that here in the US we are inundated by breach notices. For credit card breaches, the damage is pretty minimal (more than credit card such as SSN is definitely a MUCH bigger problem), and I think most of us ignore it and continue shopping. After spending a few days in the UK, there are some groups that believe required notification upon a breach will be a massive motivator, until THEIR citizens are inundated and then don't care anymore.

The moral of this post? My experience tells me that fines are a much bigger motivator to pushing compliance to a particular standard versus data breach laws. If you want to get companies to comply, affect their business. After all, security and compliance is a BUSINESS issue. Properly motivated, it will be addressed.

________________________________________
¹ Albeit, in the Merchant's defense, CISP had changed several times since 2001, and the original PCI Standard was released and amended by 2007 such that we were then working under version 1.1.
² Reported compliance is different from actual compliance.... remember that.

Posted by Branden Williams at 6:30 AM | Permalink | Comments (4)

Here's one of those areas where security and compliance stare at each other angrily across the table instead of skipping down the trail together singing, "Tra-la-la." I was speaking to a friend of mine at a birthday party about this because guys don't stay inside for the Hannah Montana makeover, we go outside and talk about beer, sports, and information security.

OK, SOME of us do that. So what if I like my toes painted?

Anyway, he was telling me that his company was taking the stance that private label cards, or those cards that have the company name on them instead of a Visa, MasterCard, American Express, Discover, or JCB logo on them, should be included in their PCI efforts. At first I misheard him and thought he said that his assessor was requiring those cards to be included. If that is the case, the assessor needs to go back to training. The only cards that are in scope for PCI are the ones that have one of the five founding members' logos on them (EDIT: Or ones that conform to valid PANs from those card brands that may still not have the logo on the front. Thanks to Todd A for pointing that out!).

This is part of that security versus compliance argument. When I learned that his company was requiring them to be included into their PCI efforts, I applauded them. Here's an example of a company that realizes that the only way to ensure their investment into the private label payment system will not be overcome by losses due to a breach is to include them in a PCI Assessment. Not only does that say something about the confidence in the assessment process, but it also says something about how much faith management has in the information security program.

There are, of course, many reasons why this may have happened. It could be as simple as management's realization that the security program is short on people and resources. Therefore, they have decided to offload some of the tasks to an assessor performing some required compliance assessments. There are darker reasons why this may happen, but those will be left to your imagination.

For the record, non -member branded payment cards are considered out of scope for PCI. But beware, If you are managing your own private label card system, you should treat it with the same level of security (if not more) than you do your member branded cards.

Posted by Branden Williams at 5:45 AM | Permalink | Comments (0)

On a recommendation from a friend, I picked up Tribes by Seth Godin. I've read many of Seth's great books, the most popular probably being The Purple Cow, and each time I marvel at human nature's rationalization that complex equals better. Complexity sometimes equals better, but don't you think it's funny how sometimes the simplest ideas are the ones that far exceed the complex ones? These are the ones that end up leaving a red mark on your forehead from your hand after you smack yourself and say "Dammit, why didn't I think of that?!?"

Man crush aside¹, security professionals need to read his books. If there is anything negative to say about us security folks, it's that we don't have the marketing skills to help others see how our ideas can make the future better for everyone.

Now, on to one of the sections from Tribes. Seth talks about risk and the probability of risk. He says something in here that should ring true to most readers, and that is that many people are so afraid of risk that they can barely even use the word². He then goes on to define risk as the probability of failure, thus when saying something like the probability of risk, we are talking about the probability of probability.

Circular AND fun.

He postulates that the safer you play your cards, the riskier your position is because the world is constantly changing.

We've all sat in meetings where the elephant in the room was the new direction the company needed to go, but no one was willing to stick their neck out there to own the change. I've been in customer meetings like this.

It's depressing.

All of the innovative energy that made the company great is chased away by risk managers and corporate ladder climbers such that we all sit in a state of decision paralysis. Seth's point to the three paragraph section I am referring to is that we should take risk to enable change. Change for the better will keep us relevant. Keeping those same legacy systems and process in place just because we don't want to challenge the status quo is riskier than raising your hand and asking a hard question or two!

"Why do you do X? Why do you do it in Y way? What business constraints do we have that preventing us from doing it like Z, especially if we could save $2 million in the first year?"

Now it's time to do a little self reflection. What risks have you put off taking when thinking of the status quo? Should you take a risk by putting a complete business case around some new hardware and services that you know your company needs and presenting it as high up as you can get? How about expanding your personal network to include others at the company outside of your group³?

Make the next six weeks a time where you take a risk or two. If you think it through carefully⁴, the rewards could be huge!

________________________________________
¹ Yeah, I have a small man crush on Seth Godin.
² This and remaining ideas are all from Seth Godin's book entitled Tribes, pages 110 and 111.
³ It's amazing what you can find out when you buy a round. How do you think sales reps know so much about the inner workings of companies they are not employed at?
⁴ And don't be a jackass... seriously. Remember other people have feelings unlike us security-bots.

Posted by Branden Williams at 6:24 AM | Permalink | Comments (1)

Do you remember debate or speech class? I remember having a professor assign me the counterpoint position on an issue in which I didn't agree. I always thought that the other guy had it easy if our beliefs were the same because he already believed what he was saying.

I recently read an article by Ariel Silverstone in CSO Magazine entitled "Where PCI DSS Still Falls Short (and How to Make it Better)" in which Ariel seems to have been put in a similar situation. Either she was asked to publish something (anything), or asked to specifically publish something on PCI; regardless, she should have spent a little bit more time on research than she did. After reading her positions, I'm pretty sure she didn't ask any QSAs (or anyone that have been in the industry for more than a few weeks) for assistance during her research phase.

After reading the article, I felt cheated. I picked up the text thinking that I would find some insightful points by a former consultant and current professional affected by PCI. Instead, I was subjected to an article that set up the shot but didn't follow through.

Her first points are definitely on-point, if not historical in nature. The first thing I have to take issue with is her comment on scoping and comparing PCI DSS to the SAS 70 Type II (note: not type I). While you can carve out specific scope for PCI and validate it like you would a SAS 70, that's not necessarily a bad thing. Sometimes that is required for a business to do depending on how they are set up. It's up to the enforcement entity that accepts the Report on Compliance (i.e., a card brand or bank) to decide if it meets their requirements. Companies that do IT hosting and management require this kind of flexibility, otherwise they would be forced to apply PCI to all of their customers.

Ariel suggests splitting up the requirements, but it is clear to me that she didn't read past Page 3 of the PCI DSS. While in some cases you could extract the top level requirements (particularly the short ones), it is unrealistic to simply group top level requirements together. For example, some elements of Requirement 11 can overlap with Requirement 6, and others should potentially be found elsewhere in the standard. Making blanket statements about the top level requirements is a dangerous game to play.

Next she talks about the concept of segmentation. PCI DSS does not require segmentation, but if you have a diverse network, it is highly recommended to reduce scope. She takes the concept of segmentation and applies it to requirement 6.1 (ok, I guess she did make it past page 3, I stand corrected), further questioning the rationale of thirty days vs any other number of days.

Part of making a standard is that you have to draw a line in the sand SOMEWHERE. Otherwise you will have people asking those kinds of questions versus actually progressing toward a goal. The point is to patch systems quickly, or to at least mitigate the risk such that the vulnerability could not be exploited (say by removing a .DLL file. Thank YOU .art vulnerability!).

The next one is a common mistake made by many professionals--including QSAs. The old One Function Per Server requirement (2.2.1). Proper virtualization can be used (including with mainframes) to allow multiple functions in the same piece of hardware while meeting the intent of the requirement. She says she was not aware of any research that proved this requirement reduced the risk associated with breaches. I've not looked for it, so I'll assume it doesn't exist. Regardless, any certified security professional will understand the concept of an enclave, and knows that proper access controls must be put in place to prevent a vulnerability in a DNS server leading to a dump of customer data. I've been calling that an "intrusion path" for years. It's the concept of many successful complex attacks. I compromise X on one server, which leads me to access Y on the same server, which then leads me to Z on another server, and so on.

It's just plain riskier.

The next suggestion (4 if you are keeping score), along with content in Suggestion 7, illustrates Ariel's lack of experience in the PCI world. Suggestion 4 discusses requirement 3.1 and the somewhat contradicting concept of keeping the storage of cardholder data to a minimum while using business, legal, and/or regulatory purposes to define what is stored and for how long.

One thing I've learned about people is that they are much less likely to stick with an off position if they are forced to write it down--especially in public companies where documentation like that could become part of legal discovery. Instead, we have conversations over the phone or in crowded coffee shops, confident that never writing it down will allow us to slip by undetected if something bad happens. I personally believe the intent of this requirement is to force businesses to write down their retention plans, see what they look like on paper, and adjust if necessary. I can't tell you how many times I've been told that data must be retained for ten years, only to have the same person come back to me in a week to deliver a scaled back version of the stance on paper.

Suggestion 7 screams "outsider with a lack of experience." I remember sitting in difficult meetings in 2004 getting yelled at by all kinds of executives because I was telling them how to run their business. You can't go from zero to eleven in a matter of minutes (unless you are Spinal Tap of course); you have to ease your way there. If the PCI Council saw fit to require internal encryption in the next version of the standard, I firmly believe there will be a revolt.

If you are not encrypting at least some internal communication of data you deem sensitive, you have a lot more faith in the security of your satellite offices than you probably should. Ever walked into a retail store only to see the system room door wide open? Do you think the corporate data center door is also wide open (hint: it's not, and usually surrounded by lots of security)? I'm not saying that we should encrypt everything, but that is one we should leave to the merchant or service provider to decide.

Oh, and I'm pretty sure that FTP or "automated tools" are not the same as "end-user messaging technologies." And no, it is not OK to send unencrypted data over the internet with FTP.

Skipping back a bit, Suggestions 5 and 6 are a little odd to me. Flexibility will allow for companies to deploy something that is best suited for their environment. The standard used to suggest TripleDES and AES as two encryption algorithms to be used, but there are plenty of other algorithms that are considered strong (if not stronger) that are acceptable. For example, Two-Fish is a fantastic algorithm (implemented correctly of course), and should be allowed on PCI related systems.

Final thought on that suggestion, the PCI Council should NOT be accepting legal risk for mandating particular encryption algorithms or key strengths. She points out why with the Zimmerman reference. Every company should do their own legal analysis to determine the best course of action for them.

I think you should read her article and form your own opinion, but I view it as a slightly embarrassing show peppered with valid points here and there. A prime example of why you should fully research a hot topic like PCI before publishing a "thought leadership" piece.

Posted by Branden Williams at 6:17 AM | Permalink | Comments (1)

RSA 2009 has been in the can for over a week now, and I've had some time to reflect on the state of security since the economy broke it's nose on the market floor. Gartner released reports saying that security spending was not cut as hard (if at all) when compared to other areas inside companies. People on the expo floor had mixed experiences as well. The four common themes I discovered were:

1. Non-essential security spending was cut (but things you have to do like SOX and PCI are fine)
2. Headcount was cut
3. No change
4. My hair is on fire

Regardless of the theme, more security professionals are warming up to the idea of Managed Security Services. While most of us want to command a SOC that is significant in both size and value to our company, our companies' executives look at the expenditure required to build said SOC and have to decide if they are in the security business or not.

Most are not.

So in order to meet the mounting threats that our overworked teams deal with every day, we need to figure out what elements of our program are best outsourced to people in the business of security, and which ones are not. Many companies start immediately looking at things like IDS management/monitoring, firewall management/monitoring, and log management. Those are excellent choices for sizable environments supported by a small team. Not only does it allow you to delegate these tasks to outside experts that do hundreds, if not thousands daily, it also allows you to re-deploy YOUR experts to focus on strategy and building value for your company.

Sounds great, doesn't it?

With the right company, it sure is great! Don't stop reading here--I'm not going to suck you into a drawn out pitch for VeriSign's MSSP services (but feel free to inquire about them!). But I want to caution any purchaser of managed security services... you are not buying a light switch!

I've recently figured out that most companies that purchase managed security services think they should work like a light switch. They just flip it on, and magically things start working.

The reality is that managed services require tuning and up-front investment to make them work well. This means that your first year costs will be dramatically higher than future years for the same scope of systems. It also means that any time you change the scope, you must account for the same type of startup costs for the new scope. Managed services can work like a light switch, provided you install that switch properly.

So remember, if you are considering outsourcing parts of your environment, you will have to invest some time and money up front to make sure you get the most value out of the service, and keep long term costs in check. Focus less on the monthly recurring cost and focus more on total cost of ownership over multiple years¹, and be sure you invest in the future!

________________________________________
¹ Kind of like buying a car, right? If you are getting a loan, focus less on the monthly payment and more on the total cost of the car. Oh, and reject the first offer.

Posted by Branden Williams at 7:31 AM | Permalink | Comments (0)

OK folks, two biggies from the April issue of the ISSA. The first is this month's issue of Herding Cats entitled, Get Compliant on the Cheap, where I review some of the fantastic commentary provided at the end of last year by JD Smith, one of our esteemed PCI Consultants.

The feature of the April journal is my article, The Art of the Compensating Control. I hope that this article helps to clear up some of the fog that clouds compensating controls.

Hope you enjoy, and Happy Monday!

Posted by Branden Williams at 7:30 AM | Permalink | Comments (0)

David Navetta published a fantastic article in this month's ISSA Journal entitled, "Who is Minding the Legal Risk around PCI" that takes a deep dive into the legal ramifications of not complying with the standard. If you do not get the journal, first off, go join the ISSA! It comes free with your membership!

In the meantime, jump over to David's blog to read the article! Towards the latter part of the article, David lays out two very real risks that I have discussed many times in this blog such as QSA shopping, rubber stamping, and scoping.

Enjoy, and have a great weekend!

Posted by Branden Williams at 10:09 AM | Permalink | Comments (0)