Archive for November, 2011

Nov 29 2011

Network Security Podcast, Episode 260

Published by under Podcast

Believe it or not, all three of us managed to get together for a nice post-holiday show. After a brief discussion of pepper spray for holiday shopping, we jump into a nice menagerie of stories.

Network Security Podcast Episode 260
Time: 35:16

Show Notes:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 28 2011

Curing the Credit Card Cancer

Published by under PCI,Risk

Back when I was a Qualified Security Assessor (QSA), all of four months ago, I often explained credit card data as an infectious disease.  Whatever your credit card data touches is pulled into scope, requiring the full set of Payment Card Industry (PCI) Data Security Standards (DSS) to be applied to those systems to the same degree that the systems processing the transactions are.  That’s because the scope of PCI compliance is defined as “any system that stores, processes or transmits cardholder data and all systems connected to these systems“.  In other words, the switch that stands between your firewall and your processing server is in scope for PCI as are all the systems attached to that switch, unless you take specific steps to control the traffic between the two systems.  Thinking about the credit card data as an infectious agent makes sense, since the data infects everything it touches with the need for compliance and assessment, even though the system may have nothing at all to do with card processing and only made the error of being on the wrong network segment at the wrong time.

Lately though, I’ve begun thinking of credit card data as a cancer instead of simply a disease.  Consider the fact that many security departments spend hundreds of man hours each and every year trying to segment their cardholder data environment from the rest of the network to limit the impact of the annual assessment.  They modify firewall rules, implement VLAN’s, cut off access and chase down every data flow they can think of and find in order to find credit card data and prevent it from infecting systems and bringing them into scope.  Yet every year the QSA comes in and finds data where it shouldn’t be and people with access to the data who have no business reason to have it.  The credit card data continuously spreads and expands scope, and leaving even the littlest bit behind still offers the chance of the scope of the assessment and responsibility to the Data Security Standards.

Why does this continue to happen?  As security professionals, we try hard to find out where the credit card data is at, but the reality is that all too often we don’t understand the thought processes that went into the business processes that created the data flows, and neither do all to many of the people who created the business processes.  We might understand the process that takes a credit card from the customer’s browser to our web server and back to our database server, but the clearance and settlement processes are often an arcane process that we haven’t mastered and can’t figure out how to do securely with our acquiring banks.  I mean, why is it that some processors still mandate that the settlement files be sent clear text over a leased line or the Internet?  And getting them to change that can, very literally, take years to happen.  Another process that we often forget and creates no end of headaches is the fraud control portion of the business; I’ve seen more than a few businesses that had no idea that their fraud prevention team had either full access to the cardholder database or had a portion of the feed that included credit card numbers sent to them daily or weekly.  And since these teams weren’t considered during the original scoping, it often means a whole new section of the business that has to be considered and remediated, costing valuable time and money.

Another factor is how little it costs a department to ask for a stream from the database and how strongly they’ll defend it once they have the data.  I’ve run into many departments in the past that had little or no immediate need for accessing credit card data, but wanted every bit of the information from the web server and point of sales devices, simply because it might one day be valuable to them.  And even if the data is being used now, if there is some value for them to have it today, all to often that department isn’t the one that’s actually paying the cost of processing and storing the data; the IT or Security department received a mandate to make to make the data available and no additional funds were provided to secure the cardholder data in a manner compliant with the PCI DSS.  Good luck getting them to pay for something they’ve had access to for years or give up this access, despite the fact it might cost the company millions and have almost no real return on investment.

So how do we excise the cancer that is credit card information from our enterprises?  I know it’s a bit cliched to say it, but we still need to understand our businesses better.  Yes, our managers are getting better at talking to their managers, but the fact is, when you get down to the actual data flows, managers are simply a set of filters that help the people who’re doing the actual work misunderstand each other better.  It’s just as important to understand the overarching business flows as it is to understand the actual tables and fields that are being copied from one database to another.  Digging into the nitty gritty of each data transformation and export to another department’s database is hard work, made harder by the fact it’s changing all the time.  Managers need to set the policies and procedures that dictate who has access to data, including the where and why, but the line level security folks need to be able to track down the data flows and enforce the policies set up by the people higher in the chain of command. 

Departments also need to understand that there is a cost, associated with cardholder data and need to be made to bear that cost directly.  As long as they simply have to ask for the data and work the political process to get it without paying a fiscal cost, they well.  Policies and procedures are easy to circumvent if a someone in Marketing or Sales puts their mind to it, but when that same person is given a price tag for the data, the need often disappears or becomes something much more manageable and doesn’t include the cancerous data like credit card numbers and expiration dates.  This is a step that only management can take and in many organizations it’s incredibly difficult, since the concept of having to pay for data is foreign to most of the business.  But as long as someone else is paying for it or the cost of data is indirect, people will continue to ask for it.

The real, long term cure to the credit card cancer is to change the rules of the game so that businesses never have access to the credit card information to begin with.  Face it, as long as a single record remains on your enterprise, someone will find a way to get access to it and spread the contagion from system to system.  The solution that’s available to businesses today are various forms of tokenization.  First, on-site tokenization allows businesses to create a ‘toxic waste dump’ in their environment with strong controls around it and only people who have demonstrable business reason are allowed to detokenize the data.  Since there is a more limited number of people who have access in this environment, training on how to treat the data with the caution and respect it deserves is much easier to deliver and enforce.  Plus definitive consequences for treating the cancer causing data unsafely can be enforced when only a limited, educated group of people are allowed to have it.

Even better is to have the data tokenization is having someone else handle credit card authorization and settlement and never let credit card data touch your network in the first place.  Most of the acquiring banks now have partnership with PIN pad manufacturers now with end-to-end encryption built in.  The stores are encrypting the cardholder data as it’s swiped and the register and they either have no access to the credit card information or only have access through a separate backend system.  Online merchants are making more and more use of outsourced payment systems, which also prevent cardholder data from entering enterprises and small businesses alike.  Several of these solutions offer ways to tokenize cardholder data as well.

When it’s all said and done though, it’s the credit card processing system that has to change, not just how businesses treat credit card information.  We need to modify and re-engineer how we take credit cards and remove the monetary motivation for the attack (and defense) on credit card data.  If credit card information has no value for an attacker then attention will shift elsewhere and the security department will once again be able to concentrate on securing the entire enterprise rather than just a small portion that has a compliance measure behind it mandating minimum security standards.  Of course, then we’ll have to worry about what we can use to get funding from management to secure the rest of the business.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

6 responses so far

Nov 22 2011

Open tabs 11/22/11

Published by under Family,Hacking,PCI,Risk

I got home Sunday from 3 days in Las Vegas, two of which were spent at the first ever Minecon.  For those of you who aren’t the parents of Minecraft addicts or addicts yourselves, it’s a game where you create a whole world then mine it for resources and build just about anything you can imagine.  It’s multiplayer, sometimes massively so, and it’s very easy to set up your own server and be hosting it for the world in a matter of hours.  Unluckily, it may be too easy; people who can barely figure out what their IP address is are setting up servers on their desktops then sharing their systems with friends via Hamachi or simply opening their home network to the world. It’s enough to give a security professional an aneurism!  I wrote up my own experience in creating a cloud server for Minecraft in April, but that server never caught on with the kids.  So now I’m trying a different solution, MineOS Crux, a custom build distribution of Ubuntu specifically created for people who want a secure, lightweight Minecraft installation.  I’m running it as a VM on my Mac Mini server and exposing it to the world on a non-standard port, plus I locked down the distro a little more than the standard build.  I’m still more than a little paranoid about it, so if the kids aren’t using it, it’ll go away.

Oh, and the kids got me to start playing Minecraft as well.  Good thing there are a lot of long holiday weekends coming up.

Open Tabs 11/22/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 16 2011

Google’s wifi mapping non-solution

Published by under Privacy,Risk,Security Advisories

Google got in a lot of trouble last year for capturing private data from wireless networks when they were driving the googlemobiles around to get video shots for StreetView.  Basically, rather than just capturing the SSID for the access points, in a lot of cases they captured data streams from the AP’s, which violated all sorts of European privacy laws.  And in reply to this, Google came up with a solution:  users can opt-out of Google’s wireless access point mapping solution by simply adding “_nomap” to the end of their SSID!  So simple it’s stupid.  No, I mean it’s so simple it’s absolutely idiotic and a waste of the digital ink that was used to express the idea!

I think MG Siegler expresses it best when he said, “The solution is a joke.”  Siegler thought of the same things I did when he saw this so-called solution.  First, only a fraction of a percent of people are even going to understand that Google is mapping their access points and even a smaller segment of the population is going to understand what that means.  And of that small group, only a much smaller percentage are going to make the changes to SSID names necessary to opt-out of the Google mapping.  I thnk that his .01% of the 10% of the people who actually read the article is a bit generous; only the truly paranoid will opt out using this method, and they probably weren’t advertising their SSID to begin with.

Let’s think about the pain in the arse it is to change a SSID to include ‘_nomap’.  My house is probably not normal, but it’s what I have to use as an example.  I have two wireless networks, two access points, three desktops, half a dozen laptops and a server that all would have to be changed to include the ‘_nomap’ SSID.  Plus there are a few more systems to worry about when you include the gaming systems the kids use.  The average household probably doesn’t have nearly that much equipment, but they also don’t know enough about wifi to set it up with proper encryption in the first place, so why would Google assume the average home user would know enough to change the SSID on all these systems once they finally got them running on their home network?

Let’s be honest; all Google is doing is waving their hands over StreetView in an effort to claim they’re doing something in front of governmental bodies who wouldn’t know the difference between an SSID and Sid Vicious.  In most cases, they’d probably recognize Sid Vicious before they’d have a clue what an SSID was or what it’s used for!  Siegler nails it when he states that Google might as well ask for people to solve calculus problems.  And I’d be willing to guess there are a number of people would have an easier time solving advance mathmatical equations than they would changing their SSID.

I want a solution that doesn’t require me to change my SSID to opt-out of Google’s mapping.  It’s a stupid solution and I’m not changing my SSID to include the ‘_nomap’ modifier.  My last thoguht is two-fold:  What effect will this have on the all the data that Google has already collected (Answer: none) and will Google actually honor their own ‘_nomap’ identifier and drop the data at collection or will they simply not display the access points using ‘_nomap’ but keep the data in their database?  I think you and I both know the answer to the second one as well.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Nov 15 2011

Network Security Podcast, Episode 259

Published by under Podcast

Rich and Martin are together for the first time in about 6 weeks thanks to all our overlapping travel. We are joined by Marisa Fagan who tells us about BayThreat- one of the only actual security conferences in the Bay Area (and a really good one). Then Marisa leaves and Rich and Martin jump into the security news.

Network Security Podcast Episode 259
Time: 39:43

Show Notes:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

2 responses so far

Nov 11 2011

Open Tabs 11/11/11

Whether you call it Veteran’s Day, Pocky Day,Binary Day or something else, it’s Friday, I don’t know about you, but I’m looking forward to this weekend and spending some time with friends.  Being a parent, I don’t get out for adult time as much as I once did, which makes the rare occassions all that much more special.

If you know a veteran, today would be a good day to tell them thanks.  I ‘repaired’ radios long ago and far away on a little artillery base in Germany.  I put repair in quotes because our job was to say “Yep, it’s broken”, replace the radio and send the broken one off for repair by someone who actually did electronics troubleshooting.  I was lucky and my enlistment was during a relatively peaceful time, but we have hundreds of thousands vets out there who saw events and actions most of us can’t even imagine.  Please respect them for their sacrifices.

I haven’t done this in a few days, so there’s a lot of built up articles.

Open Tabs 11/11/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 08 2011

Network Security Podcast, Episode 258

Published by under Podcast

We’re still scattered to the wind and getting together for a podcast is proving to be nearly impossible.  Luckily Martin was able to get a couple of podcasts from BSides DFW this weekend, so there’s a podcast, short as it is.  It’s almost enough to make you wonder if having a successful helps make you so successful you can’t have a podcast.

Michelle Klinger and Joseph Sokoly were the motivating forces behind making BSidesDFW happen again this year.  Thanks to their efforts a over 180 people were able to get together to see and here some great speakers.  Jayson Street was one of them, though he got the short straw and had one of the first slots of the day.  Pepsi Zero helped him through it however.

Network Security Podcast, Episode 258

Time: 16:28

Tonight’s music:  Five Feet from Paradise by Eleanor Fye

 

 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 08 2011

Open Tabs 11/08/11

I had a great time at BSides DFW this weekend!  Michelle Klinger, Joseph Sokoly and the whole crew of volunteers who made the event happen did such an awesome job of putting it together and the Microsoft tech center was the perfect place to have it.  Not that Jayson Street didn’t make a few of the security guards nervous from time to time.  And the rest of us nervous when he thought no one was watching where he was thinking of getting into.  I gave the closing key note speech, which went well despite the fact I was as nervous as I think it’s possible for me to be.  It’s worth giving the talk again some time, after I’ve tightened it up and loosened up a bit myself.  Just remember to challenge all our current security wisdom.

Saturday was November 5th, Guy Faulkes day, and despite it being a high holiday for Anonymous, nothing much seems to have happened.  They did pop Adidas last week, but that was supposedly a prequel to their main event this weekend.  On a more positive note, Brad Smith is doing slightly better, though he is still comatose and has pnemonia.  If you can, spare a few dollars to help Brad and his wife pay for medical bills; if you can’t, keep him in your prayers.  Brad has helped a lot of people in the security community and it’s time to help him in return.

Open Tabs 11/08/11

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 04 2011

Open Tabs 11/04/11

It’s almost time to hop in the car and head for #BSidesDFW (I even think in hashtags some days) in about an hour.  I find it annoying that I have to leave the house about 3 hours before my flight to have any chance of making it, since it takes 90 minutes to get to the airport and about 45 minutes to get through the TSA checkpoint most of the time.  I was joking around on Twitter earlier this week and said I’d vote for the first Presidential candidate, Republican or Democrat, who promised to abolish the TSA; it turned out that Ron Paul had already made that promise, but we’ll see if he’s still slugging it out by the time the primaries roll around.  In any case, I need to get packed up and head out.  I’m going to try to get a few interviews at BSidesDFW for the podcast, since there are so many interesting people speaking tomorrow. 

Open Tabs 11/04/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 03 2011

Open Tabs 11/03/11

This week’s podcast conversation with HD Moore and Josh Corman was a good thing.  Getting the ideas of “HD Moore’s Law“, the security poverty line and security debt out there so other people can beat on the ideas, examine them for flaws and hopefully incorporate portions of the concepts into their own thinking.  This is, after all, the whole reason I started blogging and podcasting in the first place.

Open Tabs 11/03/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Next »

7ads6x98y