Between figuring out next year’s budget and comparing YTD expenditures with this year’s budget, Q4 is always an interesting time for security and IT managers. For the lucky ones who have found themselves with extra money that needs spending before the end of the year (sandbaggers!), it can be surprisingly difficult to find something worthwhile to spend it on. I know, I know. I can’t imagine how anyone would deal with such misfortune. But seriously, some managers do have problems choosing end-of-year purchases and wind up either spending their extra budget on shelfware or not spending it at all – only to end up with a leaner budget for next year.

Spending excess budget is not as easy as it sounds. Most security managers have learned the hard way to cherry-pick purchases that they can roll out quickly without taking on a lot of new overhead. If the budget is already planned for next year, they are also wary of making purchases that will need ongoing support or those that would “marry” them to projects that aren’t in next year’s budget.

Lately, we’ve been seeing more companies use their extra budget for professional services, such as assessment and audit preparation services to get a jump on next year. Companies are also using professional services to offload some tasks they may do internally, like auditing webapps for vulnerabilities, to give their staff a little more breathing room during the holidays or to make up for unplanned absences. If well-scoped, professional services can provide great bang for your buck in a short amount of time without much overhead.

Having said all that, here is a bit of advice that goes without saying (but I’m going to say it anyway): If spending your leftover budget is the strongest reason you can think of for buying something, find something else to spend the money on.

There is a lot of information on PCI being published right now with the September 30 deadline for Level 1 merchant compliance looming. Yesterday, DarkReading posted a report with some information that definitely warrants attention. According to the article, many companies falling into the Level 1 merchant category (mostly large retailers) are not going to be compliant in time for the September 30 deadline. I can’t say this was unexpected though. Granted, PCI DSS is more straightforward than other regulations. But by no means are the requirements easy to comply with, especially if information security wasn’t a high priority for you in the past. From the article:

Despite the threats of fines and penalties, however, it looks as though many retailers are about to miss yet another PCI compliance deadline. Experts estimate that more than a third of Level 1 merchants — the largest retailers — will fall short. Smaller retailers generally are even further away.

The article also reports some interesting information from the PCI DSS Council’s first community meeting, which was held in Toronto last week:

Computer forensics experts at the Council meeting testified that as many as 60 percent of the breaches they have investigated in PCI environments can be traced to flaws in five or six retail applications, Lindstrom reported. “They didn’t want to give out the names of those apps, but they are mostly payment processing applications that are specific to the retail environment.”

With PCI making security a more “top of mind” issue for retailers, I wonder if we’ll be seeing those applications become more secure. Will there be enough market pressure on the application vendors for them to make security a priority in their SDLC (Software Development Life Cycle)? How much pain does PCI have to inflict before a retailer says to their vendor “your application is great, but we’re going with the other guy’s because it has fewer security flaws”?

There is also some concern among credit card companies about smaller merchants who are far behind Level 1 merchants when it comes to security:

But while many large U.S. merchants and payment processors struggle with these technical issues, credit card companies are likely more worried about smaller retailers and non-U.S. regions that are not nearly as far along as their Level 1 counterparts. For many of these companies, the problem is not technology, but resources.

“The forensics people we heard from said that more than 80 percent of the [credit card] compromises they see are coming from merchants who are at Level 4 — the smallest retailers,” said Lindstrom. “This is where the least [PCI compliance] work has been done.”

Will there be changes to the PCI validation requirements to prod Level 2-4 vendors into being more secure (and hopefully having fewer breaches)? It’s always been assumed that one of the reasons for multiple merchant levels is so that validation requirements can be increased gradually from the top down. Right now, the validation requirements for Levels 2-4 are almost identical (the only difference being that Level 4 merchants depend on their acquirers to determine whether they need to do a quarterly PCI scan, the annual self-assessment or both). Don’t be surprised if some of the changes to PCI in 2008 involve increasing validation requirements outside of the Level 1 merchants.

InformationWeek is reporting yet another network breach, this time involving internet retailer Vertical Web Media. According to the retailer’s president Jack Love, they weren’t hit by “ordinary” hackers:

“This troubles us deeply… We thought our site was extremely well protected,” Love told InformationWeek. “We were up-to-date on all our patches. We get a quarter of a million visits a month to our site. We’ve seen hacking attempts before. Anyone with a site that highly trafficked is going to see that, but we hadn’t had a problem. We had a sense of security. But the message here is you can never feel content with security. You have to be ever vigilant.” (emphasis added)

Kudos to Mr. Love for hitting the nail right on the head. Security is a never-ending process where you have to be constantly improving and on your guard 24×7. You can be up-to-date on all your patches, you can be using the latest and greatest security tools and you can be compliant with every single standard and regulation in the books. But you still need to be ready to detect and respond to a successful attack. Can you detect it as soon as it happens? Can you contain it and minimize the damage? What are your top priorities during an attack? Prevention, detection and response – all 3 are necessary.

Over at the PCI DSS Compliance Demystified blog, Michael Dahn has a post that should be interesting to anyone subject to compliance audits (which is just about everyone). Titled “How deep do your PCI auditors need to go?,” the post lays out some of the factors that auditors use to determine, as the title suggests, how deep into your security program they need to go in order to reasonably prove or disprove compliance.

From the blog:

Here are some factors they may examine:

• Can they sample similar systems?
• Will they rely on third-party reports?
• Do they need to inspect the security of every application?
• Will you need to give them copies of sensitive data for their work papers?
• Who will send the final report to the acquirer or card brand?

As you would expect from a blog dedicated to PCI DSS, the information Michael discusses is in the context of a PCI compliance audit. But many of the factors and considerations are used by information security auditors across the board regardless of their “faith”. If you’re expecting an audit soon, it’s a great quick read that provides some insight into the process.

Disclaimer: People use the word hacker in different ways. For some, it is a general term indicating that someone has skills when it comes to coding and security systems. For others, it more specifically means you have broken the law, or at least displayed questionable ethics, in applying those skills. For the purposes of this article, we are only using the term hackers to describe those who have knowingly broken the law using their computer skills.

You may want to read this article and think twice. In classic “I-told-you-so” fashion, convicted hacker-turned-security-expert Max Ray Butler, a.k.a. Max Vision, is being prosecuted for hacking again. He was indicted on three counts of wire fraud and two counts of transferring stolen identity information. According to the indictment, he helped to operate a website dedicated to buying and selling stolen credit card and other personal identity information. Reports indicate he sold tens of thousands of stolen credit card accounts gained by using “war-driving” attacks to exploit wireless networks and gain access to computer networks at several organizations, including the Pentagon Federal Credit Union and Citibank. He hasn’t been convicted of anything yet, but there seems to be a strong case against him supported by solid evidence gathered by the U.S. Secret Service.

There’s always been some debate on whether hiring former hackers to perform security duties is an acceptable practice. In my opinion, it is very hard to justify hiring a former hacker, particularly one with a criminal record. In Butler’s case, he was a former FBI informant and a somewhat well-known security researcher. But apparently, he still couldn’t overcome the lure of using his talents for illegal activities. I’m all for second chances, but you have to take your business’s best interests into account when it comes down to hiring someone who is going to be responsible for an aspect of your security. This applies to hiring consultants as well.

And in case you’re wondering: No, we do not hire former hackers at SecureWorks.

So says a software developer producing hacking tools.

If you still have any doubts regarding the underground “business” of hacking, check out this interview by Robert Lemos over at SecurityFocus. In it, one of the developers responsible for MPack (an increasingly prevalent hacking tool) talks about his cohorts, their “project’s” profitability and their goals.Some other quotes from the interview:

“The project is not so profitable compared to other activities on the Internet. It’s just a business. While it makes income, we will work on it, and while we are interested in it, it will live. …Of course, some of our customers make huge profits. So in some ways, MPack could be looked at as a brand-name establishment project”

“Our main aim is to make the pack work better – boost the number of infections, in other words. Everything else is not so important. …We have got some other projects running and more to be realized.”

“We are just a group of people working together, but doing some illegal business”

Granted, it may not be the same language you would expect to hear from someone on a board of directors. But if that doesn’t sound like they are running a business, I’m not sure what does…

A recent federal court ruling in Pennsylvania has brought this question back into discussion amongst many security, technology and legal professionals. In Healthcare Advocates Inc. v. Harding Earley Follmer & Frailey, the court ruled that it is not considered unauthorized (and therefore illegal) access if the information in question was gathered from publicly archived or cached data. This means if your company’s data has been cached by search engines such as Google or Internet Archive that data – whether sensitive or not – can be legally accessed by anyone.

From the article posted by Law.com:

“A law firm did not violate copyright and computer anti-hacking laws when it used a Web archive search tool to recover old Web pages of its client’s adversary, says a federal judge.”

“They did not ‘pick the lock’ and avoid or bypass the protective measure, because there was no lock to pick,” Kelly wrote in Healthcare Advocates Inc. v. Harding Earley Follmer & Frailey, No. 05-3524. “Nor did the Harding firm steal passwords to get around a protective barrier. … The Harding firm could not ‘avoid’ or ‘bypass’ a digital wall that was not there.”

Several other blogs have also weighed in on the court’s decision in the context of the larger “what is considered unauthorized access?” question:

If you don’t secure your data, it’s not unauthorized access
Obligation to Secure
Robots.txt and the DMCA
Thanks for letting me circumvent