Hyperbole in Breach Reporting

While reading the news this morning about yet another successful data breach, I couldn't help but wonder if the hyperbole used in reporting about data breaches is stifling our ability to educate key stakeholders on what they really need to know.

Today's example is about a firm that many rely on for security strategy, planning, and execution. The article I read stated that they were "targeted by a sophisticated hack" but later explains that the attacker compromised a privileged account that provided unrestricted "access to all areas". And, according to sources, the account only required a basic password with no two-step or multi-factor authentication. That doesn't sound too sophisticated, does it? Maybe they brute-forced it, or maybe they just guessed the password (or found it written down in an office?)

It reminded me of an attack on a security vendor back in 2011. As I recall, there was a lot of talk of the sophistication and complexity of the attack. It was called an Advanced Persistent Threat (and maybe some aspects of it were advanced). But, when the facts came out, an employee simply opened an email attachment that introduced malware into the environment - again, not overly sophisticated in terms of what we think a hack to be.

The quantity, availability, and effectiveness of attack techniques are enough to make anyone uncomfortable with their security posture. I previously wrote about a German company who, in a breach response, wrote that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." CISOs are being told that they should expect to be breached. The only questions are about when and how to respond. It makes you feel like there's no hope; like there's no point in trying.

However, if you look at the two examples above that were described as highly sophisticated, they may have been avoided with simple techniques such as employee education, malware detection, and multi-factor authentication. I don't mean to over-simplify. I'm not saying it's all easy or that these companies are at-fault or negligent. I'm just calling for less hyperbole in the reporting. Call out the techniques that help companies avoid similar attacks. Don't describe an attack as overly sophisticated if it's not. It makes people feel even more helpless when, perhaps, there are some simple steps that can be taken to reduce the attack surface.

I'd also advocate for more transparency from those who are attacked. Companies shouldn't feel like they have to make things sound more complicated or sophisticated than they are. There's now a growing history of reputable companies (including in the security industry) who have been breached. If you're breached, you're in good company. Let's talk in simple terms about the attacks that happen in the real world. An "open kimono" approach will be more effective at educating others in prevention. And again, less hyperbole - we don't need to overplay to emotion here. Everyone is scared enough. We know the harsh reality of what we (as security professionals) are facing. So, let's strive to better understand the real attack surface and how to prioritize our efforts to reduce the likelihood of a breach.

Layered Database Security in the age of Data Breaches

We live in a time of daily breach notifications. One recently affected organization in Germany put out a statement which said: "The incident is not attributable to security deficiencies." and "Human error can also be ruled out." They went on say that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." It's a tough climate we find ourselves in. It  just feels too hard or impossible at times. And there's some truth to that. There are way too many potential attack vectors for comfort.

Many breaches occur in ways that make it difficult to pinpoint exactly what might have prevented it. Or, the companies involved hide details about what actually happened or how. In some cases, they lie. They might claim there was some Advanced Persistent Threat on the network when in reality, it was a simple phishing attack where credentials were simply handed over.

In one recent case, a third party vendor apparently uploaded a database file to an unsecured Amazon AWS server. A media outlet covering the story called out that it was not hacking because the data was made so easily available. Numerous checkpoints come to mind that each could have prevented or lessened the damage in this scenario. I’d like to paint a picture of the numerous layers of defense that should be in place to help prevent this type of exposure.

Layer 1: Removing Production Data

The data should have been long removed from the database.

Assuming this is a non-production database (and I sure hope it is), it should have been fully masked before it was even saved as a file. Masking data means completely removing the original sensitive data and replacing it with fake data that looks and acts real. This enables safe use of the database for app development, QA, and testing. Data can be masked as it’s exported from the production database (most secure) or in a secure staging environment after the initial export. Had this step been done, the database could safely be placed on an insecure AWS server with limited security concerns because there’s no real data. An attacker could perhaps use the DB schema or other details to better formulate an attack on the production data, so I’m not recommending posting masked databases publicly, but the risk of data loss is severely limited once the data is masked.

Layer 2: Secure Cloud Server Configuration

The researcher should never have been able to get to the file.

A security researcher poking around the web should never have been able to access this database file. Proper server configuration and access controls should prevent unauthorized access to any files (including databases). In addition to documenting proper security configuration, certain Cloud Security Access Brokers can be used to continuously monitor AWS instances to ensure that server configurations match the corporate guidelines. Any instances of configuration drift can be auto-remediated with these solutions to ensure that humans don’t accidentally misconfigure servers or miss security settings in the course of daily administration.

Layer 3: Apply Database Encryption

Even with access to the database file, the researcher should not have been able to access the data.

At-rest data encryption that is built into the database protects sensitive data against this type of scenario. Even if someone has the database file, if it were encrypted, the file would essentially be useless. An attacker would have to implement an advanced crypto attack which would take enormous resources and time to conduct and is, for all intents and purposes, impractical. Encryption is a no-brainer. Some organizations use disk-layer encryption, which is OK in the event of lost or stolen disk. However, if a database file is moved to an unencrypted volume, it is no longer protected. In-database encryption improves security because the security stays with the file regardless of where it’s moved or exported. The data remains encrypted and inaccessible without the proper encryption keys regardless of where the database file is moved.

Layer 4: Apply Database Administrative Controls

Even with administrative permissions to the database, the researcher should not have been able to access the sensitive data.

I’m not aware of similar capabilities outside of Oracle database, but Oracle Database Vault would have also prevented this breach by implementing access controls within the database. Database Vault effectively segregates roles (enforces Separation of Duties) so that even an attacker with DBA permissions and access to the database file and encryption keys cannot run queries against the sensitive application data within the database because their role does not allow it. This role-based access, enforced within the database, is an extremely effective control to avoid accidental access that may occur throughout the course of daily database administration.

Layer 5: Protect Data Within the Database

Even with full authorization to application data, highly sensitive fields should be protected within the database.

Assuming all of the other layers break down and you have full access to the unencrypted database file and credentials that are authorized to access the sensitive application data, certain highly sensitive fields should be protected via application-tier encryption. Social Security Numbers and Passwords, for example, shouldn’t be stored in plain text. By applying protection for these fields at the app layer, even fully authorized users wouldn’t have access. We all know that passwords should be hashed so that the password field is only useful to the individual user who enters their correct password. But other fields, like SSN, can be encrypted at the app layer to protect against accidental exposure (human error), intentional insider attack, or exposed credentials (perhaps via phishing attack).

Maybe the vendor didn’t follow the proper protocols instituted by the organization. Maybe they made a human error; we all make mistakes. But, that’s why a layered approach to database security is critical on any database instances where sensitive production data resides. Security protocols shouldn’t require humans to make the right decisions. They should apply security best practices by default and without option.

Assuming this was a non-production database, any sensitive data should have been fully masked/replaced before it was even made available. And, if it was a production DB, database encryption and access control protections that stay with the database during export or if the database file is moved away from an encrypted volume should have been applied. The data should have been protected before the vendor's analyst ever got his/her hands on it. Oracle Database Vault would have prevented even a DBA-type user from being able to access the sensitive user data that was exposed here. These are not new technologies; they’ve been around for many years with plentiful documentation and industry awareness.

Unfortunately, a few of the early comments I read on this particular event were declarations or warnings about how this proves that cloud is less secure than on-premises deployments. I don’t agree. Many cloud services are configured with security by default and offer far more protection than company-owned data centers. Companies should seek cloud services that enable security by default and that offer layered security controls; more security than their own data centers. It’s more than selecting the right Cloud Service Provider. You also need to choose the right service; one that matches the specific needs (including security needs) of your current project. The top CSPs offer multiple IaaS and/or PaaS options that may meet the basic project requirements. While cloud computing grew popular because it’s easy and low cost, ease-of-use and cost are not always the most important factors when choosing the right cloud service. When sensitive data is involved, security needs to be weighed heavily when making service decisions.

I'll leave you with this. Today's computing landscape is extremely complex and constantly changing. But security controls are evolving to address what has been called the extended enterprise (which includes cloud computing and user mobility among other characteristics). Don't leave security in the hands of humans. And apply security in layers to cover as many potential attack vectors as possible. Enable security by default and apply automated checks to ensure that security configuration guidelines are being followed.

Note: Some of the content above is based on my understanding of Oracle security products (encryption, masking, CASB, etc.) Specific techniques or advantages mentioned may not apply to other vendors’ similar solutions.

Human Behavior = Biggest Security Risk

Two quick examples (both considered 'spear phishing' or targeted phishing attacks) from today's headlines:

1. The perpetrators of the RSA data breach which may have compromised the security of RSA's premium two-factor authentication solution, as it turns out, got help from RSA employees when they opened an email attachment. An Excel spreadsheet containing an Adobe Flash exploit opened the doors to RSA's network.

2. Conde Nast recently paid $8 Million to a fake company in response to a single believeable email that asked them politely to update their payee information on one of their vendors.

Both of these examples make the clear, simple point that it doesn't really matter how much technology you put between an attacker and your business assets. If an employee opens the door, they can walk right in. We're either going to get extreme in terms of limiting behavioral options (disallow all email attachments?) or we need to do much better in employee training.

Since employees are ultimately only motivated by what is easier, I don't think training will be the silver-bullet answer.

The RSA Breach

[Updated 5:36 pm ET 23 Mar 2011]

Sorry - two points of clarification:

1. Where I say "serial #" throughout my post below, we should keep in mind that the token has a hidden 'seed record' which is actually used in the algorithm, so that's another level of security. The serial # is not enough - you also need the seed # and the ability to match it to a given user's token.

2. I should've mentioned that there's also a feature which prevents brute-force attacks by disabling an account after x number of failed attempts, so if you have a very good educated guess on the PIN, along with the other data, you have a good shot. If you think you'll brute-force it, that isn't going to fly.

[end update]


I don't have any inside info, but it certainly sounds like the algorithm for generating the One-Time-Passwords (OTP) may have been accessed. This makes an attack much easier because to some degree it eliminates the "second factor" in the Two-Factor authentication. But not 100%.

If I know the algorithm, to spoof the token functionality, I still need the serial # of the token, matched to the user name, and the PIN. These things aren't impossible, though. You could stop by a person's desk, for example, and scribble down their serial # while they're getting coffee. If they're a co-worker, you probably know their user name and can make some guesses about the PIN.

Most people I know that use RSA tokens use a pretty simple PIN - a date, 4 digits of a phone number, something like that. So, if you use social engineering to get the serial # and user name, your down to having to guess the PIN, which is really a shorter, less secure password. And you're back to one-factor authentication. PINs may also be written down on the desk, scribbled on the back of the token (I've seen it), left in email or browser auto-fill, etc.

For an outsider to use this attack, it's a little more challenging than an insider. You'd need access to the serial numbers used by the company and the ability to match them with user names. Based on the info provided by RSA in their letter to customers, some or all of this may be in the RSA server logs. So, protecting those logs has just become critical.

If the token is installed on a smart phone or PC (software token), the token only works from that installed device. So, if the algorithm is public, the software tokens may have just become slightly more secure than the hardware tokens since it would be difficult to spoof the hardware configuration (or even to know the exact hardware) associated to that software token. ...at least, that's how I think it works.

So, a few shifts have been made if my assumptions are true:
- Software tokens may be more secure if the algorithm is known.
- Protecting the RSA server and logs, and access to those logs has become critical.
- Overall, the system is still somewhat secure, but people don't buy RSA tokens for 'somewhat secure'.
- RSA tokens have become pretty insecure against insider attacks.

If anyone knows something different, please correct me.

Crows Using Vending Machines and the Security Implications

As reported in the NY Times, researcher Josh Klein actually taught crows to buy their own food from vending machines. If you have 10 minutes, the TED presentation is definitely worth watching. Crows are way more intelligent than you would think.

And we think we can stop them with an inanimate pile of clothes stuffed with hay!


Of course, there's a lesson to be learned for information security practicioners. Your company's employees and system adminstrators will learn and adapt. They can see the scarecrow that you've put in place to ensure security. And they figure out how work around it.

Security company RSA in their Oct. 2008 survey reported that:

53% [of employees] have felt the need to work around IT security policies in order to get their work done.

Those are well-meaning employees just trying to do their best for the company.

A recent NetworkWorld article titled Inside a data leak audit provides a real-world example. It describes an organization that was seemingly doing everything right with regard to information security. But, a thorough audit revealed 11,000 potential leaks in two weeks. All the scarecrows you could imagine were hanging on posts all across the organization. They weren't enough.

Preventative security doesn't always get the job done. Many organizations would benefit from real-time audit and monitoring solutions. In addition to after-the-fact forensic and audit trail benefits, active monitoring can be a powerful deterrent and even enable real-time remediation.

Online Identity Privacy - Users Don't Take Precautions

One of my tenets for online privacy is:

Don't do anything online that you absolutely want to keep private.

Case in point:

I was looking through the form submissions to my company's web site. There is consistently some percentage of submissions that are auto-submitted SPAM. Sometimes, it's obvious and sometimes not.

Today, I was researching one submission and googled her name and email. The search brought me to a page that listed a spreadsheet of form submissions to another site - complete with names, email, phone numbers, and comments. Some obvious spam, but others obviously real.

They're showing up because of a technical glitch or security issue on the site. The google search brought me directly to the site's administrative page with no logon.

What makes this story interesting is that the site is a Las Vegas escort service and some of the form submissions read as follows:

• From a student (@uwec.edu) - "very interested"
  
• From a student (@wvu.edu) - "I need a price on ____"
  
• From someone claiming to work at Microsoft - "Hi, I'm planning a trip to Vegas with my fiance but I wanna get away from her for one night. What is the limit to your services and who would you recommend? I need a girl with _____. Thank you for your time." (how polite) ...he may not have put his real company, but another quick search found his email address with a profile telling me that he lives in Seattle(!)
  
• From a Web Developer in MN - "I am interested in an escort to accompany me to dinner" - (I found his LinkedIn profile because he provided his real company name)

...you get the idea.


Two lessons:

• First, the obvious one - don't trust web sites to keep your information private.
  
• Second, (to the security practitioners who read this blog) - don't underestimate how willing people are to give up their personal information to even the most suspect organizations.

btw - Who thinks this privacy breach will be reported?

Bad Guy Scenario

Here's a perfect example of the insider "bad guy" threat scenario. An unhappy ex-employee came back in through an Internet-based system and put malicious code on the company's customers' servers. He installed the code on 1000 servers and crashed 25 out of the 1000. The company reports a cost of $49,000 to find and fix the problem. They also say it could have cost $4.25 million if all 1000 servers had crashed.

The Lessons:

• Be diligent about monitoring – catching this early saved close to $4 Million
• De-Provision (it's unclear whether the employee still had an account)
• Include hosted and Internet systems in your de-provisioning process
• Do security audits to find and fill holes

Although I don't think the "bad guy" scenario happens nearly as much as the "good guy" security breach scenario, it has the potential to get very expensive very quickly.

Data Breaches Up in 2008

The Washington Post reported today that Data Breaches were up 50% in 2008. There are probably lots of contributing factors to the increase in stats:

• As the article points out, an increase in participation and sophistication of organized crime with regard to electronic crimes. I've heard this in multiple places.
• Stricter adherence to regulations that require notification of breaches (as pointed out by Shannon McNaught on Twitter -- where I stumbled across the article)
• Continued lack of deterrents for Crimes of Opportunity. Organizations have been slow to get serious about monitoring admin activity.
• An increasing reliance on electronic forms of data - people and companies have increasingly become more trusting and more reliant on electronic media. This makes the data increasingly more valuable and therefore a bigger target.
• Improved tools and sophistication that enables theft. A 16 GB USB key is an extremely effective way to quickly transfer large amounts of data without being detected. Improved technology and lower cost has introduced new and stronger threats.

The article also states that "The largest single cause of data breaches came from human error" once again affirming my proposal that by far most breaches are not malicious. I recently heard a genuine real-world story that an admin made an error on a windows drag-and-drop (as we all sometimes do) and an entire factory was brought to a standstill -- an OU was moved in AD.

It also points out that statistics "mask the extent of the problem" because many organizations fail to report data breaches. As I said before:

Nobody calls a forensics team when an admin opens up an HR doc containing a co-worker's salary. Or when an admin creates a new account and grants full system rights in order to get a new application up and running.

We all know the implications. If you've got sensitive data, understand your risk, know what your threats are, and be proactive before you become one of the stats.

89% of Security Incidents in 2007 Unreported

I've been saying for the past few years that most security breaches go unreported, but I had no hard data to back it up.  I just believed it by instinct and some anecdotal evidence.  Now, we have a survey to point to with supporting data that claims 89% of data leakage incidents in 2007 went unreported.  I've also talked a lot about non-malicious insider breaches which is listed as the #2 security challenge by respondents of this survey.  I haven't seen that question asked very often.  Interesting data points.  Data leakage, lost devices, insider threats continue to be a major concern (along with email attachments, malware and phishing).

Cyber-Ark Study: 88% of IT admins would steal

From the press release:

Of the 88 percent that said they would take valuable information with them, one third of devious IT administrators would take the privilege password list which would give them access to all the other sensitive and valuable documents and information such as financial reports, accounts, and HR records.

Also:

The survey also found that one third of IT staff admitted to snooping around the network, looking at highly confidential information, such as salary details, M & A plans, people's personal emails, board meeting minutes and other personal information that they were not privy to. They did this by using their privileged rights and administrative passwords to access information that is confidential or sensitive.

I guess if you're hiring an IT admin, you might ask if they participated in the Cyber-Ark study and if so, there's an 88% chance that you shouldn't hire them. I know the criticism about surveys like this, but is it really that hard to believe? Seems like human nature to me.

Criminal Data Loss

Seems like some people just aren't paying attention. Every time I think we've gotten past a point as an industry, someone proves me wrong. I would think by now we wouldn't be carrying very large highly confidential data sets on unencrypted USB sticks.

Can you imagine how the exposed data on 130,000 criminals will be used? I'm sure someone would find a way to monetize a list like that. I can see a few angles:

----

SUBJECT: WORK FROM HOME!!

Dear _____,

Why break into homes and cars when you can steal from the comfort of home?!? Try our latest web site phishing kit and collect credit card information from unsuspecting shoppers. No black ski masks, no up-front discovery work, and no commute!

----

Or maybe...

----

ATTN Hiring Manager:

Are you having trouble staffing up for your next big heist? Contact CriminalTemps where we can provide full or part time criminals. 100% no-police guarantee!!

Insider Threat: Crime of Opportunity

For the past few years, I've talked to many people about the insider threat. I don't spend too much time focused on the hardcore criminal element that plan an attack against their employer. I have mostly been thinking about the 35% of employees that claim they need to break policies in order to get their jobs done (see my post on Insider Threat - By the Numbers). And the unknown percentage of employees who break policies without being noticed (or in many cases without even knowing it).

A few days ago, security researcher Ira Winkler articulated one aspect of this very plainly.

Why is there a sudden epidemic of violations of sensitive personal information? The answer is, Because it’s there.

The scenario of an employee viewing sensitive information that they shouldn't be viewing is a fairly common example of real-world insider security breaches. While it won't likely lead to a $7 Billion loss, it could mean a failed audit, bad publicity, lost customers, or other lost business opportunities. In today's transparent business environment, it's only a matter of time before juicy information is made public. State Dept. employees were probably snooping on passport information for years before they found the 2008 presidential candidates. Then, it got out and became a news story.

Winkler goes on to note:

Anyone developing or maintaining information just better accept that their fellow workers will look at information and that they need to track and limit access. More importantly, they better look at their audit logs and specifically search for violations.

I agree. One of the scenarios I often run into is where administrators require access to files (in order to manage access) but they don't require access to the information within those files. A good example is the admin who controls access to HR files and has the ability to open offer letters containing salary and other personal information. To Winkler's point, if the capability is there, they will likely open the files to take a peek. After all, they have been explicitly granted access to those files in order to do their jobs. Doesn't that make it OK? No. And to Winkler's final point, the admin would probably exercise additional restraint if they knew that file access was being monitored.

Know what you're protecting against

You know that advertisement where the CEO (Todd Davis) gives out his social security number and tells you how secure it is because he uses his company's product to protect his identity information? Well, there have been 20 people who used his social security number to get a drivers license. And there was one "guy in Texas who duped an online payday loan operation last year into giving him $500 using Davis' Social Security number".

Today, I read a few articles (including this one and this one) that suggest that LifeLock should be chastised because it doesn't protect you against everything that one might think it should. My first reaction was to agree with the writers. I always knew there was no way for a product to protect your SSN against any or all unwanted uses. And they shouldn't claim it does. And ha ha for Mr. Davis' identity being compromised.

But, then I read Davis' rebuttal, "There's nothing on my actual credit report about uncollected funds, no outstanding tickets or warrants or anything" and I realized that this isn't really a case of a product not doing what it claims to do. It's a case of mis-aligned expectations about what a product can (or should) do.

It reminded me of all the times I've heard that some strong authentication technique isn't effective because it's susceptible to man-in-the-middle techniques. Sure it is, but that's the wrong problem. SSL was developed to solve that problem. There are certainly issues with SSL (mostly around user experience and education about how it works), but strong authentication is not the answer.

In the same way, there are problems with relying on SSN as authentication. And LifeLock won't protect against that. But, if it keeps your credit report clean, then maybe it's doing what it's supposed to. I haven't really followed the ads and I have no idea what the company promises its customers, but I thought I'd use this opportunity to remind you of the old cliche – there is no silver bullet. Analyze your risks and know which types of threats a security solution will be effective at protecting you against.

Correctly aligned expectations yield happy customers.

Low Tech Breach

Probably could've been avoided with simple old manual deprovisioning. Or, even more likely – maybe they were using a shared account to access the system that held customer data.

Oh where
Oh where
Has my private data gone

And of course, this from a few days ago in Oklahoma.

Sometimes I think we assume that everyone in IT is reading the same books, articles and blogs as us. And they're not. Not even close. Whatever they're reading isn't about work.

Unfair treatment for TJX and retailers

Ben Wright left a comment on one of my postings about the Hannaford breach. He pointed to one of his blog entries titled FTC treats TJX Unfairly. Good stuff. Ben obviously understands the legal issues facing retailers much more than I do and rather than just respond to the comment, I thought it fair to put this new post up pointing to his article.

Generally, I focus on technology, so I may be guilty of haphazardly posting things about businesses like:

[Hannaford] only exposed 10% of the number of accounts that TJX did, but it's still 4.2 million accounts.

Ben got me thinking - I was implying that Hannaford is responsible for exposing (active verb) consumer information. I've already mentioned that others have done more than imply that. Even if we grant that Mark's solution would've prevented this particular case, I do see Ben's point. There is a threshold of security above which we may not want to hold retailers responsible. If a retailer is PCI-compliant and still loses consumer information, is it fair to impose massive financial implications? Does that discourage retailers from taking risks and growing their business?

Getting back to technology, Ben points to an article suggesting that the breach occurred by attackers listening in to fiber optic cable. If Hannaford was PCI-Compliant, wouldn't that transmission be encrypted? Bruce Schneier told us how to eavesdrop on fiber optic cable back in September. It sounds relatively simple. Did these attackers also break one of our commonly used encryption algorithms?

I do think it's reasonable to expect companies like TJX to disable or replace their WEP security when it becomes widely known that it's insecure. And for companies that collect credit card info to provide over-the-wire encryption. But, I don't think it's an issue for government to manage. I like that the payment card industry is trying to handle the issue amongst themselves. And if they do it right, supply and demand will result in a secure infrastructure.

One more thing for CEOs to fear

I previously mentioned the Hannaford breach and that it's the CEOs that take the fall, but now I have to add one more thing for CEOs to fear. First, it was potential impact to the bottom line or damage to the company's reputation. Then it was fines by regulators and maybe even jail time. Now, add to the list of potential repercussions of a security breach being called out in Mark MacAuley's blog. And Mark names names. He tried to convince Hannaford to put measures in place to prevent this type of attack . Now, Mark is guessing it was an inside job. The attacker installed software on every server in 300 stores. He's probably right. It's hard enough for system administrators to roll out software on that scale and effectively hit every server (even with a team of consultants). It seems unlikely for someone with no knowledge of the environment to come along and accomplish that goal -- not impossible, but unlikely given that these attacks are most likely targeted at low hanging fruit where the 80/20 rule would apply.

I hope Mark doesn't mind that I'm picking on him. There is an element of seriousness to my comment about the new item on the list of repercussions. There are a variety of convenient ways to publicly call out a CEO or other business leader for lack of movement or poor decisions. You can't hide and wait for something like this to blow over. Not any more. It's time to accept risk management as a top priority – as important as discovering new ways to expand the business. And yes, leakage of customer data should probably be high on the list of risks. No more excuses. No more walls. Lots of transparency. Viva la Clue Train!

UPDATE
Ira Winkler disagrees that it was likely an inside job. I'm sure he's forgotten more about hacking than I ever knew. So, he may be right. I don't doubt that someone could hit 100% of servers, but I guess I didn't see that as the goal. Maybe I'm not in tune with the motivations of hackers.

...this may be the article that Ira refers to.

The C-Level execs take the fall

One more thing re: the State Dept. passport breach. Notice who's in the news taking the heat for the breach – the CEO of the State department. That's exactly what we were told would happen at the Gartner GRC Summit a few weeks ago. It's the C-level executives that take the fall when a high profile breach occurs, which is one of the reasons why governance is vital to the business. And why a correctly done risk analysis should beget executive sponsorship for risk mitigation solutions.

It's really interesting to me that such a seemingly ordinary act has become such a high profile breach. By ordinary act, I mean seemingly non-malicious and only acting with approved rights and privileges. These employees were GIVEN the power to act. They didn't have to TAKE the power through theft or hacking. And that's the risk with privileged users. With them, it's not about security controls. They can simply decide to subvert policy. That's why Dave's post was so timely. You can audit every transaction.

Obama Passport Breached by Insider

This is a great example of one of the most underestimated insider threat scenarios that I would be worried about if I were managing GRC for an organization.

Three employees of the U.S. State Department, who were properly given access rights to passport files, inappropriately used those rights to access details such as Obama's date and place of birth, e-mail address, mailing address, Social Security number, former names and travel plans. Was this a problem about not having the right policies in place? No. A problem with ineffective controls? No. It's simply a problem of a few people choosing to abuse the trust that had been given them – not out of malice, but simple curiosity (most likely).

Luckily, the State Department has computer-monitoring equipment in place that triggered alarms. And each of the three breaches was identified and dealt with. This incident will serve as a pretty strong deterrent for future curious employees who might otherwise be tempted to try the same thing. And (if this wasn't a government agency) the organization would be able to prove to auditors pretty quickly that they're effectively managing the risk associated to the access rights provided to employees and contractors. Because even when there is risk, they're watching and ready to respond.

UPDATE:
Apparently, it was a bipartisan attack.

OK TJX, the spotlight is officially off of you

Or at least we'll have another name to mention in the same sentence. Hannaford Brothers - looks like you're it. Sure, you've only exposed 10% of the number of accounts that TJX did, but it's still 4.2 million accounts. An interesting point was that the account information was stolen during the card authorization process. So, it sounds like network snooping. I guess we'll find out soon enough.

Boeing Data Theft: NetVision Use Case

An Information Week article titled Boeing Employee Charged With Stealing 320,000 Sensitive Files discusses a massive data breach by a Boeing insider. It's another illustration of the fact that the biggest threats for organizations are insiders. The perpetrator (Gerald Lee Eastman) was ready to share Boeing's sensitive information which could cost Boeing as much as $15 billion in damages.

This type of attack is a good use case for NetVision file system monitoring (part of our NVMonitor product). The article explains that Eastman had to exploit a weakness in Boeing's computer system to access the stolen files. Over the course of two years, he methodically searched the Boeing systems looking for unprotected file shares and was routinely denied access to many. As he searched for files and found ways around the file system security mechanisms, NetVision file system monitoring could have caught the behavior and alerted security officers with each attempt. ...nipping this issue in the bud two years ago when it began.