Data Breaches, Lawsuits, and Auditors - Oh My!

Wired's Threat Level writer Kim Zetter reports that Savvis is being sued as part of the 2005 CardSystems breach. Zetter notes that this is a legal first, making this an intriguing case to follow. Savvis' role as a Cardholder Information Security Program (CISP) auditor. This predecessor to our broadly adopted and audited PCI-DSS standards was expected to help ensure that a compliant entity was secure.

Additional coverage can be found on various security sites around the net, such as SC Magazine, which observes that the breach occurred almost a full year after the certification - enough time for a multitude of compliance issues to creep into any environment if not carefully maintained and re-assessed.

Zetter also notes that credit card companies are aware that even those companies that have clean audit results are often vulnerable. This creates an interesting scenario - companies are required to meet PCI standards, and pay for certified auditors to assess their systems. Should they then be indemnified against compromises? Where does responsibility for incorrect audits and assessments lie?

Unfortunately, it is rare for organizations to completely meet all of the standard, and exceptions and local accomodations are common - and even when an organization meets all of the standards, they do they can be vulnerable. The PCI-DSS standards are a step forward for credit card processor security, but this lawsuit is likely only the first in a series of lessons the entire industry will learn about auditing and standards compliance.

(ISC)² Security Professional Security Hiring and Employment Outlook Survey

The (ISC)² hiring and employment outlook survey results recently announced on the (ISC)² website point to security as a continued area of growth, despite the economic downturn. Their survey was answered by over 2800 respondents, with 775 with hiring responsibilities. Interestingly, almost half of those were hiring at least one staffer. The survey also notes that many organizations had experienced lay-offs and/or budget decreases.

The responses regarding hiring also met my own recent experiences - finding qualified candidates with strong technical and interpersonal skills is difficult. The skillset required to be an analyst in a large organization with a diverse IT environment can be difficult to find, and competition for those highly qualified candidates remains stiff. Many candidates have specialized knowledge in a single area, but have little qualification across other crucial fields. Others have many paper certifications, but don't handle practical questions well. In short, the downturn seems to be shaking those with lower qualifications loose, and those with stronger backgrounds are still able to pick and choose their jobs.

The good news is that if you are a highly qualified security professional, you remain a valuable asset, and may have more opportunities then in other fields. The bad news is that the weak employment market may not greatly help you if you are a hiring manager - or you your resources may be so constrained that hiring a top flight candidate is impossible.

Ephemeral Ports and Badly Behaved Software

A recent application issue pointed out what happens when a developer doesn't implement a normal TCP/IP port usage model.

In this case, the application doesn't appear to do what a normal application should: pick an ephemeral TCP port over 1024, then use that as the source port. Instead, the application binds to a specific source and destination port.

This might not be as much of an issue if the application didn't also suffer from a bad habit of not using keepalives for very long TCP sessions, necessitating a firewall rule that allows extremely long TCP sessions - over 18 hours to allow daily jobs to run.

When combined, this means that any TCP session that isn't properly closed will fail to re-start on a stateful firewall - and the application then breaks. The solution? Non-stateful firewall rules allowing host A to talk to host B, sourced from port X to port Y. You lose state tracking, protocol awareness, and any sort of application awareness, but you do get a working firewall rule even if bad things happen.

In the long term, we'll be asking the vendor about their take on how TCP/IP communications should be implemented...

Frontpage Lessons - UC Berkeley's Health Data Breach

UC Berkeley's recent announcement of a large scale health data breach serves as a great reminder of two basic basic security best practices - service separation and monitoring.

In this case, at least part of the flaw was a multi-use front facing system providing both web and database services with sensitive health data. Berkeley's announcement notes that "The attackers accessed a public Web site and subsequently bypassed additional secured databases stored on the same server." A multi-tier architecture with appropriate security precautions between each tier would likely have provided better security, and likely at a far lower cost than that of notifying 160,000 individuals of their potential exposure. The first lesson is that a strong architecture design for public facing systems can save a huge expense in both dollars and man hours later.

In addition to the multiple services on the single server, the length of time that the system was compromised indicates that it is likely that a range of other diagnostic and detection systems that could have been monitoring the server were not in use. According to the announcement, the server breach began on Oct. 9, 2008, and continued until April 9, 2009, and was only detected by routine server maintenance.

The second lesson here is that system monitoring is crucal - Tripwire, border flows to detect remote SSH sessions, and log auditing would have likely helped to find this compromise earlier.

Despite the flaws that led to the compromise, Berkeley appears to have done a good job after the fact of providing resources to affected individuals at datatheft.berkeley.edu and their process lists both activation of a CIRT and contact with the FBI. As any IT organization knows, some flaws will slip through, either old or new - Berkeley's response shows that they have a coherent plan, and this lesson should only serve to improve their overall security posture.

The Failure of Security Questions

MIT's Technology Review author Robert Lemos recently tackled security questions as a method of password retrieval or resets. We've all seen these before - often a small number of fixed questions that have predictable answers. I wrote about them from a user perspective back in 2008 - The Problem With Security Questions - And An Easy Solution, where I discussed using a password safe utility and using answers unique to each site.

Lemos points out that research found that "answers that require only a little personal knowledge to guess should also be considered unsafe" and that "Of people that participants would not trust with their password, 45 percent could still answer a question about where they were born, and 40 percent could correctly give their pet's name, the researchers found."

Your pet's name is likely in your Flickr photo stream, or your email inbox. Your co-workers likely know your favorite sports team, your favorite color may be easy to guess from your fashion choices, and your pet and your significant other may be conversational topics that they would rememember - making many security questions useless.

Many security questions are less than creative, and worse, because they're intended to be something that everybody can provide an answer for, they're likely to be something that others also know or can find out from easily accessible records.

• What is your mother's maiden name?
• What is your father's middle name?
• What is your favorite sports team?
• What is your favorite color?

Most users proceed to use actual answers to these, meaning that the answers are easy to find in today's connected, database driven world of available information. How hard is it to go from a first name, a last name, and a geographic location to a user's personal details? Not that difficult. Parents names can be found in birth records, or you may be able to simply check their LinkedIn, Facebook, or other profile. Their favorite color or sports team can be found in similar places - and there are a limited number of guesses for most people.

Worse, family, friends, and acquaintances can often guess their way into such sites. Security staffers will tell you stories of disgruntled spouses logging into their partner's accounts using the facts that they know about the person to reset their password.

Many sites handle this with an email based password send capability - which shrdlu notes that he simply uses every time he visits the site so that he doesn't have to remember the site's password. I'm sure many of the rest of us have developed similar bad habits - and, of course, if you can get passwords sent via email, anybody who takes over your email account needs only visit those sites and request a password reset to take over those accounts too.

But security questions serve a very useful purpose, particularly for sites that have a large number of users, or who have users who may use the site only infrequently. They're a somewhat reasonable way of allowing users to have the ability to reset their password, and they push some responsibility to those users to keep their security questions difficult. The problem remains that without better options, users often create a back door into their account.

So, what alternatives are there?

• Out of band methods, such as sending an SMS
• Multiple factor methods, such as
  
• Validate against another data point or preferably, data points
• Skip a reset method and have customer service deal with it
  

Of course, not having security questions can also be a problem for some sites - social engineering to get passwords reset has worked many times in the past too.

I'll keep my eyes open for clever ways to handle this problem, and, perhaps more importantly for ways to explain the risk model effectively to management.

Compromise Investigation: JavaScript Unescape

A simple method of obfuscating JavaScript code in a page is to use escaped characters - you get text like this:

\%100\%101\%%118\%105\%108\%115\%97\%100\%118\%111\%99\%97\%116\%101\%115\%101\%99\%117\%114\%105\%116\%121

This is then wrapped in a simple call as a normal JavaScript:

eval(unescape('data'));

This results in a block that isn't intelligible to the average user, but which also doesn't require much effort. The example that this came from was a simple webpage re-direct in a compromised web directory which was set up as a search engine redirect site. Simple, and yet reasonably effective and somewhat hard to locate using my normal searches.

How can you read this if you run into it? Simple. On a secure machine that is properly protected from exploits, copy the page, make sure that none of the other code is malicious, and replace "eval" with "document.write". Open the page in your web browser and you will see the actual text.

Where did this script point? An alias to another site, both of which appear to be used for search engine based advertising spam.

Selling Changes: Security Implementations

Part of the security program that I am in charge of is a transition to a Cisco Clean Access based "zoned" network. In parallel, we're migrating from a relatively open campus wireless network to an authenticated network with unencrypted and encrypted SSIDs for guests and our own users.

None of this is particularly attractive to end users or technical staffers in general - we're creating additional work for many by making them touch systems to install the Clean Access agent, or more user support time when their users can't figure out why they don't have network access when their system isn't authenticated. Many worry that we will filter their traffic, monitor it, or otherwise make their network access less usable than it was pre-change.

Since not every device is capable of handling CCA or web authentication, we have to deal with some switches on a port by port basis, and we also have to whitelist many devices.

How, then, you may ask, do I sell the project with thousands of users, over a hundred buildings, and a user base who are used to a flat, undivided network?

• First, I explain why the project is part of my program: we did a risk assessment, and this was identified as a risk to the organization, and in addition, we're doing it because we want to know who to contact for any given system, and who they are, at least on a role basis.
• Second, I explain why our management is behind this, and what their expectations are. This includes personal responsibility for both our IT staff and our users, and that they are responsible for protecting our network and our data.
• Third, I describe our test scenarios, our communication plans, and what our migration process involves. We've deployed to a variety of areas, we've tested extensively, and we have the ability to exclude problem areas. We also ensure that the changes are well communicated, that we meet with all parties in an area before deploying, and we have an on-site team post change.
  

So far, we're meeting with reasonable success. Management is behind the effort, and we have a talented technical team - but this effort is going to boil down to a large communications and sales effort.