Showing posts with label data breach. Show all posts
Showing posts with label data breach. Show all posts

Monday, October 5, 2009

Hotmail Passwords Leaked - Hotmail Users Shrug

Microsoft has confirmed an earlier report from Neowin that thousands of Hotmail passwords have been leaked online. Hotmail users, wondering what they are doing still using Hotmail when there are so many better options available, mutter "FML!"

It appears that several thousand passwords were posted to a forum dedicated to developers on the web site Postbin.com. While Redmond is still investigating, they have asked the site to remove the compromised credentials and are advising customers on how to deal with the breach.

Might I recommend not using Hotmail?

In their Windows Live blog, Microsoft suggests a phishing scheme is responsible for the compromise, and that the exposure took place at a third-party provider. They also helpfully point out that phishing is a widespread problem, effectively implementing the three-stage Microsoft response framework:

  1. Admit that there's a problem once someone makes it public.
  2. Blame someone else for it.
  3. Suggest that everyone has these problems, not just Microsoft.
The compromise includes email address with the @hotmail.com, @msn.com and @live.com suffixes, and may number 10,000 or more. Since initial reports indicate the breach involves accounts A through B, I'm curious about how a phishing scheme would target users in alphabetical order. Perhaps Microsoft will provide details at a future time.

If you have an email address ending in any of the suffixes potentially impacted, make sure you check with Microsoft to find out what you should do.


Sunday, August 2, 2009

Network Solutions Data Breach

Once again, a company entrusted with keeping secure the very components of personal information on which they depend for survival has failed. And once again, it will probably all blow over with nary a whimper of anger.

Network Solutions has admitted that they found malicious code on multiple E-commerce servers hosted for merchants' websites. Network Solutions claims that they have since removed the unauthorized code, and that no networksolutions.com servers were affected. That's of little consolation to those business sites that were compromised.

More than 570,000 credit card numbers may have been breached between March 12 and June 8, 2009, although Network Solutions states that they have not received any reports that the data has been misused, and in any event, they claim customers shouldn't worry about it because the issuing banks won't hold customers liable for any fraudulent transactions.

Sorry, Network Solutions, but that's not good enough. Please explain how the malicious code was able to be planted on multiple servers, and let us know which of your control failures led to nearly three months of this code running before you finally figured out that you had a problem.

I've said it repeatedly - until the penalty for exposing personal information is greater than the downstream costs of breach response (credit monitoring, etc.), companies will continue to violate the trust of their customers.

When Network Solutions advises "credit card issuing companies generally will not hold our merchants’ customers liable for any fraudulent purchases made using their credit card account numbers that are reported in a timely way to the issuer", who do they think pays for those fraud costs? Eventually, it's distributed among all of the issuing banks' customers in the form of higher fees and account costs.

So, Network Solutions, not only do your customers end up incurring higher costs because of your negligence, but so do all of the other customers with accounts at the same financial institutions. You not only screwed your customers, but also the rest of us who were smart enough not to use Network Solutions for their e-commerce and domain hosting services.

You can send Network Solutions a message that security of personal information is important by pulling any domain hosting or other services from them and switching to another provider. But Network Solutions would prefer that you simply let them worry about security. After all, they do an OK job, and regardless, what could possibly go wrong?

Updated Aug 2, 2009 @ 7:25 PM: You'll be pleased to know that Network Solutions is searching the Twitter to see who has Tweeted about them, and they noted my entry and therefore sent the following - netsolcares @kpshea Network Solutions deeply regrets this unfortunate incident. Real time assistance to customers @ http://cli.gs/gvqE7b #jw

I remain perturbed and am now annoyed at the extent of their damage control. If only they had expended this much effort protecting their data in the first place.

Image by ShashiBellamkonda via flickr

Monday, June 8, 2009

T-Mobile Breach May Result in Zeta Jones Ass Sharing

Glancing at the T-Mobile website, their slogan is now Stick Together. I shit you not.

I guess by sticking together they mean putting a bunch of their sensitive files in one big insecure place to make it easier for cyber-criminals to make off with them?

T-Mobile is investigating reports that they've been compromised in the wake of a neener-neener big fat wiener posting on Full Disclosure that announced some black hat had made off with the jewels and was offering them to the highest bidder.

To be fair, we should all take a deep breath until this claim is either proven or dismissed as bunk. Given that T-Mobile is now answering questions from the traditional media, it will be difficult to keep this genie in the bottle if it turns out that the databases were indeed snatched and in the possession of the bad guys (or girls).


If, however, this turns out to be true, I suggest that any T-Mobile penalty somehow includes sharing Catherine Zeta Jones' ass.


Security Fix - T-Mobile Investigating Data Breach Claims , via Security Fix


Tuesday, June 2, 2009

RAF Data Breach: Career Crash and Burn?

The Royal Air Force has a new motto: We Have Met The Enemy, and They Are Us!

Three RAF hard drives that were unencrypted have gone missing. That's always bad news.

What makes this even more newsworthy is the data alleged to be on those drives - voice recordings of high-ranking officers being interviewed for security clearances.


For those of you who have never experienced the special joy that is the clearance process, one of the primary components is the requirement to confess to all of your sins and transgressions, the theory being that it's much harder for foreign intel services to blackmail you later if your own agency already has an inventory of the skeletons in your closet.


So imagine that you spill your guts during the interview process, your deepest secrets are duly recorded, and then those recordings somehow disappear.

That would make me very, very grumpy.


Rather than serving their intended purpose - to keep the blackmail risk to a minimum - the breach of these recordings may actually place the careers of those interviewed in jeopardy, as the sensitive data on the drives could be used to either place pressure on these senior officers (do what we want, or we'll release some of these tidbits publicly to tarnish your reputation), or cause the resignation of a segment of the officer corps that preventatively wishes to keep their secrets...well....secret.


Nice work, RAF. You inspire trust and confidence daily.


Data Breach Exposes RAF Staff to Blackmail , via Wired


Thursday, May 14, 2009

How Data Breaches Screw Everybody

I've written extensively about data breaches, such as the postings here, here and here. Quantifying the costs associated with breaches can be troublesome, since many of the dollars associated with the incident are often far downstream from the source of the original incident.

Case in point - the Heartland breach, pointed out by Brian Krebs in his Security Fix blog. As it turns out, Angie's List started dropping subscribers left and right and they couldn't get their arms around the reason.

As it so happens, many of the drops were caused because customers who had their credit card numbers exposed in the massive Heartland breach were issued new credit cards (and account numbers) by their issuing banks, and the old numbers that were tied to their Angie's List accounts were no longer valid.

When Angie's List used their normal subscription auto-renewal processes for those customers, they obviously attempted to bill now-invalidated accounts, so the renewal was not successful, and those subscribers lost access.

Some would say that if people really cared about this, they would have paid attention when their card was reissued and would have updated their account info with Angie's List. That's a load of beetle dung. My time has a value, and if I have twenty merchants or online subscriptions that are linked to one of my cards, updating that info manually at each location becomes quite the effort, especially since the need for this activity can be directly attributed to a failure by Heartland to keep my personal information safe and secure.

In cases such as these, other merchants and companies can suffer significant financial losses from a breach caused by a firm with whom they have absolutely no relationship. If I was a class-action attorney, I'd be rounding up my list of clients from the thousands of consumers and merchants impacted by the need for 600 banks to cancel and reissue credit cards resultant from the Heartland breach.

As you've heard me preach again and again, firms will not get serious about protecting customer information until the cost of breaches and penalties far exceeds the cost of implementing robust data protection and anti-breach programs. Until then, keep a good list of all the places where your credit card number may be stored online, if you're silly enough to do that.

I have a feeling you're going to be manually updating that information frequently.

Security Fix - Heartland Breach Blamed for Failed Membership Renewals



Friday, May 8, 2009

UC Berkeley Data Breach

CNET Security is reporting that computers at the University of CA at Berkeley have apparently been hacked, placing the personal information of as many as 160,000 individuals at risk.

At least 97,000 Social Security numbers were accessed, which is a very big deal.

Preliminary investigation seems to show that the attackers gained access through a public-facing web site, then bypassed controls to break into a database stored on the same server. Again, security best practice is to NOT store the db on the same physical or virtual server for this very reason.

This was a Health Services computer, so you can bet there will be all sorts of recriminations. With all the rules surrounding the HIPPA reg, a granular investigation will undoubtedly take place.

I'll keep you posted, so stay tuned.

UC Berkeley computers hacked, 160,000 at risk


Friday, May 1, 2009

Lost USB Drive Bad for Spies

Think you'll get in trouble where you work if you lose a USB stick containing sensitive data? At least you're not MI6.

Wired has the story of major multi-million dollar undercover drug operation that needed to be scrapped after an agent left a USB memory stick filled with secret mission data behind on a train.

Things were so bad that undercover operatives had to be relocated due to the life-threatening implications of the lost information.

There's something about British government agencies and their inability to keep their secrets...well, secret.

Perhaps it's something regarding their diet.

MI6 Nixed Major Undercover Operation After Memory Stick Lost


Thursday, April 23, 2009

Easily Hacked Company Awarded IRS Contract To Use Your Data

If the Obama administration wants to take the lead in enhanced cyber security, perhaps they should start with their very own Internal Revenue Service.

The IRS has awarded a huge contract for processing tax return payments to RBS Worldpay, a firm that recently reported that hackers gained access to 1.5 payroll card holders and nearly 1.1 million Social Security numbers that they were supposed to be protecting.

As it turns out, RBS was found to not be PCI compliant, according to VISA. That's pretty bad news when your main business is processing credit card transactions, and PCI was designed to ensure adequate controls exist within the credit card industry.

The IRS claims that RBS will not be able to process credit card transactions until 2010, and that not only will RBS need to re-gain PCI certification, but also pass a payment security audit from the IRS.

Since past behavior is a good predictor of future events, you may want to consider not paying your taxes by credit card.

It's hard to lose $1000 in rolled nickels.

Security Fix - IRS Awards Tax Payment Contract to RBS Worldpay


Wednesday, April 1, 2009

Be The Problem, Sell The Solution

I suppose if your business model is dependent on protecting your customers from new and emerging threats, there's a danger that if cutting-edge perils disappear, so will your clientele.

Symantec may have solved that problem for themselves.
The security company, known primarily for their antivirus, anti-spyware, and other endpoint-protection products, is on the hot seat after BBC news reporters allegedly purchased customer credit card numbers from an employee of a Symantec call center in India. Oops.

Symantec claims that the nefarious conduct was limited to one call center agent, and that they had no indication that any of the credit card numbers were used improperly.
Do you know what else Symantec had no indication of? That they had a call center employee stealing and selling customer credit card numbers.

Call centers typically have robust risk and control procedures in place to limit their exposure to illicit activities among staff. Turnover and low compensation among agents and advisors has historically led to improper behaviors, and the call center environment is ripe with the kind of personal information that's in high demand by fraudsters.
Common call center procedures include the banning of any writing instruments or materials and no loose papers that advisors could use to capture and remove sensitive customer data. Computer systems are configured to not have access to email or the internet so that no data can be transmitted externally, and information cannot be written to removable media devices. Screen captures are similarly disallowed. Finally, there are aggressive anomaly detection mechanisms in place to alert security personnel to any aberrant activities.

Somewhere along the line, Symantec had either a failure of one or more controls, or a gap developed between the collection of tracking data and subsequent actioning. Either way, for a security-focused company, this is not good news.

Still, with the volume of customer data at hand and the vast number of employees who probably have access as a requirement to do their jobs, the fact that one agent was involved and the number of compromised accounts was reported to be in the 200-300 range, give Symantec a pat on the back for being open about the breach and proactive in taking steps to protect their customers.

As I've said before, you can't eliminate risk completely. You can only mitigate and respond. It appears that Symantec has done both.



Thursday, March 12, 2009

Norm Coleman Remains Dickish


There are lots of good reasons to justify calling Norm Coleman a dick. His policy stances. The current investigations into his alleged wrongdoings. The horrible advertisements he ran during his campaign. His egomaniacal contesting of the Minnesota election results.

From a data security perspective, this takes the cake - Norm breached the personal and credit card information of his donors on his website back in January, and is only now getting around to letting people know that it would probably be a good idea to cancel those credit cards.

Norm has been trying to spin this as a "hacker" incident, which it isn't. He screwed the pooch, plain and simple - the information was housed in a database, unencrypted or otherwise protected, on a public web site, where it was discovered and eventually posted on the WikiLeaks site.

Standard practice is to never host sensitive data like credit card information on the same physical or virtual server as the web server - for obvious reasons. PCI guidelines call this out clearly, while recommending that the sensitive data be encrypted or otherwise controlled so that even if someone was able to get access to it, it would be worthless without knowing the keys or associated algorithms.

Still to be determined is whether Minnesota data breach laws were broken, given the fact that the incident took place in January and affected donors are only now being made aware of the breach.

Fingers are being pointed by the Coleman camp at a third party provider, which shouldn't give them much cover, as organizations are accountable for ensuring that third parties have adequate security and controls in place.


The truly dickish move? On the breach FAQ section of Coleman's site, there's actually a solicitation for a donation. Gotta hand it to Coleman. If you're going to be a dick, be a big one.



Tuesday, January 20, 2009

Heartland Data Breach

In what may eventually become a staggering data breach that surpasses TJX in the volume of customers and accounts impacted, payment processor Heartland has announced that its systems were infected by malware sometime last year and that the firm has been leaking customer data ever since.

Heartland reported that, while determining that the infection occurred sometime last year, they only found evidence of the intrusion last week, and they immediately notified law enforcement and credit card companies. Thanks for that.

How can a payment processing firm that counts more the 250,000 businesses as clients, a company that handles more than 100 million transactions a month, go for any significant time with compromised systems and not know? 

When (and if) they performed internal security assessments to determine their high risk data and the controls that were in place to mitigate or eliminate the risks associated with it, did the audit and control teams simply fail to identify malicious code as a threat? Or did they appropriately call out malware and chart their detective and preventative controls, at which point they were either hugely mistaken about the effectiveness of those controls, or there were gaps identified that were never remediated?

One of the recent trends noted in the malware front is targeted exploit code that's tailored to attack certain systems types, or designed to detect, collect, and transport high-value data types, such as Social Security numbers, EINs, credit card and account numbers, and so on.

Unlike the good old days, when hackers and crackers, script kiddies mostly, would break into a system, it was only a matter of time before that fact became public, generally because the attackers wanted the notoriety. There was a lot of noise when something like this happened.

The modern day data thieves have a much different approach - think cat burglar as opposed to someone who throws a trash can through a window to gain entry. 
The glass smasher might get inside, but the crashing glass itself sounds an alarm and leaves evidence of the break-in, effectively limiting the amount of time for the valuables to be collected.

A cat burgler, by definition, sneaks in quietly, prowls the premises until discovering the items of worth that were the targets of the crime, and removes them, leaving everything else undisturbed - often times leaving few tracks and little evidence behind.
The longer an attacker can keep a compromised system hidden from discovery, the more data he (or she - equal opportunity crooks welcome) can acquire for nefarious purposes. Similarly, more information squired offsite means a much richer payoff when the data is sold to third parties or used by fraudsters to perform transactions using unsuspecting customer accounts.

One question that so far remains unanswered is how the malware was introduced into Heartland's systems. Was there a propogating worm introduced via email or through a compromised website? Did someone plug an infected USB drive into a machine? Was it an inside job?

I'd be interested in the code analysis to determine whether it's something that the existing antivirus software should have alerted on - and I understand I'm assuming here that AV protection was both active and updated. Along the same lines, were the infected systems completely patched for known security vulnerabilities and was their baseline security configuration hardened, with state monitoring enabled? What about vulnerability assessment and management?

Did Heartland employ network anomoly detection - how did this captured data leave the firm? If it was going out over the network, how did the HIDS and NIDS not fire, if deployed?

Much has been written over the past several years about security being a "defense in depth" approach, where your security and control environment is multi-tiered to hopefully prevent and certainly detect malicious events. It would appear that there were multiple failures in the Heartland case, and judging by the penalties assessed in the wake of the TJX breach (45.7 million credit & debit card numbers exposed), coupled with the cost of notifiying what could be several hundred million customers, and providing them credit monitoring services, this will prove to be a very expensive lesson for Heartland.

As written in my posting SANS 2009 Security Predictions, and my security crystal ball article excerpted at GovernmentSecurity.org, data breach legislation is a trailing indicator of security and control effectiveness. When breaches don't happen, legislators tend to focus on other things. When big breaches are in the news, there are more drum beats about the need for standardized federal laws and regulations around data protection and breach notification. 

This could be the incident that tips to scale to kick off a federal response, depending on the details that emerge as Heartland's systems undergo forensic examination. Stay tuned.




Wednesday, January 14, 2009

Stupid Security

I've been preaching for a long time about the benefits of encrypting removable USB flash drives, since they are easily lost and it's a breeze to suck your data off of them.

So if you're encrypting your USB keys, you're smart. Very smart. If you attach your encryption key to the device, you're dumb. Very dumb.

Such was the case with prisoner health information from Preston Prison in Lancashire, UK. More than 6300 prisoner's data was on the USB stick.

Workers from NHS Central Lancashire involved in the incident have been suspended while the investigation takes place.

It is believed a member of NHS Central Lancashire staff had uploaded the information using the memory stick then returned to the administration office and lost the device somewhere on route.

There's that data-in-transit and human error thing again, as I pointed out in my posting yesterday on the rise of data breaches. How many of these incidents need to occur before people dummy up and start doing the right thing?




Tuesday, January 13, 2009

Data Breaches on the Rise

In my Jan. 1 posting, SANS 2009 Security Predictions, I referenced the Identity Theft Resource Center and the timely studies that they release concerning data breach trends. Their new report details a 47% increase in US data breaches over 2007.

Not surprisingly, the two areas called out in the breach statistics were lack of encryption and lack of passwords on the breached data. Password protection is a pretty weak method of protecting your data, given the computing power available today to brute-force or dictionary attack the passwords. Even using pass-phrases instead of passwords is less than effective, depending on the length of the phrase, as some platforms simply hash and store the result, and breaking the smaller hash is relatively simple.

One sector that showed the largest increase in reported breaches was in the business category, increasing 36.6% in 2008, after posting smaller increases of 28.9% and 21% in 2007 and 2006 respectively. Government/Military and Education actually saw decent decreases over the same timeframe.

Only 2.4% of all reported breaches had encryption or other strong protective controls in use. 7.3% of the business breaches involved data in transit - either via backup tapes, removable media, or in some cases, electronic data movement, which could include misdirected or erroneous transmissions. Overall, data on the move and accidental exposure account for 35.2% of all breaches with a cause determined, and both fall into the "human error" category.

There is vigorous debate among security and privacy professionals about these trends, and the discussions typically take one of two approaches - we're a lot better at identifying breaches as they occur via preventative and detective controls, and we're doing a better job of complying with state data breach notification laws and regs. While both are true to an extent, I firmly believe there's one other point to be made.

There's still too much data being created and stored, and we've yet to achieve a good maturity model for controlling access to data based on a clear need for people to have the data in order to do their jobs. At every step in the information lifecycle, from creation to destruction, how well do we understand what data we have, where it's located, how it's protected, and who has access to it?
When information moves during use, whether from web apps into back-end systems, from collection points to databases, or from data stores to applications or tools that parse, analyze, or process the data, where are the gaps in our controls environment and how do we close them? Do you have a good methodology for testing the effectiveness of the applicable controls, including documentation about what sort of evidence is sufficient to substantiate whatever controls effectiveness rating you plunk down on a particular measure?

The Computer Security Division of the National Institute of Standards and Technology has just released SP 800-122
DRAFT Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), open for comment through March 13, 2009. NIST presents a general, but effective overview of how to protect PII that is applicable to data of all types, especially if your organization struggles to differentiate between data types. NIST obviously recommends performing data analysis to ascertain the types of data you hold, assigning risk classifications to the various data types, and implementing security and control based on risk.

Most mature organizations have some sort of information classification program, but the wheels come off somewhere between tagging the data and reporting that the data is breached. The challenge is to perform a root cause investigation to see where you went wrong. Did you fail to risk assess the data types, or did you not apply the controls that were applicable based on data and risk classifications? Or perhaps you applied the controls and it turned out your testing didn't identify control gaps or the existence of ineffective controls. Maybe you did identify control gaps, but either didn't have remediation plans in place, or the breach occurred before you could complete your remediation. Perhaps human error was involved in any (or all) of these phases, or you didn't enforce separation of duties or other best practices.

Until we all get our arms around the concept of controlling how much data we collect, retain, process, and store, and enforcing stringent protection mechanisms at every phase of the information lifecycle, we'll continue to see disturbing breach trends. It's only a matter of time until the incoming Obama administration begins to push for federal data protection and breach notification legislation as an umbrella approach to supplant the myriad state laws and regulatory agency requirements while pushing a straighforward, easily-measured enforcement framework.

At this point, I'm not convinced that moving to a federal model is a bad thing. Time will tell.


Thursday, January 1, 2009

SANS 2009 Security Predictions

The SANS Technology Institute has released version 1.7 of their 2009 Security Predictions.

Assorted experts from various fields collaborated to produce this collection about the future of security for computers, networks, and information.

It's a wide-ranging piece that frankly lost some focus as more data was collected. It's hard for me to find actionable intelligence for my day job in this compilation, but it's a valuable as a digest of what's expected to transpire over the next twelve months.


One thread that I happen to agree with is a future-looking view that a significant data breach will occur at a firm shown to be PCI/DSS compliant.

As we learned in 2008, several breaches were reported via the Open Security Foundation Data Loss db that involved organizations with varying levels of PCI/DSS programs implemented.


Government regulation tends to be a trailing indicator of effective security and control. What typically happens is that a flurry of incidents becomes public, and the industries involved are either slow to react by redesigning their programs or in re-evaluating the effectiveness of their controls, so politicians clamor for regulations and directives to force widespread compliance to a set of requirements so cookie-cutter that they can't possibly be effective in companies of various sizes, degrees of complexity, or breadth of information and infrastructure.


The number of reported data breaches hasn't been reduced, even after the introduction of significant regulation such as HIPAA, SOX, PCI, and others. Many regulations have been targeted to specific data sources or business types, which has led to irregular approaches to data privacy and protection tailored to meeting regulatory requirements rather than improving security posture.
Data Loss statistics indicate the following breakdown of incidents by industry type:
  • 36% business
  • 28% education
  • 24% government
  • 12% medical
HIPAA standards for the health care industry have been in effect for years, and some would like to point to the 12% as evidence that the focus has worked. However, are we certain that all breaches are being reported, or has the increased attention simply made hospital administrators and other professionals more careful about what they release publicly?

Massive breaches at companies like TJMaxx (45.7 million credit card numbers and transactions), US Dept. of Veteran's Affairs (26.5 million veteran's personal information stolen) and Hannaford (4.2 million credit and debit card numbers exposed) get all the attention, but there are substantially more people affected by the thousands of other breaches that, if made public at all, drop from the media's radar within hours.


Hannaford's breach occurred in 2008, and one of their first statements of defense was that they were PCI compliant. They soon dropped that approach when it failed to buy them any measure of sympathy from an outraged public, indignant security professionals, or embarrassed government officials who designed PCI in an incestuous partnership with the credit card industry.

In October 2008, Brian Krebs reported in his
Security Fix blog that The Identity Theft Resource Center found that 2008's data breach tally had already exceeded 2007's 446 incidents, with at least 680 breaches predicted by the end of the year. 30 million customer records had been exposed through October.

There are differing explanations for these results, depending on which group of experts you're dealing with. Some believe the issue is simply that there are more breaches. Others opine that organizations are getting better at detecting breaches - not preventing them, which should be the goal, but detecting them. The third explanation is
that more organizations are complying with state data breach notification laws.

Regardless of the explanation, it's clear that we're not seeing a statistically significant improvement in the privacy and protection of information. There's too much data being retained, too little documentation on where the information is located, how it's protected, and who has access to it, and too little attention paid to destroying data when it's no longer needed for legitimate purposes.