Jeff Pettorino's Security Convergence Blog

I wandered over to the PCI-SSC site today and noticed that they have reposted the press release from August 18 reminding everyone that the new version of the standard will be announced TOMORROW.

Thanks for the reminder; I'm pretty sure we all have that date etched into our brains via green laser.

Tease....

The US PCI Conference is now over, and what a quick two days. There are many changes coming for the new standard, and I'm very excited about talking to you all. We are putting together a webinar to discuss, in detail, the changes that you will be facing. Look for an announcement on that soon.

It was great talking with many of you about the issues that we all face every day. I look forward to talking again soon and helping you build creative solutions to these challenges.

Oh, and a quick tidbit for you all. If you get a business card from a processor, sometimes even when you put it in a blazing fire pit, it will not burn!

OK, the questions have not been really earth shattering. I'm heading to a customer call in a few, so will not be live blogging the latter half. We do have coverage and I will post anything crazy here shortly.

We're just reviewing these changes and before hundreds of people queued up at the microphone, the intent of the change is to prevent an "automatic exclusion" of Unix or Mainframe technologies. Looks like Anti-Virus is now a case-by-case basis for review.

My opinion is that ANY desktop computer with access to the internet should have A/V on it as it is at a higher risk for compromise. In some cases there can be exceptions, and technologies like Solidcore and/or Bit9 can be excellent compensating controls.

Clarification that wireless technologies are defined as any point where you make a jump over air. That could include things like Satellite, Microwave, RFID, WiFi, GSM/GPRS, etc.

This may become problematic for some users as I believe some QSAs have only been focusing on WiFi and Cellular technologies. The only piece that is somewhat left open here is "carrier-based" technologies. Some network links provided by the Telco include jumps across microwave.

I'm sitting here in the back of the session where the 1.2 version of the standard is reviewed, and it looks like Network Segmentation is the stop down. After hearing many people state their case on segmentation, I really have to stand behind the Technical Working Group here. I'm not sure how much clearer it could be made. The standard states that:

Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through internal network firewalls, routers with strong access control lists or other technology that restricts access to a particular segment of a network.

The TWG was asked to clarify further and the only comment that was made was "I guess we could tweak it a little."

Be strong TWG. Don't give into peer pressure. The definition is perfectly fine.

Are you here? If so, drop me a line! I am here with our PCI Assessment & Remediation Practice Lead, Steve Levinson, and one of our PCI Consulting Managers, Rob Harvey. We'll be manning the VeriSign booth during the networking hours, so please stop by!

According to this article from Information Week, "only 35% of Oracle users continuously monitor for suspicious activity."

Ouchtown, population YOU, bro. Well 65% of you.

Let's assume that this study is accurate (based on the installations of Oracle that I have seen, I would guess it is pretty close if not optimistic). This means that there are databases out there, probably with sensitive data in them, that are compromised and the DBAs or security teams don't even know it. Many DBAs simply give up on patching these installations thanks to a rather messy process, so the problem could even be worse.

The study specifically states that continuous monitoring (minus a definition on what that means) is performed by 35% of the respondents. Another 32% monitor once per day, 23% once per week, and 9% once per month. Apparently, a couple of respondents also chose to say they monitor once per YEAR (1%).

Daily monitoring COULD be useful, but it is not nearly as useful as real-time monitoring. It really depends on what the respondents are doing. If continuous monitoring means that they are pinging the database every few seconds to make sure it responds, that's not the kind of monitoring that I'm talking about here. I'm talking about real-time monitoring that could help a DBA or security analyst determine if a breach has occurred, or is occurring. Ideally, seeing the attack in progress would help stem the amount of data lost.

Most Oracle installations after version 10 can support some kind of minimal audit logging without a major performance hit. I don't know of any Oracle DBA that would turn on audit logging for every table in their database, but there are key schemas that should be monitored. This will require someone do some analysis though, and with most of us continually being asked to do more with less, I bet this task quickly is tossed by the wayside.

Application vulnerabilities make matters worse by exposing these databases to compromise more and more every day. Companies driving major e-Commerce installations from databases are an obvious first target, but don't forget Extranet sites for vendors, or poor network segmentation that exposes databases to a relatively large population of employees (that we all hope are on the straight and narrow).

I would be interested to see this survey expanded beyond the scope of Oracle. I bet that the numbers are pretty similar in the Microsoft SQL world as well as in any of the Open Source databases (PostgreSQL, MySQL). My guess is that two databases that would buck this trend would be DB2 and Informix, but that's just a crazy guess by a crazy blogger.

While the official release does not happen until two weeks from today, many key stakeholders now have a copy of the pre-release version. What can you expect?

You can expect THIS blogger to honor his NDA!

Seriously though, are you ready? Version 1.1 has been around for over two years now (birthday was September 7, 2006), and by now you should have been able to validate as compliant to that version of the standard. If you are still struggling with 1.1, there is good news along with the bad.

The bad news is that in some cases your remediation targets may have shifted slightly in one direction. This will apply to you if you have been doing the absolute bare minimum to comply. VeriSign advises our customers to use PCI as a baseline, and pick certain areas to exceed in so that minor adjustments to the standard will not affect you. I'm pleased to say that our recommendations have been on track.

The good news is that some requirements have been altered to more closely match existing risk management procedures. The bad news here is there is some room for interpretation (as always), that may once again cause some QSAs consternation.

Sorry, I meant to say, cause some QSA's customers consternation.

For those of you heading to the PCI Community Meeting in Orlando next week, please stop by our booth! We'll have a few leaders in our PCI consulting practice available to chat with you!

Another month, and another dose of brain vomit by me! September's edition of Herding Cats is entitled, The Softer Side of Security. In here I give you four tips on how to be more effective as a security professional. Yes, the touchy-feely crap has entered our model for success.

As a side note, I'll be writing closer to 750 words of content excluding the bio now. Hopefully that will let me fill all three columns.

While you are looking at this month's ISSA Journal, please also take a look at Bindu Sundaresan & Jennia Hizver's (two brilliant consultants in our Global Security Consulting practice) new article entitled, 10 Tips on How to HACK the PA-DSS!

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!

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!

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.

Is anyone else still just wondering what exactly this means for your business? The summary does definitely answer a few questions, but I am wondering if someone was pressuring the council to release something, ANYTHING, about the new revision.

One thing that concerns me as a QSA is the amount of variance that will be introduced in the interpretation of some of the clarifications. For example, right off the bat we see the opportunity for interpretation in the clarification under Requirement 1:

Added flexibility in the time frame for review of firewall rules, from quarterly to every 6 months, based on Participating Organization feedback. Now the control can be better customized to the organization's risk management policies.

I hear the caliber of those breach bullets is pretty high.

One of the bigger changes ones that is perfectly laid out is the sunset date for WEP. THANK GOODNESS! Yes, I realize that companies are STILL deploying new WEP installations, but they have no business in any environment where sensitive data exists—meaning storage and transmission of networks missing segmentation. There will now be a requirement to replace all of those devices by June 30, 2010.

Requirement 5 now seems to have more strength in it, but I'll wait to see the testing procedures. I don't believe the council will be requiring A/V on mainframes, but I do believe that other operating systems like Linux and Mac OS X could now come into scope. VeriSign's belief is if it is a desktop operating system with access to the internet (including indirectly through email), it should have some kind of A/V on it.

In Requirement 11, there are so many goodies there that we will just have to wait for the SAP. Internal Penetration Testing is a really fun one that I fear will cause many merchants to have a slight case of freakout (or death-panic as I like to call it). Also, are we getting closer to Wireless IPS in environments where cardholder data exists? I'm getting so excited! It feels like Christmas morning over here.

My favorite change is the one listed under Requirement 7: Clarified language around testing procedures. We'll just have to wait for the new SAP to be released before we can let out that deep breath we're all holding!

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?