Branden Williams' Security Convergence Blog

Do you ever wonder how we got into this situation? Where merchants are facing tremendous fines for non-compliance, companies are being compromised by hackers here and overseas, and data security programs seem to be non-functional at best (if not non-existant)?

I'll tell you how... MBAs. Yep, those pesky folks that learn the inner workings of how to take advantage of numbers to best increase their own personal compensation?

Yes, another MBA dog-pile. And I feel qualified to pick on my MBA brethren because I are one.

All seriousness aside (did I do that right?), let's think about how payment systems started inside retailers. This is a classic example of the Build vs. Buy problem in every single MBA finance class. In the last three decades of the 20th century in the US, retailers faced more pressure to accept branded bank cards for payment--those brands being virtually the same as they are today. Before the significant advances in computing power in the 1970s and 1980s, credit cards typically were processed by hand with something affectionately referred to as a knuckle buster. The first electronic authorization systems were not even released to the market until the 1973.

So in the late 1970s and early 1980s, MBAs were presented with the following problem. Outsource processing to a third party, or build my own processing systems and pocket the difference in cash.

As we all know, most went with the latter.

The financial models typically were quite compelling and showed a relatively rapid payback of the initial investment. The problem is that early in this decade, the financial models changed. Various governments and industry institutions created regulations for protecting data--something that security professionals have argued for years. Now the maintenance costs for touching this data has dramatically increased, thus rendering the old financial data that went into the original Build vs. Buy model irrelevant.

In fact, I challenge any merchant to take a hard look at this part of their business. Why are you processing and/or storing all of this data? Shouldn't you go back to your core competencies (another fun MBA term) and focus on retailing? Why are you building a giant cost center around processing credit cards for a few cents per transaction? Isn't that the money that you should be spending toward information security (and as a secondary supported by the first point, compliance)? Knowing information about your customers is essential to doing business, but what information do you need? What can you outsource?

Information Security IS a cost of doing business, but it's impact on your bottom line can be greatly reduced by smartly outsourcing items that do not fall under your core competency.

So there you have it. Blame those savvy MBAs for making the numbers work in such a way that caused this giant mess!

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

Skimming (in the credit card world) is commonly defined as capturing magnetic stripe data during the normal payment process by swiping it through an external (or even inline) device before or after the authorization swipe. External devices are commonly found in stores where a payment instrument is presented, and someone takes the card away from view to process, like at a restaurant. Inline skimming occurs where the cardholder is present during the swiping, and usually involves tampered swipe devices.

The PCI Security Standards Council recently released an EXCELLENT guide with tips on preventing skimming, with sample forms that you can use to track your progress. Most of the skimming techniques employed can be addressed with physical inspection, something with which this guide goes into great detail. Consider doing your visual inspections during a shift change, or at least upon the opening and closing of the stores. Simple visual inspection can go a long way to preventing skimming.

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

PIN-based debit authorization rates have recently increased dramatically, some merchants complaining that their auth rates have increased up to four times their previous rate. In some armchair research, I learned that Interlink (Visa) and Pulse (Discover) have removed interchange caps on transactions. For most merchants, it is still cheaper to process a PIN-Based Debit transaction than a credit card transaction (on a per transaction basis), but for others it is about the same. Or at least the difference in cost is so minimal that their volumes don't force an advantage one way or the other.

Visa is enforcing PIN Entry Device (PED) mandates, effective on July 1, 2010, whereby all PEDs must comply with the PCI PED Standard. For retailers purchasing new equipment in the last five years, this should not be an issue. But for one industry in particular, the desire for electronic signature capture or other payment initiatives has not driven the purchase of replacement payment equipment.

Fuel!

Think about your last trip to the gas station to fill up on petrol. Did you use a credit card or a PIN-based debit card? Actually, the card you used PROBABLY can do both, so which functionality or network did you use? Did you stick with Visa? Or did you use the debit side, Interlink?

If you used the debit side, the payment processing equipment in the pump may have used extremely weak or just single DES-based encryption. This equipment simply does not (in most cases) have the ability to do Triple-DES encryption for PIN-based debit authorization. So as a fuel provider that is looking at a five to ten year payback on any equipment purchased, do you make the jump to comply with these standards now? Or do you just turn off the PIN-based debit support?

Technically, providers can still use Signature-based debit authorizations (if you went inside to pay), so they would not be saying no to debit all together. Will new methods of payment be introduced that might render an investment in equipment today useless? Possibly, but I think what is worse is that the equipment providers woefully underestimated the demand for the product, and prices are likely to increase as merchants race to deploy compliant equipment.

If you are a fuel provider, would you consider disabling PIN-based debit at the pumps? Since nearly all cards that use PIN-based debit can also be used as a straight credit card authorization, wouldn't the extra per-transaction cost be worth it when facing a multi-million dollar (or at least into the tens of thousands for smaller franchisees with just a few locations) upgrade cost? What if you could slowly upgrade over the next five to ten years, and the upgraded equipment could also allow you to buy other things like sodas, fuel additives, or other convenience items right at the pump? Would your return far exceed that if you had to do the upgrades twice?

Consumers, would you not shop at a gas station that did not offer PIN-based debit as a payment option? Since you don't sign a receipt or signature pad at the pump, punching a PIN into the device seems like a lot of work!

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

On Thursday, I threw out a blog post which I hope to be the start of a series playing on Dave Ramsey's style for financial peace, and realized I played the role of a consultant PERFECTLY (just like Marshall Eriksen might LAWYER you). SK pointed that out for me when he asks me to elaborate. In a back to school fashion, imagine this conversation as played through your teenage daughter's cell phone.

"I was all, 'Just find the data!', and he was all, 'Whatever.'"

I am so in touch with today's youth.

SK brought up a good point. Let's say you are working with an enterprise that does not have any of the following: 1) a working DLP solution, 2) a reasonable data architecture and framework defined, 3) a reasonable understanding of business process and data flows, and 4) a reasonably accurate configuration management database. Where do you start? Is data discovery even worth it?

First off, throw DLP out the window. Nearly every single DLP vendor missed the boat (or at least their sales and marketing arms have). Note to DLP vendors, it's really hard to sell the $7 million suite, but pretty easy to sell a $20K data discovery engagement (which could, of course, lead to that $7 million suite, or it could lead to a $50K/yr licensing deal for the tool). Most of my customers don't even want to hear about DLP because they don't see it as something for which they have budget.

Secondly, attack number three (TRICKY!), but use software to help validate what you learn by talking to people. Your business folks will not be 100% sure where their data is, or what data is on the systems they use. Talking to them will yield you an 80% picture (at best), so you need software to validate what they are saying. Free software like Spider from Cornell, or grep can be used to find sensitive data in your unstructured data space (like flat files). Trust your business folks, but VERIFY what they say.

While you are going through the verification process, see how your structured data is set up. This will be data that you find in databases all over your enterprise (yes, VSAM too). You will be amazed at what you can learn about your applications and your data by dumping schemas from every database WITH some sample random data out of each table. BE SURE to randomly select records from different operating times. Applications change; maybe the newest version of your application do not store social security numbers, but older versions may have. If someone did not go back and clean up the data after the upgrade, you've got a breach time-bomb on your hands.

Finally, if it applies, review your configuration management databases. Depending on your setup, this may or may not apply. If your applications rely on a configuration management database, you will absolutely need to address this.

Granted, finding out where your data lives will give you a massive amount of information. If you don't have a reasonably mature information security program in place already, you will be overwhelmed by the results of this exercise. As always, you and your organization will benefit greatly from a good security program, but if you don't have the funds for that, start by going on an electronic discovery and destruction initiative to effectively reduce the risk carried by the business.

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

I've been on a Dave Ramsey kick lately. I like his message and his concept of declaring war on debt. One of his mantras can save people TONS of cash if they would just use basic things they learned in school.

"Do the math!"

Everyone out there has a brother-in-law, church buddy, or friend of a friend who is "a finance guy." We tend to listen to people we consider experts without questioning their motives, simply because we don't believe we can comprehend the complexity of the question enough to figure the answer out ourselves.

For example, several years ago I went to a car dealership to buy my wife a new car. I had just recently graduated with my MBA, brought my Texas Instruments BAII Plus, and got ready to talk numbers ((Hey, that education should be good for SOMETHING, right?!?)). I left my wife at home and headed out with strict instructions on make, model, and of course COLOR. Negotiators at car dealerships want you to focus on the monthly payment instead of what you are paying for the vehicle (at least in my experience). When I got the first offer back, I did the math and learned while most auto loans at the time were going for 6%, this dealer wanted to put me into a 9.5% loan. I ran the numbers MANY times thinking that my MBA failed me.

It didn't.

Because I did the math, not only did I save money on the monthly, but I also cut the money I paid in interest over the life of the loan almost in half!

You know what? I dreaded doing the math, but once I did it, I found it was easy to do, and kicked myself for not doing it more often. By starting with the basic math going into a financial instrument like a car loan, I was able to make smart decisions about the purchase to save money and ensure that it did not have an adverse effect on my financial situation.

If Dave Ramsey were a security pundit, I think he would modify the phrase to say "Find the Data!" In fact, let's call that Baby Step #1. FIND THE DATA.

Information security is designed to protect information (or data). So how exactly can we protect it if we don't know where it is?

(Please pause for a moment to let the enormity of the question sink in....)

How many of you out there work for companies with extensive data maps? My guess is probably no-one does. There may be a few of you out there that do, but most companies just make assumptions about systems needing to be secure, but pay no attention to the data stored on said systems. Here's why that is important.

Groups have tried to attach a cost per record should that record be stolen and part of a data breach. The data backing up these numbers is so wildly varying that making any decisions based on the results are foolish. It is a nice benchmark that can at least legitimize the cost associated with a data breach. And, more importantly, it quickly points out that if you don't store the data, you don't need to secure the data!!

So if you really go "Find the Data," you will exit that tremend0usly difficult project with a good idea of how bad the situation is. I promise you, it is worse than you think. You will find data that will shock you into rapidly doing SOMETHING about the mess. That is a vital tipping point to the whole process. Now that you know what data you store, and where you store it, you can begin to securely destroy data you do not need, and evaluate options for the data you do.

For the data that you DO need (and really, ask the hard questions), you should fight to the death to protect it. Centralized data is easier to protect than distributed data, but there are options to protect both.

Going about finding data in your enterprise looks like a daunting, near impossible task. I would probably agree! But spending the time to REALLY find it out will pay off in spades when you let someone else get breached.

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

Bob Carr was recently quoted in a Computerworld article saying that QSAs let [Heartland] down. Of course, he is not referring to his most RECENT QSA, but I'm sure that was an editorial change to make the story more interesting.

The article is a fantastic read, but also slightly humorous in nature. I'm going to leave Heartland's situation out of this post, and look at how other companies that have dealt with breaches. If you want to see what others are saying, check Rich Mogul, Mike Rothman, and Andy Willingham.

Nearly every company I have worked with suddenly "Gets Religion" after a breach. Prior to it, security is not top of mind, therefore things like PCI become burdensome as opposed to easy.

Security always becomes much more important after you've been bitten. It's a massive pendulum that swings WAY out on the over-reacting/knee-jerk edge, where before it was way out on the other edge of complacency and letting the risk ride. By the way, the blame for this lies securely on our shoulders--security professionals. We do not do a good enough job working with the business to help them understand real risks and costs of doing business, thus preventing something like this from happening.

Don't believe me? Here are some phrases I have NEVER HEARD come from one of my customers or prospects:

• Hey Brando, this price is OK, but can you double it and really dig beyond what is required by PCI DSS?


• I know this area over here is TECHNICALLY not in scope, but can you include it anyway so we can ensure we have good security controls there too?


• I need you to do a statistically valid sample with a higher error rate so I can do more validation on our IT processes.

• You don't need to look at any of these systems, they don't store CC data (which is technically a misconception because PCI applies to areas that also transmit or process data), so don't go into that room.


• Are you sure you have to perform that test? I only want the bare minimum.


• You have to pass me! My anniversary date is in two weeks and I cannot patch this two-month old vulnerability by then!


• Come on, two passwords is practically two-factor!


• Look at the real risk here! There's only 100K cards in plain text on this machine at any given time, that's not a big deal, right?

So here's the thing. Some QSAs WILL let you down. You get what you pay for, and some QSAs may not do a good job. The Q/A process from the Council is working to address this. But you are letting yourself down if you allow something like this to happen. If you realize that the assessment is not thorough, you should either work with the QSA to fix it or terminate the contract and find one that does have your best interests in mind.

______________________________________
¹ This is an important distinction. Companies that suffered breaches in the past sometimes become complacent and forget what they learned until the next one happens.

Posted by Branden Williams at 8:07 AM | Permalink | Comments (3)

No, this is not one of those posts poo-pooing PCI because it is the popular thing to do. But after my marathon writing sessions working on the book, I started to think about all the customers that I had visited over the years, and all the problems I have seen, and how even today the problems that come up are essentially caused by common root issues.

BTW, I'm hoping you guys all LOVE the case studies. Some of you readers might even be business owners or playing a part in them! That was, by far, my favorite part of writing the book. Maybe I'll try some bad fiction writing next? (FAIL)

Anyway, one of the things that the information security rants about is how PCI should never be viewed as your total security program. PCI by itself is not good security. Many retailers, through no fault of their own, "know enough to be dangerous" with data mining and information management. They have digitized data about their customers, products, financials, marketing plans, inventory, and employees to help make them more efficient. Retailers have an amazing amount of data available right at their fingertips, and it helps them have (only) the right products in front of the right customers at the right time, increasing their ability to turn inventory.

With this much data flying around, not only do you need a way to manage it, but you need a way to secure it. Retailers traditionally ignored information security until PCI forced their hand. And I mean REALLY forced their hand. As in fines being assessed. Had Visa not fined merchants, PCI DSS compliance rates would have increased over the last two years, but not nearly as rapidly.

Why do you think that is? Is it because retailers never really viewed their data as super secret? Maybe they concentrated only on the Availability and Integrity of their data?

Regardless, now companies are having to deal with PCI, so they begrudgingly comply. Bare minimum. No additional expenses. Hire people to deal with PCI only, not really interested in security. Well, let me rephrase that. If you speak to the executives, they will tell you they are concerned about security, but their actions (and the actions of some employees) clearly state differently.

Companies that intensely focus on ANY compliance initiative are doing themselves harm in the long run. Compliance comes and goes, but you will always need to address security. In fact, you might argue that compliance initiatives like PCI or HITRUST all stem from data breaches caused by poor security. Complying with the bare minimum requirements from one initiative only leaves you vulnerable to new compliance initiatives that may cover related security issues outside the original scope.

PCI was meant to be a component of the overall security infrastructure, not THE ACTUAL security framework. In a mature security program, you would have controls defined and mapped back to compliance initiatives. This way you can save yourself a TON of time and energy by managing to your specific control set, not to each individual compliance initiative. Imagine the metrics you could pull from that!

PCI will damage your company if it becomes your security framework. Remember, it changes every two years. Theoretically, most of the changes are minor and in response to community feedback and compromise trends, but do you really want to be scraping the bottom of the barrel and doing a major overhaul every time PCI changes? Imagine spending tens (or hundreds) of thousands on a compensating control that barely passes PCI DSS, and then having to undo and redo the work the next year because of a change in PCI? It happens all the time.

How do you solve this problem? First, you have to find an executive in your company with the testicular fortitude to stand up for Information Security. Not only must this person be charismatic and full of gusto, he (or SHE of course) must understand why security is important, and be able to relate to other executives in a manner which they will understand as well. Security is a BUSINESS issue, and the business has to be on-board or you will have lost the race before the gates ever open.

Next you need to get back to basics and start with a wide-reaching enterprise security assessment. As far as frameworks go, I'm partial to ISO 27002, but choose one (or a hybrid) that makes sense for your business and environment. Figure out how you match up. Are you close? Do you just need to define lots of stuff? Or is it going to be a long, hard ride?

Finally, create your plan and work on getting there! It will require time, resources, probably some new hardware and/or software. Be sure to review industry BEST practice, and figure out how you can smartly better your posture without creating situations where users work around your new controls and you don't adversely impact the business. The business may need to change some of what it does, but you don't want to shut it down while in process. Focus on doing things RIGHT first, then look at where that puts your completion estimates. Depending on your level of maturity and size, a 2-3 year implementation plan may not be unreasonable. Going much beyond 5 years signifies some major barriers to completing the project, and a 1 year deadline either means you had most of it right, are a small and nimble company, or you grossly underestimated your timelines.

Remember folks, spend for security, not compliance. And definitely don't implement a compliance target as your main security framework. That's how PCI can ruin you.

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

OK folks, bring on the love. Ready? I'm going to stick my neck way out there.

PCI is easy.

*GASP*

OK, taking a company that ignored security (or only focused on one particular element of a good security program) to compliance is hard, painful, and will result in lots of kicking and screaming and other tantrum like actions. Why? See this post.

But take PCI DSS on the surface. It's prescriptive (potentially overly so in some cases), it is based on a good, common set of security practices that, quite frankly, you should already be doing, and its impact to your organization can be limited dramatically depending on how you approach it. If you look at the high level twelve requirements for PCI, all of them map into ISO27002 standards. Want to know what an assessor will ask you, or exactly what you have to do to comply with a particular requirement? Read the testing procedure! It's right there!

One of the issues customers and industry folks have with PCI is they will pick one particular area of PCI and latch on to it as a problem. "I can't do PCI because of X," or "Y is TOTALLY insecure.... if I do Z, I am more secure but not compliant?"

Sometimes these conversations come from people who simply do not want to go through the effort of PCI DSS and are trying to delay taking any action to resolve a gap. Maybe they think if they delay it long enough, they will be promoted out of the job, and it will be someone else's problem. I once had a (former) customer tell me he could not wait to be done with PCI so he could get back to security. What this gentleman didn't know is that PCI was the only thing delaying him being pwned because his security was so poor.

I think if the folks screaming about PCI would stop for just a second and take a look at the item for which they scream (ain't ending in no preposition here, baby! YEAH!), they would realize that (in most cases) good security practice tells them to do the same thing! If we are truly security professionals, or if we care about security at all, shouldn't we focus on improving security in our companies? The answer is Yes, and if the method by which we motivate our companies is the stick of PCI, why not use it?

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

Time for a throwback! This year, I posted my new article "The Art of the Compensating Control" over a three week period back in April. A reader recently contacted me about a claim I make in Part 4 of the posting. He says:

In your April 2009 blog The Art of the Compensating Control (Part 4) Tax day special, you stated that using the random function in COBOL to generate your key was in a sense, "a really bad idea". I have no knowledge of encryption so I don't see the fault with the process. How would this be equivalent to only 53 bits of encryption?

Excellent question! The basis of this post relies on a tool by Mandylion Labs called the Brute Force Calculator.

True 128-bit encryption means that the key is 128 "bits" of data long. A bit of data can either be a 1 or a 0. 8 bits make a byte, 1024 bytes make a kilobyte, and so on. An example 128-bit key might look like...

0010100010101011001010001010101100101000101010110010
1111101010110010100010101011001010001010101100101000
101010110010100010101011

Theoretically, this would be truly random, and you can use the entire "key space" offered by the key size and the algorithm you wish to use because you are placing a 1 or a 0 in each of the 128 bits.

Now let's look at how ASCII-based numbers (or if you like, EBCDIC) are represented in binary. Each ASCII character (or number in our case) is equivalent to 8 bits of data, or 1 byte of data (yes, technically 7 with 1 bit of parity). For example, the binary value for the ASCII character '1' is '00110001'. So now, 16 digits (128-bits / 8 bits [because each number takes 8 bits to be represented in binary] = 16 positions), or characters, would be all you can use to make up your key. If you know that your key is based on binary representation of ASCII numerical values, then you effectively know that each 8 bits of data can only be one of the following values:

• 0: 00110000


• 1: 00110001


• 2: 00110010


• 3: 00110011


• 4: 00110100


• 5: 00110101


• 6: 00110110


• 7: 00110111


• 8: 00111000


• 9: 00111001

Using the calculator referenced above, you can calculate the "effective" key strength by understanding that 16 digits gets you a total of 10 quadrillion (10 with 15 zeros behind it) possible combinations. By taking that number and performing a logarithm using a base of 2 (because remember, binary numbers can be either 0 or 1, two different values) you find that 10 quadrillion effectively equals just over 2^53, or 53-bits of effective encryption. For comparison, if you are able to use the entire 128-bit key space, the total number of possible keys would be 340,282,366,920,938,000,000,000,000,000,000,000,000. That's a pretty big number!

So using the assumptions in the calculator (which may be outdated by way of computing power, especially in light of the recent improvements in GPU processing), 1,000 machines could crack it in less than 300 hours.

Granted that these examples are painting one particular picture. Yes you could get creative and just pull the last two digits of the binary values and use MORE digits, but isn't that the point? Create a better, more random key? If you are going down that road, why not just ask your user to type randomly on a keyboard while generating your key, then measure the time between keystrokes, combine it with the random number generator on your machine, and get about the closest you will get to true randomness with 128 0 or 1 rounded values?

Give the calculator a try! There are some other great things you can do with this sheet like calculating how effective your enterprise password scheme would be against a (non-rainbow table based) brute force attack.

Posted by Branden Williams at 5:43 AM | Permalink | Comments (3)

Portions of this post originally appeared in the March 2009 Issue of the ISSA Journal.

We just got our first severe weather scare of the year in Texas. A tornado was reported less than five miles from my house by spotters on February 11th. Some of my customers have facilities in Tornado Alley and have heavily fortified their data centers to take a direct hit by a tornado. Usually, the secondary data center is also in Tornado Alley.

Why would you put two data centers in harms way? When you run the probability calculations, the likelihood of both being destroyed is about the same as an intersection in Montana having a Starbucks on every corner ((OK, I'm going out on a limb here... if I'm wrong, just disregard the analogy and pretend like this would never happen.)).

Other parts of the world have different types of concerns like earthquakes, cyclones, and monsoons. Any of these events could easily damage or wipe out a company's operations. Companies that still believe it won't happen to them will be dealt a swift lesson in humility should an event catch them unprepared (see this post for another look at the same problem.).

The events of September 11th reminded us of an aspect of BCP/DR that we often overlook. What do we do with all the items that are not destroyed in a catastrophic event? Nature does strange things. Who would have imagined that a data theft could occur from papers flying around Manhattan after the towers came down?

Here are some of the things you need to think about when working on your BCP/DR plan.

Set up your recovery site appropriately. If your business is such that you can survive well without a particular site for a few days, then a hot site setup is not required. If you do need a hot site, then you must consider the physical and electronic security implications of synchronizing data.

Secure the backup site. If you choose to use a hot site for immediate failover, you must treat the hot site the same as your primary site. You should ensure the same level of physical security exists there to prevent burglary or theft, and that you have secured the data in transit between the sites to prevent electronic theft. Hot sites without live processing present so many challenges that several of our customers prefer to load balance between sites instead of having a primary and failover.

Reduce or eliminate risk to physical assets. If your location is in a disaster zone and sustains damage, looters will not be far behind. This means that whatever walls you depended on to keep your location secure may be damaged or destroyed. If someone is wading through a parking lot and happens to notice some nice computer equipment ready for the taking, he may be motivated to take it. Depending on where it ends up, that could easily spell a breach! Any physical asset that is at your location could be stolen. Don't leave those mounds of paper records lying around for the taking.

Make sure your communications hub is on alert. HAM radio operators will tell you that when all else fails, amateur radio will get through (I am also guilty of saying this and chasing an occasional storm or two). Depending on your requirements, it might be a good idea to have a scanner tuned to local emergency response and amateur radio frequencies (including Skywarn) for a localized disaster. You may even decide to invest in GMRS equipment to keep your emergency personnel in touch in a localized area if your cell phone fails.

Have supplies! Katrina devastated New Orleans. But during the crisis, one Internet provider stayed alive, and the guy in charge blogged about it. Read about his adventure and you will get an idea about what kinds of supplies you might need.

Remember that in times of economic crisis, small incidents are magnified. Is your company well positioned to survive a disaster caused by nature? If not, now is a good time to revisit and make sure your board has all the information they need in order to make the best decision for the business.

Posted by Branden Williams at 8:46 AM | Permalink | Comments (0)

The following is a guest post by Bindu Sundaresan, a consulting manager in our Risk & Compliance consulting practice.

With the current "non-stimulating" economy, there is a lot of talk about the "stimulus" bill which is impacting all areas of the US economy. One such impact is the reason for today's blog post.

A portion of the new economic stimulus bill, called the Health Information Technology for Economic and Clinical Health Act (the "HITECH Act"), will have a significant impact on Health Insurance Portability and Accountability Act of 1996(HIPAA). This new law revives HIPAA (which has been around for over a decade), but has many a time gone unnoticed/ not strongly enforced, and no incentive to comply, amongst the other regulatory demands.

Changes to HIPAA become effective one year after the enactment of the HITECH Act—February 17, 2010—but proactive actions have to be taken by healthcare providers and their partners in order to comply with the new law.

There is the need for some reworking and rethinking by "covered entities" and "business associates"- the terms that HIPAA created for the parties dealing with health information.

"Covered entities" include physicians, hospitals, health plans and health care clearinghouses, who store, process, or transmit health information.
"Business Associates" are those who use health information to perform services on behalf of a covered entity, such as legal, accounting, consulting or administrative work.

Highlights from the HITECH's impact on HIPAA:

• Expanded obligation and direct regulation of business associates
• New restrictions on use and disclosure of Protected Health Information (PHI), including sale and marketing
• Affirmative Notification of Breach Requirements
• Increased Enforcement and Penalties, including applicability to Business Associates
• Federal security breach notification requirement
• Useful Tips to get the ball rolling:
• Develop an inventory of your current Business Associates and third party vendors.
• Develop a PHI data flow map that maps PHI data to critical systems and assess whether the systems can meet the new standards
• Identify entities with which you share PHI that may be subject to the same privacy and security rules as covered entities and carefully manage data exchanges with them
• Get your Legal department involved now and draft new legal agreements for business associates that comply with the Act
• Update your HIPAA privacy and security policies and procedures
• Develop or modify your existing Breach Notification Policy to comply with state and federal breach notification provisions.
• Develop a comprehensive Incident Management policies and procedures framework that help achieve compliance with not only HIPAA but also other applicable regulatory requirements, industry standards, and internal requirements

Posted by Branden Williams at 6:38 AM | Permalink | Comments (2)

Why is Requirement 11.2 one of the most failed by merchants and service providers alike?

Requirement 11.2 has shown up here a few times, but after looking back, I never really explored the issues in detail. Those who have been unfortunate enough to attend one of my sessions where this topic came up know where you can make a mistake.

Requirement 11.2 mandates quarterly scans for all hosts in scope for PCI, both internal and external. Scope reduction techniques like segmentation can do wonders for limiting what needs to be scanned, but makes the biggest impact internally. In one of my case studies, I talk about a customer that reduced the number of in-scope systems to less than 1% of their infrastructure thanks to good network segmentation. From a risk & compliance perspective, that alone pays for any added cost associated with new equipment and maintenance.

So what's the big deal? I mean, seriously, how freaking hard is it to scan a few systems? Isn't that how security became mainstream in the first place? Vulnerability scanning? ((Tongue in cheek of course!))

The fact is, of all of the requirements in PCI, 11.2 is one that companies struggle with more than they care to admit. In more than half of the PCI assessments we did in 2008, Requirement 11.2 came up as an initial gap. If it's just scanning, why can't we get it right?

Two reasons.

Reason the First: You scanned, but you forgot to obtain CLEAN scans for every quarter. Remember, the testing procedure for Requirement 11.2 states that QSAs must "Verify that the scan process includes rescans until passing results are obtained." Just scanning is not enough, you have to scan, patch, and re-scan until you have a clean scan ((How many times shall we put "scan" into a sentence?)). Most companies do well on their external scans; it's the internal ones that trip them up. The reasoning on why this occurs is usually something like, "Well, the firewall blocks that type of connection, so you can't exploit it from the outside anyway."

Sorry chief, that doesn't cut it.

The hardest part for companies to deal with is managing the vulnerability lifecycle. Companies must play all four parts of the vulnerability management quartet: Discover, Patch, Retest, and Close. Companies tripped up by this requirement typically stop at the first or second part, leaving the rest unplayed. Try listening to a song you know well, but instead of all of the instruments, imagine what it would sound like if played by only two instruments instead of four.

Vulnerability Management is exactly that, a management process that must oversee the tactical steps required to comply with 11.2.

A QSA will require four quarters of CLEAN scans!

Reason the Second: You scanned externally, but forgot to scan INTERNALLY. Yep, strange as it is, this is actually as common as Reason the First. Back in 2004 when I first started doing CISP assessments, companies faced with complying with the monthly scan requirement (at the time, Requirement 10.2) always found some geeky tech guy from their version of the Pit of Despair to do this work. As a testament to how far information security has come in retail, guys like that are not relevant anymore. That guy has gone on to earn an MBA and maybe is a manager or director now, or maybe he just left retail and went to a company more suited to his skillset. Regardless, that guy left a gap that remains unfilled.

Expanding on the management problem described above, internal scans suffer the most. Countless companies I have worked with put internal vulnerability management on the back burner and only focus on external security threats. Remember the Armadillo Network Model? Hard crunchy exterior, soft chewy middle? Works great if you have no insider threat, and there is no chance someone might accidentally open up a vulnerable service through a mis-managed firewall change.

A QSA will require both internal AND external scans!

Don't let your next PCI Review become a PCI COMPLIANCE FAIL because this critical periodic maintenance requirement was overlooked.

Posted by Branden Williams at 6:00 AM | Permalink | Comments (2)

The following is a guest post by Matt Wilgus, Technical Services Practice Manager for VeriSign's Global Security Consulting group.

While the aforementioned question rarely gets formally asked, it is a decision information security offices deal with all the time. Often the security office also handles compliance initiatives. Given the limited resources, is it better to comply with requirements, if the opportunity cost is investing in a project which could bolster security, but not meet compliance initiatives?

If an organization is secure than the organization should likely appear secure; however, this is not always the case. The extent an organization is secure is open to perception and often boils down to risk tolerance and risk acceptance. However, what really drives tolerance and acceptance? An understanding of the business environment is the primary driver, but legislative and regulatory standards also come into play. These standards mandate organizations implement a certain level security in order to conduct business. Organizations deploy a combination of qualitative and quantitative methods to determine if they can accept the risk in a network, application or environment. Third parties also use similar methods to determine the security of an organization.

Over the past 15 years there has been plenty of legislation and regulation to bolster security in nearly every industry (e.g. HIPAA '96, GLBA '99, CISP '99/'04 PCI, NERC '03) and nearly all companies face some compliance requirements. Some of the regulation focuses more on privacy than security; however, there are plenty of commonalities. Additionally, there are federal and state related security standards (e.g. FISMA 800-53, SB 1386) and independent programs from the ISF, ISACA, ISO, etc.

The aforementioned items have improved security and generally set a decent bar, but many argue that organizations now only attempt to meet the standard. If compliance requirements didn't exist, most organizations probably would not have better security than they do today, but some would. If compliance regulations did not exist, security could become a differentiator amongst competitors. There could be a free market on security standards. One benefit would be an organization could better quantify what a security feature is worth, rather than being seen as a cost of doing business.

So it is a decision time between two solutions. Invest in Solution A with excellent coverage on compliance, but provides little in terms of additional security benefit, or invest in a Solution B with little compliance relief, but dramatically improves the quality of security? The security purest would choose the latter; however, doing so probably underestimates the "consider yourself accountable" effect (a.k.a. CYA). It also underestimates that not meeting compliance regulations creates a never ending project.

For the few organizations not governed by any regulations (i.e. those cash only, privately held, single employee entities), try to be secure. For all others, appearing secure may be good enough.

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

The following is a guest post by Shaun Fothergill, the EMEA Practice Manager for VeriSign's Global Security Consulting group.

The tidal wave of regulatory compliance issues has intimidated the brave and petrified the frail, those who once played lip service to these issues are now looking for very serious answers from very serious questions. How do I comply? What do I need to do? What will it cost me? How do I keep compliant?

The problem is that there are so many regulatory issues we need to consider and each of these seemingly having their own security nuance that needs to be addressed.

Listed below are just some of the compliance issues businesses need to take into account:

• Data Protection Act?
• Human Rights Act?
• PCI DSS
• Access to Health Records Act?
• Sarbanes Oxley?
• International Accounting Standards?
• Proceeds of Crime Act?
• Patriot Act?
• Financial Modernisation Act (GLB)
• Money Laundering Regulations?
• RIP Act?
• Electronic Communications Act?
• Electronic Signatures Regulations?
• Electronic Commerce Regulations?
• EU Privacy directives?
• HIPAA?
• Companies Acts?
• Basel I and II?
• Freedom Of Information Act?
• Disability Discrimination Act?
• EU 8th Directive?
• Mork and Mindy common alien law?

The PCI imperative is just one compliance issue that is gathering even more momentum, in the US many institutions are now deploying compliance solutions based on many days and months of gap assessment and remediation planning. Similar initiatives are appearing in Europe and no doubt will impact Asia Pacific in the months and years to come.

But what is really at stake? What should a business really consider? What makes compliance an opportunity and not a problem? How can the pain be used positively?

Solid common sense compliance is fundamentally part of IT Governance, and IT Governance is part of business governance that is fundamentally part of sound efficient business practices.

If sound and effective business practices lead to an IT infrastructure that is more closely aligned and effective then perhaps there is another view that places regulation at the heart of making positive and effective change for business. Whilst governance and compliance are very real and serious needs there is a bigger opportunity for business and IT to collaborate and be more cost efficient. IT alignment within a business is crucial if the overall business is to be "compliant." If we consider that, then the wave of regulation is going to "hit" the organisation no matter what we think or do, would it not be better then to consider the IT/Business efficiency possibilities of regulation?

Compliance is NOT just a security issue, compliance issues reside across the entire IT stack and requires the ability to "translate" the business and compliance requirements into real solutions across the entire IT supported business. IT should where possible support a business as it addresses the regulatory landscape appropriate for its industry. Keeping in mind the "business" owns the requirement to comply.

In my view, businesses requires a framework to address the compliance stack, a baseline of IT controls and an enterprise wide management structure to keep it that way.

Many businesses have not taken the advantages of common control requirements across a range of IT compliance issues. Does your organisation have a baseline set of controls that can be managed thus providing you the ability to manage your IT infrastructure effectively? Do you have a baseline? Common industry frameworks exist, ISO270001(BS7799), ITIL, COBIT and risk processes such as COSO. All these can be leveraged to support the development of a common control construct.

For countless years IT has generally been so pressured to implement rather than have the time to design effectiveness into the systems they support for business. Perhaps now is a perfect time to work with industry frameworks ones that drives cost effectiveness and business/compliance alignment.

Its my belief that a solid compliance framework (DNA) can be used to exploit the overlap across a range of compliance issues and build in a set of common control requirements--a compliance framework and baseline. Regulation can therefore be used to crystallize focus and add significant momentum to the business.

The "opportunity" or "catalyst" should be to build a common operational control framework that could support a myriad of regulations, then demonstrate control effectiveness and exploit the common requirements thus leading to tighter effective alignment between IT and business.

IT can manage and be measured against these common elements, automate costly processes thus providing a cost effective and flexible secure IT structure tighter aligned to IT.

Compliance and regulation issues will always be with us so there is a real opportunity to build in greater business and IT effectiveness, by exploiting and building a common compliance DNA. If we build into our architectures a common set of controls, we will gain much greater business advantages. Those with insight and drive have already began this process.

These types of initiatives may just provide the opportunity to do something outstanding - construct a secure IT and Business Compliance DNA.

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

The following is a guest post by Fred Langston, Sr. Product Manager for VeriSign's Global Security Consulting group.

With the stampede to the next big thing gaining speed, Cloud Computing and Cloud Services face the standard, yet utterly preventable, horse-before-the-cart security conundrum. Anytime paradigm-shifting technology that saves money and decreases operational costs hits the market, two things are certain - 1) your company, just like 99% of the other companies in your vertical, will be running with the pack straight towards rapid adoption, and 2) security tools, techniques, and control technologies to find and mitigate the huge business risks associated with the new cloud services are:

• Lacking in essential functionality, scalability, or cloud-wide scope
• Not based on well-vetted best practice policies or standards specific to each particular cloud environment (because none exist yet!)
• Not able to provide the same level of visibility and granularity in security controls your company currently employs in their non-cloud, non-virtualized IT environments

Most likely, little (if any) thought has been given by the business about exactly what your company's security requirements are for most cloud computing projects other than, "Our Cloud Services provider has assured us that..."

So, what are the InfoSec troops, fighting in the trenches, able to do to create the most secure use of Cloud Services possible, other than losing sleep? Well, anyone that knows me knows I'll spout a best practice solution for everything under the sun given a sliver of an opening. It's my nature. But, not here.

Cloud services seem to me to impose on us a devilishly more complicated, already barely tenable enterprise security tableau that we must design, implement, and operate in perpetuity. Like security's not already hard enough or not already too expensive for management. Should we just resign ourselves to the fact that essentially we can no longer provide the security we expect for those outsourced cloud services, that it's Contract's and Legal's and Audit's problem now and not ours? Or, do we demand the right to dig? To dig deep into the cloud service provider's...well, everything?

Why would we not hold a Cloud Services vendor, who's running their security infrastructure in a very similar if not identical manner as a Managed Security Services Provider (MSSP), to the same standards of service that we demand of every MSSP in the space? How logical is that? If they really are protecting the systems, networks, and data to the level they promise to contractually, why would they not have the same set of data ready to share with us about security operations in 'our cloud'? Only the Cloud provider can provide this information and that makes them an MSSP for the Cloud as well, by default. They have the firewall logs, IDS/IPS alerts, configuration data and the like for our cloud.

So, as an MSSP, I have to ask, "Where's my daily aggregated alerts, change control logs, Firewall Rule changes etc, etc?" Seems to be a double standard we really can't continue to live with if we plan on holding the line against the 'bad guys'.

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

A couple of weeks ago, I jotted down a few thoughts on the letter from the NRF to the PCI-SSC about the PCI Standards. My post was a bit rant-ish, but Anton Chuvakin threw down a great review in his blog yesterday.

The only point that I wanted to add a different opinion on is the use of WEP.

I've been a proponent for wide open wireless networks in corporations for a few years. I argue that because network compromises are either hit-or-miss with advanced encryption technologies, most hackers default to attacking hosts instead. One of our own testers is known to breach networks that security professionals thought were virtually impenetrable. He didn't do it by packing a Cray into his car. He just set up a louder, fake access point that caused a laptop to associate with him, then launched an attack against that laptop.

Instead of trying to protect the network, why not assume that wireless networks are the equivalent of a user operating from home, and make that user interface with it in that manner? Sure, you can cut down on the noise by doing some basic filtering of MAC addresses, or even a basic WEP key. But inside that setup, run VPNs with firewalls on the endpoints (BOTH sides) to connect the machine to the network. Treat a user sitting in your office using wireless as a remote user, and treat your wireless network the same way you would the internet.

From a handheld device perspective (like the ones often found in retail), things get complicated. Almost to the point that it is virtually impossible to continue their use without upgrading them to WPA/WPA2. Add to that the key management issue that can arise when faced with a pre-shared key (which most of those devices have).

Fundamentally, weak wireless security will be compromised. ASSUME it is compromised. Then build your controls around that hostile intermediary. You have already done it at least once, just duplicate it here. Where have you done it? Probably at least two places. 1) Remote access as I mentioned above, and 2) your external website. In both cases, you assume the internet is compromised (oh my stars, is it ever!), and build your security around that assumption.

Posted by Branden Williams at 6:03 AM | Permalink | Comments (2)

People often come up to me and say things like, "Wow, you really are passionate about your work!" Aside from the old "Do what you love, and love what you do" adages our great grandparents regurgitate to us when they see us struggling with some arguably trivial thing in our work lives, passion is something that people can see on you.

We've all sat through one of those talks at a conference or an association meeting where it is clear that the speaker is just going through the motions. Maybe they are not just reading right off the slides, but you can tell that the only thing they are thinking about is hitting the tables, bar, or airport. Did you really listen to their message? Or were you also thinking about hitting the tables, bar, or airport?

When you are talking to co-workers outside of security, do you exude passion for your work? Sure, they may not care that something you did increased productivity of the workforce by deploying a spam filtering solution, or that you helped an inexperienced netizen tell the difference between a real email from your company and a phishing attack.

I'm not trying to pull a Zig Ziglar on you, but stop for a moment and think about your current position. If you are in security, are you passionate about it? Does that passion come through in your interaction with co-workers? Do your projects get extra care and feeding because you really want to see it done right? Are you passionate about security?

If not, maybe you are in the wrong job. We need passionate people to evoke the change required to achieve our goals. We need people who care enough about security to spend the extra twenty minutes helping a curious co-worker understand why we need to block his MySpace, and offer alternatives so that he can use his break time efficiently enough to get his fix.

Security is close to a tipping point. We've finally made it past the whiz kid techie that knows some security stuff to organized security departments and functions that add value to companies. Passionate people will help spread the message farther and wider, further legitimizing our existence and importance!

Posted by Branden Williams at 9:47 AM | Permalink | Comments (1)

It's now day two of WWDC, and amidst the AT&T iPhone 3G customers crying foul at the upgrade price to the 3GS, we've seen previews of the newest revision of the OS X series, Snow Leopard. After listening to the keynote (btw, I am not actually there, just living vicariously through the twits that are), I finally understand why Apple did a total stoner's give-up on the name to the new OS. At first, I was a little bummed.

I mean, can't you imagine what the Apple commercials would look like if it were code named Cougar? Rawr!

Snow Leopard is largely based on Leopard, but with several core components rewritten or enhanced to add amazing new functionality that is making my mouth water like crazy. My first computer was a Mac--the old all in one that had the OS loaded on the first 3.5" diskette you put in. Total awesomeness. In High School, I discovered the greatness of Unix with my first internet account through Netcom. Then running some Linux machines in the lab at school. Man, I hosed MANY a Linux box back in the day. After High School, I switched to PC for a while. OS 9 seemed stagnant, and at the time PCs were experiencing much more of the cool factor than Macs were.

After OS X released, I'd always wanted to get back into Mac. So I took the plunge! Now that I live in the Mac world (except for my work PC... not bitter), I am very excited to see Snow Leopard continue to grow in functionality and integration into the corporate networks we live with every day. The Exchange functionality in Mail is looking super sexy! With the new line of eco-friendly laptops being released just before the release of Snow Leopard, there is no question that we will see a swell in the growth of this platform in IT.

OS X has largely flown under the radar from a security vulnerability perspective. That's not to say that Apple has not had to scramble to fix some serious vulnerabilities in the past, but when you look at the number of vulnerabilities in OS X over its lifespan versus say Windows XP, it is largely flying under the radar. Also, consider that Microsoft owns anywhere from 85-90% of the PC market depending on error and data source. If I were a bad guy, I would target something that will get me the biggest bang for the buck, or Microsoft Windows.

As Apple's market share grows, this will change. This article from Darknet UK suggests what many in the industry have suspected, Apple is woefully unprepared and may end up becoming a victim of their own success.

Software vendors are sometimes pressured to push software out the door before being able to complete security reviews. I know this because I used to write software for a company that routinely did this. Security is something that is an afterthought in most of the development world. Instead, companies like Apple, Microsoft, and Adobe (as mentioned in the Darknet post) should put their software through the rigors of code reviewing technology to find as many vulnerabilities introduced by sloppy coding BEFORE releasing the product to the world.

The Ready-Fire-Aim method is the way we deal with security in software today. Release it, wait for something to happen, and then fix it later on. It's like the Dump & Chase method in hockey. You are relying on your offensive players to chase down the puck on the opponent's side, beating their defense, while using your own defense to keep the puck in the zone.

In order to move that Aim back one step where it should be, we need to focus on security before code is released. Even to the point where we might choose to delay a release by a month in order to find and fix these vulnerabilities. The easiest vulnerabilities to fix are the ones that don't show up in the final code base in the first place.

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

VeriSign consultant Nick Coblentz published seven quick tips for preparing for an application assessment. If you use custom applications for any of your business, you should have them regularly assessed. Developers are human, and we (I used to do dev work) make mistakes.

I'd like to augment the list based on recent client experience. These are really two ways to say Build a Contingency Plan.

Expect thing to go wrong - ESPECIALLY if you are testing against production systems. Expect that the whole application will bomb. How will you recover? Do you have staff on-call that can restore services in hours or minutes? Remember, the most relevant tests will be against production critical applications. Applications that, if inactive, will impact your business or customers directly. Build that contingency plan!

Expect thing to go REALLY wrong - You are testing against a QC environment, production is not tested directly... What could go wrong? When things go wrong, they usually do it in a stellar way. Like the big guy that thinks he'll entertain folks by jumping off the diving board, only to slip and belly flop. Many times, our applications rely on other services, or have access into other core areas of infrastructure that testing can impact. Are you prepared for a network outage? What if the application starts acting weird and fills up your interweb tubes? Build that contingency plan!

Go check out Nick's post!

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

Voltage has a new feature on their website, a map of data breaches with an approximation of the affected geographic area (or at least the location of the breached entity's HQ). This is a nice compliment to the Privacy Rights site which lists all reported breaches, chronologically, since the Choicepoint breach in 2005 that exposed a reported 163,000 records.

I spent some time clicking around and really enjoyed playing with the different views and getting a perspective on where these things happen. Looking at the map, it's really not a big surprise, but the most significant thing is the lack of global breach announcements (or lack of data). The number of countries affected are in the low teens, which we know is not accurate, but the lack of data breach notification laws in most countries affects what we know.

Enjoy!

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

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)

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)

PCI is still a hotly debated topic nearly four and a half years after its initial release on December 15, 2004. You didn't have to visit too many after hours parties or exhibitors at RSA to see that.

Most of the criticism of PCI comes from people who really don't understand it, or understand how to use it to their advantage. And those people fall into two categories themselves; those who are green to PCI and are overwhelmed, and those who love their soap box.

Those in the former bucket just need time to get up to speed. PCI, like Rome, was not built overnight, and it requires weeks of study to fully grasp how it will affect your environment. There is training available from a couple of industry sources, though my personal preference is that any training on payment security should not stop at PCI. I have a solution for the card companies to address the latter group directly, but more importantly, address the industry at large to demonstrate that you really do focus on information security.

I propose that the founding members of the council (Visa, MasterCard, Amex, Discover, and JCB) consider two ways to demonstrate PCI Compliance. The first of which is to complete the PCI DSS just like they would do today. Nothing new there.

Here's the twist.

The second method should be met by demonstrating a mature ISO 27000 security program, potentially certified under BSI America. That serves two purposes. The first purpose is to accomplish the intent of PCI DSS, protecting the data. The second is to combat the nay-sayers who say things like "I can't wait until this PCI crap is over so I can get back to security¹." In reality, those nay-sayers were doing a poor job at security before by only focusing on problems that interested them, not ones that were in the best interest of the customers, shareholders, and employees of the company.

If the card brands gave merchants and service providers the option, I think you would see the majority choosing PCI DSS, and only the most savvy choosing the ISO route. The best thing is that the card brands could fight the fires on two fronts. They can continue to coddle the laggards, and improve corporate information security for those that wish it. Most security professional agree (four out of five dentists?) that PCI is not the scariest thing out there, by FAR. But if you use what you learn from PCI and improve upon its required baseline, you can use the ankle-biting nature of PCI to also subdue his bigger, more ornery cousins PII and the State Data Breach Laws².

_______________________________
¹ This is an ACTUAL QUOTE from one of my retail contacts!
² Sounds like a great name for a band!

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

I hope to see you there! I arrive on Monday and will be at the welcome reception about halfway through, and am leaving at lunchtime on Thursday. You can find me at the VeriSign ESS Booth (not the big one up front) at Booth #1454. It's in the back, so you have to look for it!

I will be manning the Retail Security area of our booth on Wednesday from 11:00 to 2:30. Come by and see me! Also, if you have not done so already, follow me on Twitter (http://twitter.com/BrandenWilliams/), I'll be tweeting from the conference and the booth! Who knows, maybe we'll end up at the same crowded bar filled with people arguing the merits of DLP!

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

I've been writing Herding Cats for over a year now, and with all this talk about DLP, I wanted to dust off my FIRST EVER Herding Cats.

Have you ever wanted to see if sensitive data your company protects exists outside of designated areas? Maybe you are looking for Personally Identifiable Information (PII), intellectual property, or cardholder data that might be sitting around in flat files. I suggest turning to Grep¹, a GNU searching tool that is included on most Unix-based operating systems (and there are MS ports)!

Grep can use the power of regular expressions to quickly search for patterns in files. The results obtained will help you triage data leakage that may occur through the normal course of business.

I was recently working with a customer who found additional consumer information in batch files received from a financial institution. I am not talking about the consumer's hair color or meal preference. I am talking about their social security numbers. Our customer had no idea they were receiving this information, and yet they would likely be liable for its disclosure if a breach occurred.

The method described below is not foolproof; however, it will find the majority of files containing sensitive data.

It will not reliably (without additional tweaking) find information encoded inside binaries or database files, but you can use it to look through compressed files² and flat files.

Let's say you wanted to take a cursory look at data that could contain social security numbers. Your grep command would look like³:

grep -rl "[[:digit:]]\{3\}[-,[: space:]]\?[[:digit:]]\{2\}[-,[: space:]]\?[[:digit:]]\{4\}" / > files-to-triage

In this command, we are recursively (-r) looking for any file that has nine digits in a row, with or without delimiters, and listing those filenames (-l) into a file called files-to-triage. After doing some test runs with this, I discovered that this will match quite a few files that do not have any of this data, but I think I could filter those out pretty quickly.

What if you wanted to look for stray cardholder data? To find most variations of valid cardholder data (apologies if I missed any) that would occur in a solid string of numbers or blocks of four separated by dashes or spaces, you would type:

grep -rl "\(\(4[[: digit:]]\{3\}\)\|\(5[1-5][[: digit:]]\{2\}\)\|\(6011\)\)[-,[: space:]]\?[[:digit:]]\{4\}[-,[: space:]]\?[[:digit:]]\{4\}[-,[: space:]]\?[[:digit:]]\{4\}\|3[4,7][[: digit:]]\{13\}\|3[0,6,8][[: digit:]]\{12\}" / | mail -s "Sensitive Data Report for `uname -a`" sensitive_data_reporting@company.com

This is what it looks like to write a regular expression that will search for most known types of credit card data. Regular expressions look like a work of art when viewed by the trained eye, but like hieroglyphics for the rest of us.

But what is that new fancy piece on the end? Say you wanted to run this regularly and email it to a report gathering mailbox. Provided your server has the mail program installed and its communication with a mail server is not blocked by firewall rules, this may be possible.

The automation can get pretty sophisticated from here. You could enhance the regular expression more or further parse the output to remove false positives, have the information dropped into a database or aggregate report on a daily basis with scripts, or simply just run it on a schedule from cron.

Now keep in mind, this is not a foolproof approach, nor the most efficient way to search for these types of data. There are several commercial packages on the market today to choose from that will do what you see above, and much more. But if you are looking for a starting point to see if you have a problem, using open source tools like Grep can be a cost-efficient way to see how deep the hole really goes.

____________________________________________________
¹ http://www.gnu.org/software/grep
² To do this, you need to use 'zgrep'.
³ You may have slight syntax differences in your regular expressions. Non-maintained versions of operating systems need not apply.

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

I'll admit, I'm not the insomniac whose brain refuses to shut down because of something like a skimmer. They do scare me. Less from a personal liability perspective and more from a corporate liability perspective.

Have you ever seen a real-life example of an ATM that has been doctored with a skimmer? Today is your lucky day! One Gizmodo reader submitted his pictures and story.

Maybe I'm crazy, and maybe it's just not that big of a deal anymore. The bad guys are getting very crafty now, and able to fit skimmers to specific ATM models. It used to be that if you used an ATM regularly, it would be very easy to tell if someone had tampered with it. Stray wires, duct tape (NOT DUCK TAPE), odd cameras or mirrors, all of which should be red flags to any user of that magical machine that makes you feel like you win every time you play with it!

Remember those old "fake ATMs" that were essentially just big skimming devices? I think many of us became wary of the generic ATM machine in a parking lot after that. But we're not talking about that here. We're talking about the ATM near your house that you visit every week, and you may not even be able to detect it!

At a minimum I would suggest that you disable the ability to withdraw funds from anything but a checking account from an ATM. Hopefully that should at least minimize the amount of money you would be out if you fell victim to such an attack. Any more suggestions than what is above might stray into the personal finance realm, and I'll let those guys blog about that!

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

Have you seen it? OWASP recently released their Code Review Guide to the general public for download! I'm very happy to say that one of our own consultants was a contributing author, Jenelle (Chapman) Davis!

This book goes through the basics of preparing for a review, understanding how threats may present themselves, to the more advanced topics of reviewing code for technical controls, to even giving suggestions for common languages or platforms on where to start. If you are interested in code review, you should understand the concepts in this book at a minimum. Slowly, but surely, we're starting to see more and more information be made available on this topic, and hopefully this will begin to spread around the desire for this type of service.

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

Kotaku recently reported that a cache of Xbox 360s and PlayStation 3s offloaded to Circuit City has tons of fun data on them. Smaller merchants are buying these things for pennies on the dollar in hopes to resell them for a profit in their stores. I've heard that these things are everywhere!

Folks, don't forget, that every one of these devices that you plug into the wall or has a battery is basically a computer. Sure, it may not be the one that you are reading this post on, but it is a scaled down version of the same technology.

You know that VOIP phone sitting on your desk? Yep, a computer. Aside from the data security issues associated with outdated or known vulnerable software, there is data on that thing. How long it lives, or what it stores depends on the device. Sure, my Wii only has my family's Miis on it and the code to my wireless network. But not the REAL wireless network, a DMZ one that I let all my security unconscious family and friends use. There is nothing in the 242 or so data units on the device that I would not be ashamed of posting here in this blog.

Can you say the same for your computing devices?

If not, then BE SURE to destroy all of the data on the device before handing it over. For appliances or self contained units such as TiVos or PS3s, you will void the warranty by sanitizing the drive, but if you are disposing of it, you probably were out of warranty anyway.

Regardless, hard drives are cheap right now, so using the super destructo method of a big magnet or a commercial shredder certainly becomes a more reasonable solution!

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

Last week I moderated a panel at a PCI focused dinner in Chicago. Big props to the folks that helped to plan this (Alex, Melissa, Ben, and Diana from VeriSign), the event was great! The panel participants were heavy hitters from the industry including Anton Chuvakin from Qualys, Davi Ottenheimer from Arcsite, and Bill Cook from Wildman Harrold.

Anton has a few great points from the event that he has posted on his blog here. We had a fantastic discussion, and there were even great discussions among the panelists that revealed conflicting opinions. We had so much discussion that we were unable to go through the entire list of questions I had prepared. I had thirteen, and we only were able to get through THREE in the seventy-five minutes we used!

Side note... the guy next to me on AA1882 to BOS is chuckling so hard at Madagascar 2 that he is shaking the whole row. WOW. Too bad I don't have my ratchet set, I could secure these seats a little better. And yes, I often do write at 30,000+ feet.

The audience and panelists focused on the word compliance and how it differs from the terms security and validation. It is obvious that the scrutiny on PCI is higher now than it was during its initial rollout. Merchants are crying foul saying that card brands are using this to protect their investment into outdated and insecure technology. Legal cases challenge both fines and statements made by Visa recently revealing that there has never been an instance of a compliant (remember the difference between compliance and validation) entity being breached. And everyone is disgusted with the vendor that claims to solve all of your PCI problems by buying his technology.

We're at a crossroads, methinks.

Today, Bob Russo and other industry pundits (one of which has absolutely no business being a part of the inquiry except to irresponsibly use his position promote his own incorrect and misleading propaganda thereby making retail CIOs look like old relics that cheer for this fancy, new thing called EDI... yes, you guessed who it is) will go before the House Homeland Security Committee to try and answer the question, "Do the Payment Card Industry Data Standards Reduce Cybercrime?"

Crossroads.

One thing that was clear from the panel is that everyone agreed PCI has pushed data security projects farther inside their companies than any other measure to date. If you are reading this out there and disagree, it may take a breach for your management to see the light and invest appropriately. We also all agreed that an amazing amount of money for security projects magically becomes available after a breach.

After listening to some of the stories about other QSAs that the audience brought, I think I might have stumbled upon something. We've all had someone explain a situation to us that does not appear to represent a compliant solution. Not only are we sometimes mislead by a lack of context, but I think something a little more ominous occurs.

The number of QSA firms is impressive, and merchants are free to choose any one. Let's say that as a QSA you are dealing with a prized or significant customer. While the QSA is on-site, the customer pushes back (as I explain in my upcoming article... more on this later) on findings in various areas to see if the QSA will bend. If two or three managers push back in key areas all at the same time, there is a significant chance that a non-compliant situation might occur if the controls are inter-dependent.

Is the QSA remiss for not standing its ground or pointing this out? Absolutely. But as we have seen, merchants and service providers sometimes forget that they are still ultimately responsible for their own PCI Compliance. Once they have that compliant ROC, sometimes they run around their campus triumphantly waving it in the air as they dodge cubes in Prairie Dog Land.

Sit back from a moment and think about all those situations where you have pushed back on assessors. Depending on the items they reversed their position on, you may be in one of those situations where a breach is going to sneak up on you. Is compliance with PCI a guarantee that you are immune to breaches? Most (including the panel and all of the audience members agree) that it will not. Instead, implementing PCI correctly and layering security on top will give you the best shot you can get.

Remember, if you are able to convince your management to take security seriously, and responsibly use your position as a security expert to recommend controls that are good, cost-effective, and relevant to the organization, you will have a much better shot at preventing that breach.

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

Times are tough. Unless you are just now coming out of your winter hibernation, you are probably so beaten by that phrase that you are not far off from striking the next person that vomits it upon your day.

Listen up executives, this one is for you.

Breaches cost money. OK fine, I know that is not paradigm shattering knowledge I just dropped like it was hot. Still, executives miss the mark when trying to securely manage or grow their business. We know this because of the nearly daily additions to the breach list that PrivacyRights.org manages.

Executives have been failing at managing long term expectations for years. Any of us that work for a public company know that an executive's myopic management may not be able to focus past delivering the next financial report. If your executive is only managing the P&L, how do you expect her to understand that a long term investment in security is something that is both wise and necessary? She will have to explain the added costs and lower quarterly performance to her shareholders--never a pleasant discussion.

Heartland is the second public company to go through a major breach in the last few years that will have to disclose costs associated with the breach in their reports to the Street. In a weak economy with flat growth, shrinking margins, and weak performance, imagine what a multi-million dollar charge would do to the viability of your company. If you had $300 million in cash, and had to lose half of it in six months to cover a breach, would you be able to ride out the rest of the recession? Imagine if you had spent $50 million over one year instead to achieve the same outcome.

That's savings you can celebrate; but unfortunately, it can only be measured it in hindsight.

If you ask an executive that is dealing with a breach what they would have done differently, once they get through the stages (Denial & Isolation, Anger, Bargaining, Depression, and Acceptance), they will probably admit that they should have paid more attention to the risks associated with poor security practices. Big expenditures over time are ALWAYS preferred to massive expenditures in a short window.

THAT, my executive friends, is what should be keeping you up at night. Have you spent enough money to prevent something that could alter the lives of some, if not all of your employees, shareholders, and customers? As the top dog(s), you carry the weight of the world on your shoulders. Employees and their families depend on you to make rational decisions and position the company to outpace competitors. Shareholders depend on you to deliver return on their investment in the company. Customers depend on you to ensure that the company is stable, the products and services are of acceptable quality, and that you will exist.

Notice that ALL of those people that depend on you are focused on the long term!

As the not-so-new adage goes, you will pay for security now, or you will pay for it later!

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

Going through some email over here and looked through the recent edition of The Aegis from the Society of Payment Security Professionals, and found a great little snippet from Chris Mark entitled "Wear Your Seatbelt...and Maybe a Helmet." In it, he pulls a quote from the PCI SSC that seems directed at detractors of the PCI DSS. They state:

"The PCI SSC believes that the best way to protect cardholder data that is stored, transmitted, and processed is by implementing the PCI DSS and remaining in full compliance."

Chris points out that this seems to imply that PCI DSS is the high water mark, not the baseline from which you should build a program. It may just be that a technical writer may need to get in there (as a recent press release demonstrates) and add a few words, or it could be positioning on the part of the council. What Chris and many of us are trying to say is the quote should probably read something like this:

"The PCI SSC believes that the best way to protect cardholder data that is stored, transmitted, and processed is by implementing the PCI DSS, remaining in full compliance, and customizing additional security measures to build upon the base requirements of PCI as appropriate for their business."

Not all companies should consider end-to-end encryption for every single transaction they process, but then again, some should. Not all merchants should eliminate all paper records from their store locations, but then again, some should.

PCI is, and always will be, a baseline. It is based an good (note, NOT best) security practices, and is designed to be a catch-all for everything that touches cardholder data. There are obvious limitations to the catch-all, which is well addressed in the Self Assessment Questionnaire model that was released just over one year ago.

Just because we have not seen a fully compliant company breached doesn't mean that it is not possible. It just means that the bad guys don't need to poke holes in the standard yet because not all companies take it seriously.

Posted by Branden Williams at 1:30 PM | Permalink | Comments (0)

I know, it seems rare when we find it. I would have been hauled off along time ago and locked in the loony bin if I had stopped down every insane security discussion I was having by screaming SERENITY NOW!

I spoke with a retailer this morning that started a conversation with "We do security in an unconventional way."

At this point, my finger is moving toward the giant eject button I carry with me for situations just like this. Think about the "Easy Button," but instead of easy, it says EJECT and flies me far, far away.

Then the individual surprises me and says, "We treat our network as compromised instead of trusted, and adjust our security practices and posture accordingly."

. . .

YES! FINALLY someone gets it! Retail networks should NOT be trusted. Remember the example I often use about how hard it is to get into the corporate headquarters, let alone the corporate data center, versus only needing a crowbar (sometimes not even that) to get into a retail store location. Why do people inherently trust networks that they manage, but obviously have little to no control over?

If you are retailer, you should hire a company to break into your store locations to see what all could walk out the door. Maybe even up to and including the whole breaking and entering part (sans bodily harm). The benefit of what you will learn about your environment would have to be worth the $40K for an assessment, and some money for repairs.

Thank goodness for some serenity this morning; I needed it.

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

Here's a rare one from me, some Friday Night blogging! Why are you so lucky as to get this? Because I didn't have time to do it yesterday!

In speaking with a customer today, I remembered something that many companies (not this customer) are missing when it comes to building secure and compliant environments. It's really a scope creep issue when you look at it. Unfortunately, a very dangerous one.

What could this mystical threat be? That of core systems. Those systems that provide IT services to the larger server population. Here are a few systems to think about.

• Domain Controllers
• Anti-Virus Servers
• Log Aggregators
• Patch Management
• Remote Access
• Network Monitoring

Why are these a threat? Let's take a look at the special environments you built for your high security areas. Maybe you have some credit card data, so you have a nice little cardholder enclave. HR lives in their own zone (workstations too) because they have LOTS of protected employee data there. Marketing has a little separate area because they collect customer information for their uses. Seems OK right?

Well, all of those areas might use a common IT infrastructure to function! That means that an unpatched vulnerability in an Anti-Virus server could lead to the disclosure of sensitive data!

Unlikely you say? We've investigated breaches where this very thing has happened. Some common server that is relied on or trusted by protected servers is breached, then the bad stuff happens.

The lawyers, the consultants, and the PR daymare (because the worst parts happen during the day, not at night).

My suggestion to combat this is to do one of two things. Either secure those common servers into vaults (and maybe in their own firewall zones), or duplicate the functionality inside each zone of the firewall to reduce the impact that compromising a major infrastructure item would have.

Now, off to enjoy the weekend. See you for more fun next week!

Posted by Branden Williams at 3:53 PM | Permalink | Comments (2)

Are you one of the many companies that rely on satellites to communicate with your, uh... satellite offices? We security professionals often ask hard questions about how that data is protected en-route and usually are quickly dismissed with a "Oh, it is too hard to do and would require a six-figure investment in hardware to accomplish."

Well, thanks to Adam Laurie, you can do it for around $1,000!

If you are relying on satellite communications, you should now be asking those hard questions of your provider, and making sure that you have acceptable encryption on those lines preventing someone from intercepting or injecting traffic into that stream.

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

I'm not Seth Meyer. I'm not a television star. I don't have a team of writers feeding me stuff on cue cards.

That said....

According to an article by Fred Aun, Peter Alguacil from Pingdom released a report recently suggesting "there are probably 219,000 sites with outdated SSL certificates."

Probably.

Fred, who rounded the original 219K figure from Peter up to 250K in his posting, goes on to describe the "bit of math" that Peter used to come to this conclusion using data from two different sources. First, Netcraft estimates there are one million sites with valid SSL certificates. Next, a report by Venafi released in 2007 suggests 18% of Fortune 1000 sites had expired certificates. So then Peter does the math and says that since Netcraft does not count invalid certificates, if we were to estimate 18% of one million, we'd probably end up with 219,000 sites.

Really Peter?

That sounds a lot like the math we used to get in the venture capital world during the Dot Com boom. "There are 300 million people on the internet, and if I can get just 1% of those to pay me $20, we will have $60 million in revenue! IT'S SO FREAKING EASY! So your $10 million, no strings attached, cash investment is basically like buying bars of gold and leaving them in a vault! CHA-CHING BABY!"

Are there sites out there with expired certificates? Abso-freaking-lutely. Are they sites that you use every day and trust? Probably not.

Sure, we're all human, and sometimes we make mistakes. If a large company does not single source its certificates through a company like VeriSign that can offer a managed solution to prevent something like that from happening, it is feasible that sites like Google or Yahoo could end up with an invalid certificate for a few hours. It has happened in the past.

The moral of this story is, any time an alert comes up in your browser about a problem with a certificate, you should be wary. There are too many attacks out there to ignore those warnings.

The moral of this blog post is math is great. "Dot Com math" should be questioned.

Posted by Branden Williams at 5:46 AM | Permalink | Comments (1)

The first challenge to securing your data (or meeting compliance) is understanding where your data lives. An alarming number of people I speak with in the industry have no idea how bad their problem is because they only know where half of the data lives and goes.

HALF! That is a BIG problem.

Engaging in data flow mapping exercises can be painful. So painful, that you might be forced to look outside your organization for help!

Yes, VeriSign has a service that does this... OK, shameless plug complete.

Where do you start? In an article that I published last year entitled, "Data Flows Made Easy," I detail an adaptation of the Design Structure Matrix that can be used to help map data flows in your organization. The first step you have to take is to interview your teams and figure out if the implementation teams that live in the real world of IT have implemented the same system that the designers that live in their perfectly architected world created.

The one drawback to relying only on interviews is that you are victim to the Garbage In, Garbage Out problem. If you have never gone through this type of exercise before, you can be sure that you will have some inaccuracies.

But, when you have gone through the process and have something like Figure 6 in the article, you should find one of the many DLP vendors that have a data discovery feature in their tool to validate that the diagram is complete. Or, you can engage someone like VeriSign to bring in partners and consultants to do this for you.

Trust, but verify.

If you use the data flow method that I have outlined in the article, you will find that your flows are much easier to maintain, and you will spend less time explaining complex Visio diagrams to auditors. Several top, global retailers have taken the concept and converted all of their data flows into this format. It's the first step in our PCI Program Management offering, but could easily be used in any security or compliance program. It's a two-dimensional matrix that is begging for someone to write a cool front end interface.

Oh, and to those of you that tried to download the latest Herding Cats and got a Forbidden message, I fixed that, and set the SGID bit on the directory so that should never happen again.

Posted by Branden Williams at 8:20 AM | Permalink | Comments (0)

It's one week later. With limited public announcements, what is this post going to tell you? Well, let's start off by stating what it won't tell you. You won't find any gory details about the breach or the other parties involved. You won't find anything here that cannot be deduced using public information sources. You won't find anything here that has not been stated before.

So what use is it? How about we assemble some key points and do a little bit of analysis to understand how something like this can be prevented in your company.

According to the original press release, the investigation uncovered malicious software that compromised data that crossed Heartland's network. Before we start attacking PCI and saying that the standard should require encryption over any network, let's think about what the standard does today that would prevent that.

To start, PCI Requirement 5.1.1 states:

Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

We don't know what kind of malware this is, so we don't know if there are signatures to detect it; however, there are many types of software that can detect malware without signature. White-listing software is particularly useful here, and properly managed could easily have thwarted this breach.

Next, let's have a look at PCI Requirement 6.1:

Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.

Malware rarely finds its way onto a system that is fully patched. Exceptions would include a zero-day exploit, or someone that already had administrative credentials for the machine in question. Zero-day exploits for machines behind firewalls are not as probable as those in front of them (or workstation/desktop machines). Administrative credentials could be particularly crippling, but getting access to them can be tricky. You would not typically see those outside the corporate network, unless the attack targeted an individual or team inside of a company. Besides, we know that no default credentials should work because of PCI Requirement 2.1 (Always change vendor-supplied defaults before installing a system on the network).

OK... One more, and then I will stop (although you can keep going). PCI Requirement 11.5:

Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

This one is the key. Malware cannot go undetected on systems that have proper file-integrity monitoring performed. Note I said PROPER, but let's face it. Even a BASH script that computes a SHA-1 hash on all the files in a particular tree will find malware when it compares those hashes to previous versions.

CEOs, keep reading. Your part is coming, but first I need to address the CISO that is screaming at me right now.

Yes Mr. CISO, you are well informed. A targeted attack can be pretty effective against the base controls I mention above. The reality is that targeted attacks don't happen (in the US anyway) as much as you might think because the basic security principles mentioned above are simply not being followed. Why would a criminal invest countless hours and money creating a targeted attack when generic malware works just as well?

Mr. CISO, you should not give up. You need to understand the risks in your environment, and that starts with strategic things like governance, and tactical things like mapping out data flows. This also means that when you are ready to ask for funding to address a risk, you don't tell the board that the world will end with EVERY SINGLE ITEM on your agenda. Pick something appropriate, and SELL IT.

I know, you hate salespeople. Face it, if you are going to be effective, you will become one.

Now, Mr. CEO. As the Chief chief, you are responsible for all the things that happen on your watch. If a data breach occurs, you can bet that your compensation will suffer, your employees will suffer (through layoffs and poor financial performance), and in some extreme cases you will find yourself reporting to outside legal counsel instead of the board (this happens more often than you think). I'm not saying you should throw all of the company's money toward security, but you should be taking it seriously. Make your CISO (or CIO... and if that is the case, go get a CISO) do his research and justify his position. When he does, you should listen.

What can we all learn? Going through the motions of something like PCI without actually committing to it will land you in the "PCI Validated, but Compromised" bucket like so many before you. The Anti-PCI crowd comes in two flavors, the "It's Too Damn Hard" flavor, and the "It's Doesn't Address X Issue" flavor. Both of those flavors have valid points, but they are sooo 2006. 2009 is the time to OWN your security, and PCI is a great place to start.

If you are shopping for the easiest pass, or looking for an assessor that will pass a halfway implemented control, you are asking for trouble. 2009 is yet another year to do more with less, but don't skimp on something like this. A good assessor will provide you with the concrete evidence you require to secure funding and fix problems you have been sitting on for years. It's time to take security and PCI seriously and get your program in place to maintain them every single day. Why? Because breaches put their victims at a competitive disadvantage to their peers, thus impacting their long-term outlook.

Need help on finding a place to start? Drop us a line! We can help!

Posted by Branden Williams at 2:44 PM | Permalink | Comments (1)

One thing about Botnets that scares me is the amount of idle computing power that is available to the owner of the Botnet. Suddenly, things that were once computationally infeasible with one machine become plausible or even possible with thousands of machines.

It seems like most Botnets churn out SPAM right now to the tune of trillions per day. SPAM may be profitable--the fraud generated by the SPAM anyway--but in light of recent attacks, I wonder if there are more enterprising methods.

If Botnet owners didn't happen to have 200 PS3s laying around for a research project on SSL, they could develop a program to break a large task down into work units, and have each bot on the net work on one of those units in the background (just like how SETI works). [Thanks BU!]

Even better, maybe it could be an interesting way to re-use those empty cycles. Business idea for someone. Develop a legitimate agent that can do that, and pay owners of computers some cash value for their cycles. Better yet, have that agent look for malware and alert and destroy it. Maybe the best yet is have it be part of an anti-virus program. Enrique Salem (SYMC), David DeWalt (MFE), or Mingjiang Chang (TYO:4704), there's a freebie for ya.

I'd be very interested to see what kind of illegal profits could be squeezed out of botnets outside of SPAM. SPAM is one thing that everyone hates, but maybe those guys could be more creative and find other ways to bring in cash?

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

Finance and Commerce Magazine published an article based on a survey revealing that most companies are unprepared for IT risks.

*blink*

What? You mean that with all the emphasis we put on it, and all the spending after some of the biggest breaches in history, we're still not ready? This is not coming from the consultant who sees this stuff every day, this is coming from people working for these unprepared companies.

With the economic situation as it is, will your own employees finally turn on you and take advantage of weak security controls in your network?

This may be an unpopular position, but while the risk is definitely much higher for insider threat, it doesn't seem to make the news as much as the external breaches do. Maybe it is because most of the employees that are in a position to take advantage of something like that have too much to lose by committing such a crime.

This blogger is not sure.

Maybe things will get nasty for those companies who have ignored good security with employees facing the threat of an imminent layoff or being financially overextended. I would suggest there is a better chance of a hacker using an employee to exploit these poor controls, probably without them knowing it is happening.

Be it through phishing, social engineering, or just the right place at the right time, appropriate motivation may end up costing companies and their customers big dollars in 2009.

Posted by Branden Williams at 6:24 PM | Permalink | Comments (0)

The following is a guest post by Jonathan Care. Jonathan is a Sr. Consulting Manager inside the EMEA practice at VeriSign.

Why do we want to do a forensic investigation?
The goal of a forensic investigation is to establish certainty of fact in a particular situation, normally as part of an incident response. Therefore one chooses to perform a forensic examination when one needs to establish facts relating to activities performed on a computer. The scenario for forensic computing is usually around a litigation support case, for example, tracing fraud, unauthorised activity, illicit content perpetration, or other computer misuse.

Where are forensic investigative results commonly used?
Forensic computing reports are normally used as part of a court process, or an internal employee disciplinary event. Therefore one question that must be ascertained is where the case is likely to end up - if a criminal case, then forensic reports must establish certainty of fact beyond any reasonable doubt, whereas in a civil matter the forensic report must establish a balance of probablity that alleged activities did (or did not) occur. The burden of proof in a criminal matter is therefore a much higher hurdle to clear.

What kinds of businesses will use forensic computing?
Traditionally, forensic computing has been in use by the public sector law enforcement agencies, however it is now being seen as a mainstream activity as part of the ICT and corporate governance of commercial organisations. Where an organisation is operating in a regulated framework (for example, a financial services company), forensic computing can be seen as evidence of the duty of care required in loss management and fraud recovery. Typically, the use of forensic computing services depends on the risk appetite of the organisation, in addition to externally imposed regulation. For a company operating under the controls of PCI-DSS, forensic computing investigations can be seen as a best practice under principles 3,6, and 10. However it cannot be denied that undertaking a forensic computing investigation can be a timely, costly, and intensive process, although should the case end up in a court of law, then the omission of such an investigation can prove even more so!

Who is involved in a forensic computing investigation?
Forensic computing activities are best performed by specialist personnel - these can be either internal staff, or more commonly external experts. The use of external experts demonstrates impartiality that may not be accepted by an organisations internal employee. A recent case dismissed an internal IT manager as an "expert" due to concerns over impartiality and formal accreditation. Of course the use of external experts can add to costs, and the risk assessment must be made over potential losses in court vs. the costs of establishing a solid evidential base.

When to engage in a forensic investigation
As part of incident response planning, the organisation's appetite to risk should be established. Strategic and tactical planning in this area is essential - during the "heat and noise of battle" when an incident is detected, it is hard to make a balanced risk based decision that is in the best interests of the business. Scenario based planning should address:

• Where is this case likely to go? (criminal/civil court, employee tribunal, internal disciplinary, liason with security service providers e.g. Antivirus)


• What is the estimated financial loss? While stories such as "The Cuckoo's Egg" make interesting reading, commercial realities dictate that if the estimated financial loss is below the acceptable loss percentage, then a strategy of internal recovery - patching systems, reviewing firewall/IDS configuration, and moving on, can be appropriate. It is important to consider not only a single incident loss, but the likely annualised loss.


• How will the case affect the organisations external reputation? Due to data protection legislation, organisations are commonly required to publically state when personal information has been disclosed as part of an incident. This can range from the "lost laptop" through to web site breaches and fraudulent insider activity. It can be argued that the engagement of external digital forensics expertise can not only have practical and immediate benefit, but can also assist in the organisations PR activitity surrounding the incident, demonstrating a concern and care for the information under their control.


• Is the scope of the incident completely understood? In a qualitative analysis of the incident, an understanding must be gained of how much impact has occured. For example, in the "lost laptop" scenario:


• Was the data encrypted? Bear in mind that in addition to items stored on the hard disk in a secure area such as PGP's PGPZip or Virtual Disk) that the laptop may contain useful artefacts to an attacker in the web browser cache and history, or in email storage (for example an Outlook PST or OST file). If whole disk encryption has not been deployed, then there is a non-neglible risk of additional information security breaches.




• Were any authentication tokens (passwords, certificates, ID keys and so on) lost?
• Is the likely suspect known? (that is, is the suspect an internal employee/subcontractor, an external partner, or an unknown attacker from elsewhere)


• What logging and audit measures exist for affected systems?

• the scope of the incident is clearly bounded
• the external impact is low
• the loss is below the acceptable loss ceiling
• it is certain that the case will not progress to court

In addition, where the affected equipment involves card information in the clear, that an investigation is warranted to ascertain the business processes that caused this breach of PCI-DSS standards to occur, and that an impact analysis is highly advisable.

Posted by Branden Williams at 4:36 AM | Permalink | Comments (1)

The following is a guest post by JD Smith. JD is a Sr. Consultant inside the PCI practice at VeriSign.

PCI DSS 1.2 has several sections that require a security application to be used to satisfy a requirement. Some of these areas are file integrity monitoring, firewalls, encryption, wireless scanners, intrusion detection/intrusion prevention and anti-virus.

All of these areas have several tools available to address the specific requirement. However, what if a merchant needs to keep the budget to a bare minimum? What if there is absolutely no way a merchant is able to purchase several of these solutions straight off the shelf and pay the licensing associated with them without severely impacting the business?

Open-source solutions exist for practically every requirement identified in the DSS. What is open-source? Generally speaking, open-source is considered to be a solution for something is maintained by a community and is typically royalty free.

For instance when it comes to intrusion detection systems, there are open-source tools such as Snort that has matured over time and is known as the gold-standard for IDS. Many front-end analysis tools exist that use the Snort engine (e.g. Squil and BASE).

For merchants that must secure their wireless environments, open-source wireless scanning tools such as NetStumbler, Airsnort, and Kismet have been in the security toolbox of pen-testers for quite a while now.

Merchants who are struggling to find a powerful firewall solution while staying true to open-source should take a look at NetFilter. It runs on a Linux operating system and is able to handle as much traffic as most other expensive solutions.

Another major component of PCI DSS 1.2 is encryption. For solutions around SSL, OpenSSL is the premiere SSL/TLS encryption library. Also, OpenVPN is an open-source VPN solution which is useful for site-to-site VPN creation without having to spend a lot of money on a Cisco or Juniper solution.

Included in encryption would be TrueCrypt for file, folder and disk encryption solutions. It's open source, very flexible and provides extremely robust encryption options for a merchant.

Among other useful tools that a merchant's network security team should use to test the strength of their network is Zenmap for port and host scanning, and Firewalk for checking ACL configurations. Password crackers are useful for the security team to verify that passwords are configured properly. Some useful password tools are Aircrack (for wireless scanning), John the Ripper, and Cain and Abel. A favorite network service password tester of mine is Brutus which tests services such as FTP, Telnet, IMAP, POP3 and others that are sometimes available on a network.

It's important to keep in mind if a merchant chooses to stick to an open-source approach to assist with PCI compliance, the majority of the open-source security tools available only run in a Linux and/or UNIX environment. Therefore, network security staff or consultants need to have familiarity with this kind of environment.

Lastly, all of these tools and many others are discussed conveniently in one place: http://sectools.org/.

Posted by Branden Williams at 4:24 AM | Permalink | Comments (0)

The following is a guest post by Phil Fuhrer. Phil has many years of experience in the assessment and management of IT systems quality. In addition to his current work at VeriSign his interests include requirements, systems architecture and security technology.

Edward Deming is considered the father of statistical quality control .The "Deming Cycle" and his fourteen points for managing quality improvement are the most widely known parts of Deming's work.

The "Deming Cycle" is much like the Systems Development Life cycle and other methods that ratchet change allowing continuous improvement. Less well known is Deming's insistence that effective quality improvement can not be done without statistically stable quality measurements (Bell Laboratories Deming Quality class about 1996). As a statistician he recognized that attempting to improve an unstable or poorly understood system is non-scientific tampering.

The fourteen points are rooted in the idea that management must advocate quality in non-production line systems where success and failure cannot be counted or otherwise easily measured.

Security is a type of quality and cannot be measured by counting successes and failures. Restating Deming's fourteen points as security directives is a useful way to direct security management.

Deming's 14 points for management paraphrased and their security implications are:

1."Create constancy of purpose towards improvement". Replace short-term reaction with long-term planning. - Assessment, testing and compliance evaluation are tools to identify defects. Further analysis should be done to identify the root cause of defects and to systematically improve the processes that determine security level.

2."Adopt the new philosophy". The implication is that management should actually adopt his philosophy, rather than merely expect the workforce to do so. Often security as other quality dimensions only receive upper management attention when there is an abject failure causing resulting high cost or low profit. Management should adopt a security policy.

3."Cease dependence on inspection". If variation is reduced, there is no need to inspect manufactured items for defects, because there won't be any. - In security inspection should be built into production processes and not considered separate or add on.

4."Move towards a single supplier for any one item." Multiple suppliers mean variation between feed-stocks. - In security variation can be caused by overly complex interfaces between software suppliers and by incorrect or malicious user input.

5."Improve constantly and forever". Constantly strive to reduce variation. - As with other quality dimensions there is no such thing as perfect security.

6."Institute training on the job". If people are inadequately trained, they will not all work the same way, and this will introduce variation. This applies to both production and development staff. Security (as other quality) training is inadequate when it creates machine-like rote behaviors that reduce attention to variation (unusual security risks).

7."Institute leadership". Deming makes a distinction between leadership and mere supervision. The latter is quota and target-based. This fits for security.

8."Drive out fear". Deming sees management by fear as counter- productive in the long term, because it prevents workers from acting in the organization's best interests. This fits for security.

9."Break down barriers between departments". Another idea central to TQM is the concept of the 'internal customer', that each department serves not the management, but the other departments that use its outputs. In security while some barriers between production and development are needed, finger-pointing and miscommunication must be addressed.

10."Eliminate slogans". Another central TQM idea is that it's not people who make most mistakes - it's the process they are working within. Harassing the workforce without improving the processes they use is counter-productive. Security management by slogan is not effective.

11."Eliminate management by objectives". Deming saw production targets as encouraging the delivery of poor-quality goods. Real productivity is not measured by volume alone. Security and other difficult to measure quality dimensions should not be short changed.

12."Remove barriers to pride of workmanship". Many of the other problems outlined reduce worker satisfaction. This fits for security. Workers should take pride in Identifying potential security holes.

13."Institute education and self-improvement". This fits for security.

14."The transformation is everyone's job". This fits for security.

Posted by Branden Williams at 2:40 AM | Permalink | Comments (0)

What a confusing time it is for me those of us who just like sitting around all day and poking at the interweb through a browser. We have a rather nasty 0-Day exploit for Internet Explorer roaming around, and Mozilla Firefox makes Bit9's list as one of the most vulnerable applications in 2008 (surprisingly, IE is not on there).

The Internet Explorer 0-Day is so bad that some experts are urging users to switch to another browser. Naturally, the first choice for a number of users would be Firefox. But now Bit9 has released this telling report saying that it was one of the most vulnerable apps in 2008.

So where do you turn? Well, the list is not the prettiest. You could go with Chrome, but then you read the EULA. You could try Opera or Safari, but both have also seen major security vulnerabilities this year.

Maybe it's just time to punch out for 2008?

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

Something is going on. I don't know exactly what it is, but all the sudden I'm hearing more of this buzzword. "Cloud Computing" may be the buzzword for 2008. There are even blogs that dedicate content to it.

It sure seems to be thrown around a lot... especially in the economic hiccup we are experiencing right now.

Should we blame Gartner for its use? Only for using cloud computing and $3.4 trillion in the same article. I bet that's the root of the problem.

So what is cloud computing? Well, according to IEEE, "Cloud Computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, tablet computers, notebooks, wall computers, handhelds, sensors, monitors, etc." Essentially, a mashup of Software as a Service (SaaS), virtualization, and potentially even Service Oriented Architecture (SOA). I suggest that it is destined to become a generalization that has no real meaning on the surface, but requires detailed questions and answers before its true meaning is known.

That's where security comes in. When looking at doing anything with cloud computing, security professionals must understand exactly what is going on. The leveraged resources used to allow for cloud computing to work means that you have a lot of co-mingling of things. Data and systems that need to be kept secure will mingle with data and systems that don't. The whole strategy of using segmentation as a scope reduction technique (or just good practice) goes out the window with this type of infrastructure. Unless, of course, you create multiple clouds, but then that kind of ruins the whole paradigm, doesn't it?

As with most technology, there is a place for cloud computing in our infrastructure. It should neither be immediately shunned or lauded. Instead, do the due diligence required to get a clear picture of how it may impact your enterprise.

Posted by Branden Williams at 7:53 AM | Permalink | Comments (1)

After the year we had in 2007 with PCI related breaches, who would have thought that 2008 would give us more? I mean, after last year, who would have thought that we would see another major breach given the "lessons" we learned?

Um, I did. Fo-sho.

Why? Because early in my career I learned that most executives don't care about problems until they hit close to home. Like right under their nose.

We've seen two instances this year of companies that had validated compliance with a QSA, but were subsequently breached. Without specifically commenting on either of these cases, we have never conducted an investigation of a compromised entity and learned that they were compliant at the time of the breach. I've written about the quality of QSAs and the corporate responsibility, but as Will Smith so eloquently explained, parents just don't understand.

Many retailers are struggling right now. Guess what one of the first programs to get cut will be? YEP! The one that will prevent that breach from actually occuring.

One common theme I am seeing in many of my large retail customers is they seem to think that they will be able to transfer the liability of a breach to their QSA. I worry when I am sitting with a manager of the PCI program and he or she asks what is "passable" or something we can "cobble together for the QSA" knowing that it won't last past the QSA's flight out.

Don't laugh, this has happened multiple times this year. Or if you want to laugh, just giggle silently to yourself while making sure this won't happen to you.

If you are wondering what kind of liability a QSA carries, you can read the publicly available Validation Requirements for Qualified Security Assessors (QSA) v. 1.1. If you are at work and don't want to slip into a post-lunch coma by wading through this, here's the gist of it.

QSAs are liable for improperly performing the assessment, and willfully passing someone that should not be passed. We have to assemble a considerable amount of documentation when doing these assessments to justify our position. If there is ever a review, we have to show how we arrived at our conclusion. If we are unable to, there is where the liability can come into play.

If a merchant hides things and get's lucky because sampling did not find issues known by the merchant, the QSA may or may not have liability here. It depends on the circumstances, and more importantly, the lawyers. None of these clauses have been tested yet (to my knowledge) in a court, but that will change based on the events of 2008.

Regardless, as a merchant, you should not want to ever GET there. Brand damage aside (which I will argue may not be relevant in many cases), the fines that must be paid pale in comparison to the fees you will pay to lawyers and vendors to hastily assemble a compliant and secure solution.

Merchants must own and be responsible for compliance every day of the year. This means actually being compliant, expanding on compliance to become secure, and finally having a program in place to monitor and maintain that compliance 24x7.

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

Probably.

Well, at least one of mine doesn't. Let me take you through the scene I lived as I completed a routine checkup at my doctor's office last week.

After arriving and being called back, they did the standard how tall are you (thankfully, I have not shrunk), how much do you weigh (PRE-thanksgiving, thanks!), do you have a pulse, and is your blood pressure somewhere in between dead and explodingly high.

Yep, I said it. Explodingly. It's a smashup between a gerund and an adverb. An "adverunderb."

So after all the basic stuff, we sit down and review my medical history as they have it, including any surgeries or medications I have been on prior to my visit. As we're going through this, I noticed that they listed a medication that I have never been on. After watching the nurse edit my data in the practice's medical software, I wonder what it would be like if a doctor's office had a compromise. It's not too far fetched. Most store patient records electronically now, and many allow internet access right there from their PCs so that the receptionist can update her Facebook between opening and shutting the big sliding glass window.

Electronic medical records can be a good thing. Ask any of the MBAs that made a ton of cash selling computer illiterate MDs on how they can save time and money by investing in this wacky computer fad. But the risks associated with keeping this data electronically are significant.

Now here's where things get interesting.

So the doctor walks in, and what do you know, she types her FOUR DIGIT NUMERIC PASSWORD to log in. And it was not like she was using the numbers above the QWERTY part of the keyboard, she was using the 10-key numeric pad. Right next to me. Easiest password I ever shoulder surfed.

EVER.

Of course her little numeric password then gave her access to my entire medical history, including things like a copy of my drivers license, social security number, and medical insurance information and card. Think of the identity theft fun you could have with that!

So what are we to do? I will put this in the bucket of corporate responsibility. If your corporation is going to put technology in the hands of your employees, you are responsible for making sure they know how to use it securely and appropriately. Regardless of your company's size, or the type of technology being deployed.

And if I were a bad guy, this is the type of gold mines I would be going after.

Posted by Branden Williams at 2:30 PM | Permalink | Comments (1)

Yep, it's been a PCI heavy week. Want me to discuss other topics? T and suggest one!

Last week I sat through the Certified Payment-card Industry Security Manager training here in Dallas. The folks at Aegenis planned it at a hotel that happened to be about 10 minutes from my house, so getting there was easy. There were several bigwigs from the information security and PCI industry there with me in the sold out training, and the industry perspectives were valuable.

If you are not an employee of a QSAC and are looking for a GOOD source of training around PCI, data breach laws, and a detailed look into the payment industry, this training is for you. If you opt for all three days of training, you will be taken through the process first as an auditor, then as a manager. The tests are given on the final day.

For those merchants that have been begging for solid, industry-specific training around PCI, this is where you need to go.

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

Here at VeriSign, our email filtering is pretty effective. We have a corporate solution run by Postini (Google) that I am sure processes an amazing amount of SPAM for us. In most cases, one email that I would consider truly SPAM might slip through every couple of months. Not a bad track record.

Today one of those messages got through, and I was amazed at what the bad guys doing to try and commit fraud nowadays. I remember several years ago that one effective method to get money out of large corporations was to just send an invoice for a small amount to the Accounts Payable department. Somewhere in the next two months, a check for that amount would show up in your mailbox.

As corporations tracked invoices more closely, these holes closed up and the bad guys had to get more creative. They started going after individuals through phishing and other types of con games. An acquaintance of my wife got suckered into one of those a few years ago when she sent cash to a company she got an email from claiming to fix credit problems.

The message today was someone claiming to be a professor, and their title being "Head Payment Commission." The interesting thing here was that instead of an invoice, this SPAM apologizes for paying late! It includes a bank reference and a bogus bank account, with a set of questions that I would need to answer to get paid. Aside from the obvious grammar issues and OverUse Of Studly Capital Letters on Common Nouns Like "Wrong Account," they ask you to re-confirm the payment details to make sure that payment can be rushed. Here's what they are asking for.

1. Your Full Name:
2. Phone, Fax And Mobile No:
3. Company Name, Position And Address:
4. Profession, Age And Marital Status:
5. Working Id? D/Int?l Passport:

Note the bold underlines. I certainly cannot remember seeing anything like that on any supplier form I have either sent out or filled out. This is definitely something that smells like classic social engineering. Most social engineers would be a little more sneaky and only ask one or two of those types of questions among legitimate questions. They would then finish with a legitimate one or two to bury the one that should set the alarm bells off.

It's pretty ingenious, but nothing new. Bad guys have been doing this for years, and I would see this as nothing more than a smarter version of the Nigeria scams. We all know that stuff like this works, especially on people that are too trusting.

If it didn't work, it would not have shown up in my Inbox anyway.

Posted by Branden Williams at 10:43 PM | Permalink | Comments (0)

One major change to PCI version 1.2 is the new requirements and testing procedures for Req. 12.8. 12.8 deals with how merchants and service providers should handle their third parties that can affect the security of cardholder data. The card brands have told us in the past that they would not expect a service provider to prevent a merchant from being compliant, but that the merchant must understand that they will carry the liability for a breach at their service provider's site.

We've seen 12.8 morph considerably from PCI version 1.0 to 1.2. The intent was to help merchants understand how service providers deal with their data, and make sure that they are protected if there is a breach at their service provider. I still believe that the intent is the same, but the language around the requirement and testing procedure has been relaxed slightly, but still points out the liability. This means that you may not have to alter that master services agreement that was originally inked in 1979, but that legal on both sides must be made aware of the stakes involved.

There are a couple of industries that have unique problems as it relates to PCI. One of those industries is the travel industry (shout out to Yvette!). The service providers that they rely on provide some infrastructure (such as common use terminals, or shared ticket counter or gate space) that is virtually unmaintained, and the airports have been unwilling to put any additional support into these systems. Thus, the contracts do not mention anything about data security or PCI, and would not be compliant under PCI 1.1.

Now with PCI 1.2, the travel industry has a way to deal with these common use areas in a manner that does not affect their compliance. Security is still definitely an issue, but this is another one of those issues where you don't want to totally rely on PCI Compliance to keep you breach free.

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

Look out merchants, there is a sneaky omission to PCI v1.2 that does not seem to be making any headlines, and I'm wondering if this will just fly under the radar until someone like me stands up and points it out. All the discussion thus far has been around Anti-Virus, Network Segmentation (or lack of a requirement for), WEP, and firewall rules having a six month review (vs. quarterly). But, does anyone remember this little tidbit from the PCI v1.1 when trying to determine the scope of a PCI Assessment?

Any data repositories outside of the authorization and settlement environment where more than 500 thousand account numbers are stored [are in scope].

I've heard that this little loophole has saved many merchants from fines simply because they were able to take some non-compliant processes and get them under this threshold. Don't get me wrong, merchants would be liable for a breach if those non-compliant processes were linked to a breach, but anything below this threshold would technically not be material enough to show up in a Report on Compliance generated by a QSA.

Well, that whole provision is GONE from PCI v1.2. This means that merchants and service providers (small service providers could get hit hard with this) will have to do a better job of 1) defining where their data is, and 2) making those repositories compliant as they could be subject to the review of a QSA. Based on my interaction with customers, I think this is one of the more significant (if not the most significant) changes in the standard that people should worry about.

What do you think?

If you are worried about it, don't forget to ask a VeriSign consultant about our Data Discovery service that can help you map out all of this data (and other non-PCI data) across your enterprise.

Posted by Branden Williams at 4:27 AM | Permalink | Comments (0)

VeriSign's Managed Security Services group provides all kinds of services to assist organizations in the heavy lifting associated with some security tasks. Those tasks that are easy if you have one, but not easy if you have a thousand.

In a recent internal email string, one of our engineers told us they are seeing a dramatic increase in the amount of PDFs that have malicious JavaScript embedded in them. These exploits use the OpenAction function (like the HTML document.onload() function) as a vehicle to obtain full machine compromise with a root kit. I'm not sure why we feel the need to embed scripting into a PDF (isn't that what the web and offline browsing is for?), but it appears that once again functionality has usurped security.

I guess the next step is to make text files more functional so we can exploit those.

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

One of the topics that I often get into discussions with customers is pulling data out of volatile memory (RAM). The argument that is usually made related to insecure RAM storage is, "Well, someone would have to get on the machine and know exactly where to look in memory and it would just not be feasible for someone to do."

My response to this argument is typically something along the lines of "Obscurity is NOT Security." Obscurity is a poor defense against security problems.

It now appears there is evidence of malware that can grab data in memory to the hacker's delight. It's not really rocket science folks; it is actually pretty simple. This technique has legitimate uses in programming, and now that less and less data is being written to disk, the bad guys have modified their techniques to take advantage of volatile memory.

They are doing it by using common debugging software to pull and/or monitor the contents of the running volatile memory. For many merchants, this means that full magnetic stripe data is there for the taking.

Keep in mind, there is not a ton you can do about the majority of POS applications out there. Unless it is receiving the data encrypted, it will probably be in memory un-encrypted or could at least be pieced together while a crypto routine runs. This to me us much more serious than the issue of data sitting in a pagefile. It seems that if you have the ability to distribute the malware, you will get realtime data on a regular basis and won't be looking through snapshots of a pagefile.

Of course, I suppose you could just as easily hook into the routines that write things to disk and capture it there.

Regardless, it looks like the malware is out there. Be sure you are patching your machines and doing solid egress filtering as most of the malware compromises a machine first, then sends data offsite.

Posted by Branden Williams at 4:13 AM | Permalink | Comments (0)

Billy Rios, application security extraordinaire, posted commentary on Sandro Gauci's paper entitled "Surf Jacking - HTTPS will not save you." It's based on an attack called "Side Jacking" that was introduced during the 2007 BlackHat conference. Essentially, this type of attack allows someone to hijack a web session which would give them access to your account on a particular website.

Branden... In English please...

Ok, so let's say you make use of some stretch time that the office gives you (assuming they know about it), and head down to the coffee shop of your choice to get a nice fresh cuppa. You bring your laptop with built-in WiFi with the full intention of working on that presentation for Johnson. That guy can't seem to finish any of his work, and you get stuck cleaning up the mess. The only way you can deal with this kind of crap is to change your surroundings.

So you order that Triple Venti Carmel Macchiato with a dousing of cinnamon and two (not one, not three) mint leaves because it is your guilty pleasure and the guys from work are not within earshot to rip me endlessly for it until I curl up in the corner, sobbing quietly while looking for my blankey.

Anyway... so you pop open your laptop and there Johnson's presentation sits. Flipping through the cluttered and incomplete slides makes it hard to keep your drink down, so you decide to log into your bank account and see if you have enough reserves to take a sudden unpaid vacation. You hop onto the free WiFi that is so graciously offered by the coffee shop, and proceed to log in. Of course, your bank is smart and uses SSL to secure your connection, but someone was lazy when they coded the application and forgot to make the cookies secure.

No, not the biscotti that you have been gnawing on, a web cookie. Web applications often use cookies to identify different user sessions. That way, John Doe does not get John Q. Public's information (how embarrassing).

So now, we have unsecured cookies traveling back to the client! "But Branden," you protest, "all of the data is wrapped in SSL? What's the worry?"

According to Gauci, the cookie could be retrieved if you look at your bank account and open a new browser window to book travel to AnywhereButHereistan. Simply opening a new window to a non-secure site opens the possibility for an attacker nearby to inject an HTTP Redirect (302) message that will then transmit that session cookie in the clear!

Now the attacker copies the cookie, drops it into his browser, and takes over your session! YIPES!

Rios points out that this is a very simple fix (use the secure flag), but lazy development and poor security review in the SDLC promotes security vulnerabilities like this one. If this is not addressed early in the development process, Rios points out that you could get coded into a corner and have a major rewrite on your hands.

At any rate, those of you who have been solely relying on SSL (or EV-SSL) to ensure your web applications are secure, you should consider having someone like VeriSign's ESS do a security review of those applications to ensure flaws like this don't leave your customers screaming!

Posted by Branden Williams at 12:16 PM | Permalink | Comments (1)

I may not be the first to use the term, but this concept is killing security and compliance across the globe. What am I talking about? I'm talking about the lack of function in companies with silos.

We see silos rear their ugly heads in virtually every customer we deal with. Sometimes it is the disgruntled manager that was passed up for a promotion that is no longer being a team player. Other times it is a team in another region of the globe that wants to do things their own way. Or maybe it is just a jerk sitting next to you in Prairie Dog Land.

So what do we do when these turf wars break out in our companies and derail our security efforts? I'd tell you, but I just decided to make this the topic of the October version of my column, Herding Cats!

Regardless, the task of busting silos is not something that a security group can do on their own. We can help set the tone or goals, but it must be carried out and pushed by the CEO. Getting the big guy's (or gal's) attention is not going to be easy, but the efficiency that can be gained by killing cross-dysfunctional teams will make a huge difference.

Make sure your company is one of the few that uses this tactic to improve their bottom line, especially in our weakened global economy!

Posted by Branden Williams at 1:19 PM | Permalink | Comments (1)

Cyber-Ark has released a new study (article on ars technica) suggesting that 88% of IT workers would steal data if fired.

Every 88 in 100 IT employees would steal data if they were shown the door. That's more than the 4 out of 5 dentists that recommend chewing Trident after meals!

I'm not sure who they were polling, but it sure makes IT folks look like a bunch of criminals. At a minimum it does reinforce one point that often shows up in my presentations. At the end of the article, we learn that every third administrator would write down an administrative password. Administrators are often the worst offenders when it comes to breaking security policies and procedures.

This is why data security is so important. With proper security, you could easily remove the ability for 86 of those 88 folks to walk out the door with decrypted data. With good network controls, you could also prevent it from leaving the premises BEFORE a firing would occur. And as we know, once the data walks out the door, the lawsuits usually come directly following.

Posted by Branden Williams at 9:41 AM | Permalink | Comments (0)

Last month, we saw Kaminsky release details around a particularly nasty flaw in the DNS infrastructure. The tubes exploded with traffic on this flaw and security pundits beat their chests, telling the masses that they have been reporting this for years.

Well, it's a new month, and we have a new flaw.

Slashdot has posted a story about a BGP flaw that has been around for years that could easily bring down major portions of the internet. Wired has an article here, and the PDF of the presentation by Kapela and Pilosov is here.

I was a system and network administrator in a previous life (and to date have only had one system of mine EVER hacked... that pesky IMAP flaw in 1997 taught me a TON about security), and I always marveled at how easy it was to goof up parts of the Internet with bad BGP announcements. Thankfully, we were too small to ever be a victim of such an attack, but I do remember fat fingering IP space and seeing my goofed up announcements propagate quickly across the internets. I also got a kick out of a goofed up as-path prepend statement I did once (which is exactly how part of this attack works).

Ahh, those were the good old days.

But apparently, the good old days are still around! Imagine being able to target specific users to read all of their email before they can. Or maybe launch attacks on the inside of your own company (many companies use IBGP to route internally, some use straight BGP) to learn about an impending layoff. This is a classic Man in the Middle attack (MITM), and should reinforce our beliefs that the Internet (and maybe your internal network) IS NOT to be trusted.

Kapela and Pilosov state that the only way to fix this problem is with "perfect filtering." That will never happen. A better way is to start wrapping your traffic inside SSL or other types of encryption technologies that include assurance and integrity checks.

What will it be next month?

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

So you all know (well the three of you that read this... Hi Mom!) that I am headed to Australia this week. I was doing my traditional pre-flight checklists to make sure that I had everything I needed before I started packing. Power converter? Check. Power supplies for devices? Check. Remove things that just add weight that you won't need? Check. Log into my credit card account to make sure we're good? DOH!

My card has been compromised AGAIN! The DAY BEFORE I am headed to Oz.

The new one is on its way (overnight now) but good gracious, talk about skidding across the finish line. Upside down. On fire. In eighteenth place.

This is the only piece that annoys me is the inconvenience. Irrespective of their internal beliefs, companies that come into contact with consumer data should still do whatever they can to protect it, even if consumers are relatively insulated from its effects (such as with credit card theft).

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

When I was flipping through some RSS feeds and saw this fantastic post from Gizmodo, I HAD to bring it here for discussion. Now keep in mind, this is a photographer's artistic work, but it sure does open the door to other low tech ways to subvert security systems.

One of my personal favorites is the McGuyver style (sans chewing gum and dental floss) method of defeating magnetic lock doors with a balloon, tape, and a straw. Convenience says that we should not badge in AND out. Just on the way in is fine. On the way out, we'll put sensors there so that the door will magically unlock for you. It's the high tech version of the black treadmill mat looking thing at the grocery store that we kids always used to go jump on to make the door open.

And then came the footless shoe smacking me upside my head leaving me reeling, wondering how my mom can catch me getting in trouble when she is in the back of the store buying milk and beer.

After all, it is the breakfast of champions.

Anyway, with a little ingenuity (and some luck) we can get those heavy magnets to unlock from the outside of the door! No badge required!

What other kinds of hacks have you guys seen out there for defeating security systems?

Posted by Branden Williams at 10:14 AM | Permalink | Comments (1)

OK, yeah, that was a reach. As long as it makes me giggle, things will be just fine.

I assume most of you are away from your RSS readers this week because you are furiously patching your DNS servers. The attack is actually quite genius, and continues to demonstrate the inordinate amount of trust we place in servers and data that should not be trusted.

The details of how the attack works can be read in the above linked article if you are interested. You probably don't have the time right now because you are rushing to patch though.

Bruce Schneier takes this opportunity to lash out at the patching process. While some security pundits don't take Bruce seriously, he's got a point. The state he speaks about is a bit Utopian in nature, but the points are valid.

Can we get to a state where software is written with security baked in? Even if we can, would that prevent this or much more sophisticated attacks from occurring?

Electronic crime is a profitable business. As we cut off the money supply, they get more creative to recover their losses. My true fear is that they will get creative enough to create a vulnerability that goes undetected for some period of time, until a trigger point hits that causes mass chaos. If we're struggling to deal with relatively simple fixes today, what will we do when something like that hits?

Posted by Branden Williams at 12:04 PM | Permalink | Comments (0)

Well, it has happened again. I received a rather menacing looking note in the mail today. You know, one of those heavy stock sealed letters that has the perforated edges? Yeah. That kind.

Inside it looks like my information is on a lost tape from a bank. The funny thing is, I don't remember banking with this institution... ever. I have a feeling that one of the brokerage firms I use (or used) was backed by this institution, but nevertheless, I thought of an interesting type of phishing attack that I bet would work. When I looked through this notice, it did appear to have a corresponding breach on PrivacyRights.org. I have already placed my fraud alerts, so I should be good.

But what if it didn't? If I were to target specific individuals (i.e., spear phishing) and tell them that their information was compromised from a large bank and provided a number for them to call for more info, would they readily give me enough information to steal their identity? I think people have started to be wary about clicking on things or giving out information over email, but what about through the mail? Sure it won't have the same reach that electronic attacks will, but how much more lucrative could the loot get?

My thoughts are that it would work remarkably well against those individuals who don't have lawyers reading their mail, and especially some of the elderly population.

Posted by Branden Williams at 8:49 AM | Permalink | Comments (0)

Wired reports that a Citibank hack may be responsible for a recent ATM crime spree. Edit: Looks like some arrests have been made! I've discussed issues around hacking ATMs and challenges with skimming in the past, but this one appeared to be pretty lucrative. While bank networks are not impenetrable, attacking endpoints is becoming much easier and more lucrative.

Anyone remember the old days when you had to make sure the ATM you were going to use was real? Speaking of that... Ladies, you should beware of this.

Something of interest to me... As a consumer, do you check your bank statement with all of your receipts? Would you know if money started disappearing from your account in $10-$30 increments? Does the state of your personal financial situation dictate your attention to your bank account? I may be a dying breed, but I have been known to spend twenty minutes poring over a bank statement to figure out where I missed a dime.

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

The ISSA has posted the electronic version of the journal, so if you are itching to read what is coming to you via the post, go check it out! My column this month is titled "Don't Get Cyberjacked!"

It may be the first time that the phrase "This ain't your daddy's security incident" and the word "stripper" appear on the same page (or ever) in that fantastic publication. Go check it out!

Posted by Branden Williams at 8:03 AM | Permalink | Comments (0)

Monday was presentation day at CSI-SX. I had a decent crowd, for the breakout session! One day, I'll do a talk that is not the last session of the day :)

While I was in between sessions sitting in the speakers lounge, one of the other speakers (I did not catch his name) dropped his computer bag and jacket on the chair across from me. I looked up, nodded, and went back to my work. He proceeded to pull out one of those laptop locking devices that you see at public terminals. You know, the ones you can beat with a toilet paper tube. He then secured the whole apparatus (bag included) to the chair! A conference chair. The ones that weigh like ten pounds.

I was not watching him the whole time, but I did not see him ever leave the room. The room was maybe 100' x 40' and he sat down on the couch less than 10 feet away. What benefit would someone get by "securing" the laptop and back to the chair? Am I not paranoid enough?

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

If so, LOOK ME UP! I'm speaking on Monday afternoon at 4pm at the conference. Hope to see you there!

As always, I'll be sending tweets!

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

Just finished up with the last booth work at the show. Today was fairly slow (as to be expected), though there were still plenty of people coming through. I got to see the VeriSign VIP token work, and that was pretty cool! Hope you stopped by to get your free token!

As I was leaving, the last hunters of conference trinket treasure were hurriedly making the rounds before the expo closed. All in all, quite a show. If I missed you this time, I hope to see you somewhere else soon!

Posted by Branden Williams at 5:01 PM | Permalink | Comments (0)

Today has been filled with all kinds of activities, including meeting with some customers and vendors. I just finished the first meeting of the NSS Advisory Group and I am very pleased with the direction that it is heading. I think there is a lot of promise there for helping customers figure out which vendors DO solve PCI issues, and which ones don't.

I will be AT THE BOOTH at 10am tomorrow! Please stop by! I have a pretty "Blog This!" button on (Thanks K-Dog!).

Also you can follow me on Twitter at http://twitter.com/brandenwilliams.

See you there!

Posted by Branden Williams at 3:23 PM | Permalink | Comments (0)

(This post is brought to you today by the letter A).

This weekend, I took a hiatus from the computing world and headed down to the family lake house. Time to get ready for summer and clean out all the junk!

Well, not junk, but lots of ladybugs for some reason.

When we arrived home yesterday, I caught up on my personal email, and noticed that someone posted a comment to my personal blog. Like this blog, when someone comments, I get excited since I'm never sure if anyone is reading. (Please leave comments, it makes me feel useful. Just like all the characters in Sodor want to be.) The comment in particular was an attempt to run a SQL Injection attack against my blog software.

Thankfully, it appears that my blog software caught this intrusion, but it left a nice record in my email. Here's what it looks like when someone (or a bot) tries to attack a field.

Bill364367','396455billy@msn.com','','15.13.14.4','2008-03-08 11:08:05','2008-03-08 11:08:05','','0','lynx','comment','0','0'),('0', '','', '', '', '2008-03-09 11:08:05', '2008-03-09 11:08:05', '', 'spam', '','comment', '0','0' ) /* (IP: 46.232.63.181 , titania.nameremovedtoprotect.com)

Names & IPs changed to protect the silly.

So the question is, is YOUR code vulnerable to this type of attack? When is the last time you had an application penetration test or code review performed on your custom code? VeriSign has seen quite an up tick in interest around these services (which we happily provide), though it still seems that most companies really miss the importance of this type of security review. Either it is easily dismissed as too expensive, or companies want to review every piece of code they can get their hands on (vs. a methodical and targeted approach to key apps and an overhaul of the SDLC).

Posted by Branden Williams at 8:35 AM | Permalink | Comments (0)

Evan Schuman (Storefront Backtalk) wrote on Valentine's Day that PCI is not just for payments anymore. Hate it or love it, PCI is a great standard for a baseline of security. You can replace Cardholder Data with just about any type of data you want to protect, and you can establish a minimum baseline that will do a reasonable job of keeping that data protected. Security consultants have been pointing this out for a while.

I think the part of this that is the most telling is that the security and IT programs in some companies are so bad and so far gone, that PCI is what is standing it up. Again, I still believe that the PCI-DSS is a good baseline for companies to start with, but PCI is tailored to the protection of cardholder data (duh). Companies should be taking a broader look at their security and IT postures, extending beyond PCI.

PCI can also be an excellent poster child for building a security program. If you can get it right with PCI first, you can use your experience to extend that program into other areas of the company (take it up a level).

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

Yes, it's true that part of the reason I was not posting very frequently is because I was running out of ideas. It is also true that I've started following Schneier's blog again. Anyway...

He's got an excellent post with 2 examples of how Social Engineering was successful in the theft of significant sums of money. Security is made up of People, Process, and Technology, and people are almost always the weakest link.

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

This week, Bruce Schneier blogged about the CIA's disclosure of hacking incidents to public utilities. I've been wary of utilities ever since I learned about SCADA systems, and their implication on security. I've heard about consultants primed with a copy of NMap accidently shutting down large SCADA networks simply because of their age & lack of security.

The thing that is scary is that we have come across companies reliant on SCADA systems for their factories or assembly areas that are also subject to PCI.

Eek!

The good news is that with careful planning and a good network segmentation strategy much of the impact can be reduced.

Posted by Branden Williams at 9:57 AM | Permalink | Comments (0)

Todd Wilkens posted about his personal war against Blackberries this month. As a consultant, it is not only hard to conduct meetings (where we are getting paid by the hour) with customers when this happens, but I have been tempted to do the same thing as well! I think we all tune out at some point when it comes to meetings, especially those after lunch ones.

What I'm interested to know is if anyone has ever suffered a breach due to a lost blackberry. With the amount of scrutiny over email these days, I know that some caution is taken. That said, I also know that humans are lazy people and email is very pointy/clicky. I've seen executives forward extremely sensitive information via email to their Yahoo email accounts so they can work on it when they get home.

So as these computing devices get more ubiquitous, how much concern is there really out there related to a data breach, and what measures are you taking to mitigate that risk?

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

Security is not about compliance, it's about building a good program and governance to protect data. VeriSign announced today in conjunction with BSI Americas that VeriSign will be the exclusive firm to provide ISO 27002 readiness assessments that ultimately lead to certification.

The ISO 27002 standard covers Information technology, security techniques and a code of practice for information security management and allows companies that implement it to first focus on security, and then tweak it to deal with compliance. Enterprises faced with multiple compliance initiatives should first focus on good security practices before pushing compliance. This will set up a foundation to maintain compliance every day.

For more information, see the press release above!

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

With numerous retailers putting offers both online and in the store, how many of you are making the rush? Maybe because I can remember hitting the mall VERY EARLY in the morning on Black Friday as a kiddo I have never taken part in this. We also have family things going on that day, so it makes it a little bit harder.

My advice to retailers, watch out. As we saw back in July, cards stolen in the TJX breach this year could likely be used on the busiest day of the year. Many years ago, I worked retail and learned to dread the day after Thanksgiving. Even on our busiest times, you could at least walk through the store without having to physically move people out of the way.

With pressure mounting on retailers to deliver big numbers, will they not take a second look at a credit card to help push people through the line? One of the greatest times to use social engineering is when your mark is super busy, and overly distracted. I predict that retailers will see higher amounts of fraud this year for card-present transactions (noting of course that my 2.5 year old son is beating me in the NFL football pool this year, so take my prediction with a grain of salt or two).

And finally, I hope you all have an excellent holiday!

Posted by Branden Williams at 3:43 PM | Permalink | Comments (0)

This one still amazes me every time I see it happen. I would think that by now, people would try to understand what they don't know so they can deal with it.

I am dead wrong.

I'd like to reflect back to a conversation I had with an Information Security Director in a prominent company in the transportation industry. The reason why the industry is important here, is we met with this individual after the 9/11 attacks. Most people in the transportation industry were hyper-sensitive to security at the time.

We went in and were pitching enterprise security intelligence services--something that might be relevant to this individual. This individual welcomed us into an office, allowed us to talk about this service for 20 or so minutes, and then looked us in the eyes and said with a straight face...

"This service looks great, but I don't want to know about threats out there because if I know about it, I have to do something about it."

....

I could imagine some guy at a 5 man shop saying that, but this is a major company we are talking here. I don't know if I held it together in front of the individual, but I was shocked to say the least.

This incident relates to the current corporate mindset in many companies today. If I don't know about it, I don't have to do anything, therefore I have plausible deniability. The hard problems are there to be tackled, not ignored. So go get 'em fella!

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

I recently did some work for a customer that had an interesting perspective on the physical security of devices. We were talking about putting some specific controls in place to hold encryption keys, and when we mentioned that we could put them on little USB sticks (not an HSM, but think like that), they said "Oh, if we do that they will disappear from the stores."

Employee or customer theft of devices sure does not come up as something we deal with every day.

This particular company ran largely a cash-based business, and had a very small group of customers that paid by credit card. They were actually considering completely dropping all credit card acceptance because of the added risk they took on. The nature of this customer's business includes high turnover.

When asking more about the physical security component, they built in some component of "acceptable loss" into any purchase going into their stores. For example, RAM would regularly be stolen out of PCs placed in stores. Part of their decision making process to purchasing equipment was based on how easy it was to steal, and what the replacement costs were. Meaning, they had built in an acceptable loss component into certain purchases for IT.

That was a unique perspective. For them, it is cheaper long term to just buy equipment that is hard to steal than it is to build physical security into pieces of their infrastructure.

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

One of the big problems with building a business is ensuring that processes & procedures scale. Information Technology programs are no exception. We spend as much time as we can building in automation such that our precious resources are not consumed repeating a task over and over.

Security is no different.

In fact, there are several tactical security tasks that require strategic planning in order to scale them. For example, patch management tends to be a big issue for many companies, especially retailers. How do I create a system that allows me to do massive patching with limited (if any) downtime? How can I ensure a high rate of success? How do I keep exception management to a minimum?

We work with several large companies that deal with this on a daily basis. Ultimately, when faced with a deadline, companies are more likely to react with a tactical solution (let's hire 100 contractors and go run Windows Update) as opposed to investing the time & money to make a viable long term solution that scales. Cost is definitely an issue, but long term gains are to be had with strategic security and IT planning.

What are some other areas that have issues with scale?

1. Identity Management
2. User Provisioning
3. Hardware Provisioning
4. Software Deployment

Branden says: "Include the ability to scale and meet the needs of the organization's growth for current and upcoming projects!"

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

This month in Harvard Business Review, we finally get a case study that applies to Information Assurance! "Boss, I Think Someone Stole Our Customer Data" ($4 PDF) tells a story that many CEOs fear, and some can give you a first hand account about--a breach of customer data.

While the case study does speak in some general terms, it is an excellent table-top exercise to run through during your regularly scheduled incident response plan test. This exercise should include various functional groups such as Legal and Marketing in addition to the traditional security or information technology employees. The case study is written in general terms, and can be used multiple times as the law changes.

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

For our VERY FIRST installment of "What Do Other Companies Do" (WDOCD), Randy Smith has asked the following:

"What specifications do other companies require for Secure Tape Destruction (especially for older tapes that could have pre-encryption account number data). To my understanding PCI does not provide a specification.

Do you feel that standard is OK to relax when all the account number data is encrypted?"

Excellent question Randy! Virtually every company we work with has some sort of destruction policy for media, and it varies from using a bulk eraser, to pulling out the DeWalt and drilling a hole right through it (yes, one company we have done work for does exactly this after a bulk erase), to enlisting a third party media destruction firm, to transferring the media back to the manufacturer for analysis and destruction. A quick search on YouTube will show you many more creative methods to destroy these devices (though not recommended by this humble security consultant).

Specific to PCI, the only destruction standards mentioned are ISO standards that have nothing to do with destruction at all. Slight oversight that we hope will be corrected soon.

What is actually required is some method to destroy the data or media such that the data cannot be recovered. Small tape strips are minor risk, but incineration or shredding seems to be the best method to ensure the data is not recoverable.

For tapes where the account number is encrypted, I do believe a relaxed method would be appropriate. In fact, if you filled a FedEx truck with tapes of encrypted data, and then left it in the open for people to take those tapes, you would not be required under state laws (today) to notify the affected individuals! The card associations might take a different view of this of course.

The answer: For unencrypted tapes, be sure you do a very thorough degaussing before taking them to your vendor for physical destruction. This will ensure that any leftover fragments will not have any data on them to recover. For encrypted tapes, shredding with 3 to 6" tape strips left over should be acceptable.

Thanks for the question Randy! For your time, keep your eyes open for a little gift from us!

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

Well folks, it's time. Yes, I've been running this blog for a whopping month or so, and I just want to see if anyone is reading. So far, the only comments that have been submitted are those for "Biagra" and some "Hot New Penny Stock" that promises to make me rich beyond my wildest dreams. While those are certainly enticing links, I think we could make this much more productive.

What I'm looking for is to play a game called "What Do Other Companies Do" (similar to "Spin the Topic Wheel" for any P1s out there). Essentially, I'd like you to email questions to TheSecurityBlog@gmail.com asking how other companies address various security practices. For example, "What do other companies do related to code review of applications?" For those of you interested, the short answer is "not much."

There are a ton of good questions out there and we have a ton of inside knowledge we can share, so let's get to discussing!

Posted by Branden Williams at 8:00 AM | Permalink | Comments (0)

Going to privacyrights.org will clue you into a large cause of data breaches--the stolen laptop.

This type of incident is a repeated example of why knowing where data lives in your enterprise is so vital. When we are called into a customer for PCI consulting services, rarely do we see a holistic approach to understanding data flows. There are certainly experts who know their part, and 80% of the time they are right on. But they often lack an over-arching perspective of the data flows, and are unaware of data flows that lie outside of their bailiwick. The level of documentation required for overarching visibility is considerable, but it is also extremely valuable. Imagine being able to see the entire picture at once and instantly be able to identify risky areas or understand how a new service or acquisition could compromise security.

Of course, someone violating policy will not show up a formal diagram. How do you protect against the outliers?

Several companies including (but not limited to) Tablus, Vontu, and Verdasys have taken a focus on locating and tracking data from credit card numbers, to personally identifiable information, to intellectual property throughout a corporate network and it's workstations. Using this data in conjunction with that magical map can help point to high risk areas as well as policy violations. This are not the end all solution by any means, as education and awareness can be just as effective from the "honest mistake" type breach. It is a key piece to the Layered Security strategy your company takes.

Why are these tools not the end all solution? This will help prevent the accidental exposure, but will not prevent the sophisticated insider from siphoning this data off site. If data flows are encrypted for example (by say an SSL VPN), many of the data flow analysis tools fall down because they cannot see inside the stream. You can always block all encrypted traffic, but if you allow people to browse out to an SSL site, you may be allowing this data to leave without your knowledge. It also may not cover USB Drives, iPods, or other temporary storage if it it is not mounted at the time of the scans. USB Drives have long been a debated topic for good reasons.

The moral of this story is really beginning to think about the data.

Posted by Branden Williams at 12:11 PM | Permalink | Comments (0)