PCI problems

I was thinking about writing something about the problems on the PCI standard. I didn't find the time to do it, but Mark Curphey did it, and very well. I really agree with almost everything he pointed on his article.

I'm also seeing a huge distance between measured Risk and security controls when companies try to comply with PCI. Like the encryption requirements, most of the companies have worse vulnerabilities than lack of encryption, mostly when we are talking about information on databases.

The applications need to access the information, encrypted or not. So, all the necessary steps to allow the applications to access the information are there. And there are lots of things to deal with the applications, beginning with secure coding (that is covered, although not very well, by the standard) and passing through user profiles and policies to regulate their access privileges over time.

Besides that, there are many situations where exceptions from the rules are being conceded, most of them on the issuers side. There are lots of old mainframe bases systems being used, and these companies are being able to use compensatory controls over lots of requirements, as the mainframe environment is "secure". Hey, didn't these guys realize that mainframe security today is mostly being done through simple obscurity? PCI assessors are not properly verifying access privileges from people that support production environments. These guys can access lots of information. Now try to point some PCI auditors that know how to dig into details on mainframes to find about those privileges. It'll be very hard to find one.

And what about log management? Anything being done? Almost nothing.

Is the personal firewall necessary?

Again on Security Incite, Mike says that there is no need for personal firewalls anymore, as the one provided by the OS seems to be enough for most cases. I agree with him when he says that where it is not enough you'll need it from a bundle of other things, like AV and AntiSpyware. I believe we will start to see products like "endpoint security solution".

The AVs are already doing anti-spyware, the personal firewalls are doing some AV, and so on. In a near future every desktop protection product will do all this stuff, protect against "malware" and external attacks.

Corporate editions will also include NAC/NAP integration. There is no sense on installing dozens of agents to keep bad thing out, just choose a single good one to do all the job. It's also a good market trend for the companies looking for ways to survive, include all security features in a single agent and sell it as "endpoint security agent". Nice.

Path of least resistance

I was reading a comment from Mike Rothman about the need for SSL and then I found this expression, "path of least resistance". I really liked it on the context of security. There are lots of easy things to do to remove paths of least resistance. Depending on the level of exposure of your organization, this is all you may need to do to achieve a reasonable level of security. I remember several security measures that when are discussed by more technical guys seem to be not so relevant, but we can't ignore how many less savvy attackers are there trying to exploit our systems. A control that can stop 90% of them is better than nothing at all. I really prefer to deal with 10% of a threat than 100% of it. Just don't ignore that 10%. You can choose consciously to live with it, but don't ignore it.

The Kid is growing!

Four years ago I coined the term Honeytoken while discussing how honeypots could be used my companies with Lance Spitzner. Now they made their way into "professional" publications, like Network World. Good to see that the idea is growing. I believe that honeytokens can be a very good way to implement data monitoring for PCI compliance, for example.

Posts you hang on the wall

Sometimes I see on the discussion lists some posts that I think we should "hang on the wall". Today Marcus Ranum sent two paragraphs to the log-analysis list that were so great that I'm almost printing them to put on my office wall:

"All the current trend toward legislating compliance has
accomplished is setting the bar very low, and encouraging
companies to look only at meeting that standard. I've had
senior IT managers tell me "We are going to do the exact
minimum, wherever possible."

In log analysis terms, that means that the logs to to a big
bucket which is periodically dumped into the compost
heap. Nobody'll look in the bucket until someone passes
legislation requiring people to LOOK at it. And, of course,
when that happens, they'll do the exact minimum, &c..."

Congrats Marcus, always sharp!

Virtualization and Security

Mr. Antonopoulos has got a point on this article for Network World. I don't think security is aligned to the business drivers that are conducting the virtualization fever. He used good examples, as the security trend towards appliances. Is it aligned to the virtualization model being used today? I don't think so.

Cobit 4.0 and other standards

I've recently found some time to take a look at Cobit 4.0 version. I was glad to see that ISACA aligned Cobit to other documents, like ISO17799 and ITIL. It was a very important change, as the organizations will usually deploy their processes following best practices guides like ISO17799 and ITIL and will have their IT environment audited by someone using Cobit.

This will avoid that people try to use Cobit as an implementation guidance, what is definitely not the purpose of this standard. It will also force auditors to know more about the other standards as I've found in the past some auditors that suffered from "non-Cobit blindness".

Audit Quality and Freakonomics

I was recently reading the excellent documents from Ross Anderson on Information Security Economics. A good reading tip for those interested in the subject is the famous Freakonomics book.

After reading Anderson's texts I realized that the reason for the lower quality of the External Audit that I've been seeing is strictly economic. There are no incentives for an audit company to actually deliver good audits! For those who hire a big audit company the main reason is the final report, usually needed to comply with things like SOX. A "clear" report is the best thing that they can receive, as they will be compliant with regulations and won't have to spend money on solving audit issues. Naturally, audits that find less issues will be preferred by the market. Meanwhile, those companies that run more thorough audit processes will suffer the opposite effect. Is it possible to build into those regulations something to avoid it?

Those five mistakes over encryption

Anton Chuvakin liked that I called his article on encryption mistakes a "masterpiece". But it really is!

In fact, encryption mistakes are in focus now that PCI is getting stronger. Everybody is looking for ways to encrypt card data. And it's exactly at this time that they are more vulnerable to vendors pitches. I'm seeing some "PCI in a box" products being sold, and they are usually related to encryption.

Another problem with encryption is when you're talking with vendors of other IT products besides security. Try, for example, to ask a software salesman about how his software deals with user IDs and passwords. I'm almost certain that you'll hear "relax, they are encrypted". I know that salesman aren't the best people to answer those questions, but I feel a sadistic and hard to control desire to ask "How?" (in fact, I always do that). Their answers always contain one or more of those mistakes listed by Dr. Chuvakin. My favorite ones, until now, are:

"With a 256 BYTES key and 3DES" (even if it was bits... :-) )
"Using a known secure method called RSA" (are they really encrypting passwords with RSA???)
"I can't tell you, it's so secure it's secret" (men, it's so funny to hear that!)

Now, where are the security guys from these companies? Are they working only on their corporate policies? Even if some of these cases are just a salesman trying to lure you with a bad answer, there are some of those that are really bad encryption implementations. Some software houses still don't have nobody responsible for including security in their products and development processes. This makes the work of the security departments of companies that are buying their software much more harder, as sometimes they are struggling with business people to avoid that crappy software from entering into their business. And sometimes that crappy software is the best (or even the only) solution in terms of business functionality.

Another aspect that really annoys me when I hear those answers. If those guys are saying those things to me without thinking twice, it's because someone else asked that and BOUGHT that answer. How can a CSO or something similar be satisfied with an answer like that? Encryption tends to be seen as a too technical subject for CSOs to learn about. No, they (we) need to know at least the basics about it. It's not that hard to identify those five mistakes. If you believe that a vendor already throwed something like those answers into you and you bought it, go look for a basic encryption introduction. Even by reading some pages from wikipedia you'll be able to identify most of those cases.

The CISSP body of knowledge contains all the information needed by a CSO to know the encryption basics. If you already obtained your certification or are planning to get it, take your books and read that part again with a different look. Now you know when you'll need that information.

Encryption Mistakes, masterpiece by Chuvakin

Anton Chuvakin wrote a masterpiece about the most common mistakes regarding data encryption. They are:

- Not encrypting when it's easy and accepted
- Creating your own encryption
- "Hard-coding" secrets
- Storing keys with the encrypted data
- not handling data recovery (or "where are those f* keys????")

I think that every professional responsible for PCI compliance projects needs to read it. Encryption is not that silver bullet you're looking for (in fact, I hope you're not looking for one!)

Storm Worm and some old predictions

In 2005 I presented in CNASI conference a PoC trojan that uses the authentication from a valid web session from the user to inject it's own transactions. I showed that even some strong authentications systems could be fooled by that. I'll reproduce that code on our Black Hat presentation as part of the trends on botnets, this specific case on their "features" sets.

It was interesting to see that the Storm Worm is doing something very similar to what I showed before to inject it's content on webmail and blog systems, avoiding CAPTCHA tests. Together with content being presented by Jose Nazarion on BH DC, this is another of our predictions appearing on new malware.