By David Mortman
Today Verizon released their Supplement to the 2009 Data Breach Investigations Report. As with previous reports, it is extremely well written, densely loaded with data, and an absolute must read. The bulk of the report gives significantly more information on the breakdown of attacks, by both how often attacks occurred, and how many records were lost as a result of each attack.
While the above is fascinating, where things got most interesting was in the appendix, which was all about comparing the Verizon data set from 2004 through 2008 to the DataLossDB archives from 2000-2009. One of the big outstanding questions from past Verizon reports was how biased is the Verizon dataset, and thus how well does it reflect the world at large? While there was some overlap with the DataLossDB, their dataset is significantly larger (2,300+ events). Verizon discovered a fairly high level of correlation between the two data sets. (Page 25, Table 4). This is huge, because it allows us to start extrapolating about the world at large and what attacks might look like to other organizations.
The great thing about having so much data is that we can now start to prioritize how we implement controls and processes. Case in point: Table 5 on page 26. We once again see that the vast vast majority (over 70%!) of incidents are from outsiders. This tells us that’s where protection should be focused first. If you go back to the body of the supplement and start looking at the details, you can start to re-evaluate your current program and re-prioritize appropriately.
Posted at Wednesday 9th December 2009 9:23 am
(1) Comments •
By David J. Meier
As you are already well aware (if not, see the announcement – we’ll wait), Google is now offering a free DNS resolver service. Before we get into the players, though, let’s first understand the reasons to use one of these free services.
You’re obviously reading this blog post, and to get here your computer or upstream DNS cache resolved securosis.com to 184.108.40.206 – as long as that works, what’s the big deal? Why change anything?
Most of you are probably reading this on a computer that dynamically obtains its IP address from the network you’re plugged into. It could be at work, home, or a Starbucks filled with entirely too much Christmas junk. Aside from assigning your own network address, whatever router you are connecting to also tells you where to look up addresses, so you can convert securosis.com to the actual IP address of the server. You never have to configuring your DNS resolver, but can rely on whatever the upstream router (or other DHCP server) tells you to use.
For the most part this is fine, but there’s nothing that says the DNS resolver has to be accurate, and if it’s hacked it could be malicious. It might also be slow, unreliable, or vulnerable to certain kinds of attacks. Some resolvers actively mess with your traffic, such as ISPs that return a search pages filled with advertisements whenever you type in a bad address, instead of the expected error.
If you’re on the road, your DNS resolver is normally assigned by whatever network you’re plugged into. At home, it’s your home router, which gets its upstream resolver from your ISP. At work, it’s… work. Work networks are generally safe, but aside from the reliability issues we know that home ISPs and public networks are prime targets for DNS attacks. Thus there are security, reliability, performance, and even privacy advantages to using a trustworthy service.
Each of the more notable free providers cites its own advantages, along the lines of:
- Cache/speed – In this case a large cache should equate to a fast lookup. Since DNS is hierarchical in naturem if the immediate cache you’re asking to resolve a name already has the record you want, there is less wait to get the answer back. Maintaining the relevance and accuracy of this cache is part of what separates a good fast DNS service from, say, the not-very-well-maintained-DNS-service-from-your-ISP. Believe it or not, but depending on your ISP, a faster resolver might noticeably speed up your web browsing.
- Anycast/efficiency – This gets down into the network architecture weeds, but at a high level it means that when I am in Minnesota, traffic I send to a certain special IP address may end up at a server in Chicago, while traffic from Oregon to that same address may go to a server in California instead. Anycast is often used in DNS to provide faster lookups based on geolocation, user density, or any other metrics the network engineers choose, to improve speed and efficiency.
- Security – Since DNS is susceptible to many different attacks, it’s a common attack vector for things like create a denial-of-service on a domain name, or poisoning DNS results so users of a service (domain name) are redirected to a malicious site instead. There are many attacks, but the point is that if a vendor focuses on DNS as a service, they have probably invested more time and effort into protecting it than an ISP who regards DNS as simply a minor cost of doing business.
These are just a few reasons you might want to switch to a dedicated DNS resolver. While there are a bunch of them out there, here are three major services, each offering something slightly different:
- OpenDNS: One of the most full featured DNS resolution services, OpenDNS offers multiple plans to suit your needs – basic is free. The thing that sets OpenDNS apart from the others is their dashboard, from which you can change how the service responds to your networks. This adds flexibility, with the ability to enable and disable features such as content filtering, phishing/botnet/malware protection, reporting, logging, and personalized shortcuts. This enables DNS to serve as a security feature, as the resolver can redirect you someplace safe if you enter the wrong address; you can also filter content in different categories. The one thing that OpenDNS often gets a bad rap for, however, is DNS redirection on non-existent domains. Like many ISPs, OpenDNS treats every failed lookup as an opportunity to redirect you to a search page with advertisements. Since many other applications (Twitter clients, Skype, VPN, online gaming, etc…) use DNS, if you are using OpenDNS with the standard configuration you could potentially leak login credentials to the network, as a bad request will fail to get back a standard
NXDOMAIN response. This can result in sending authentication credentials to OpenDNS, as your confused client software sees the response as a successful
NOERROR and proceeds, rather than aborting as it would if it got back the ‘proper’
NXDOMAIN. You can disable this behavior, but doing so forfeits some of the advertised features that rely on it. OpenDNS is a great option for home users who want all the free security protection they can get, as well as for organizations interested in outsourcing DNS security and gaining a level of control and insight that might otherwise be available only through on-site hardware. Until your kid figures out how to set up their own DNS, you can use it to keep them from visiting porn sites. Not that your kid would ever do that.
- DNSResolvers: A simple no-frills DNS resolution service. All they do is resolve addresses – no filtering, redirection, or other games. This straight up DNS resolution service also won’t filter for security (phishing/botnet/malware). DNSResolvers is a great fast service for people who want well-maintained resolvers and are handling security themselves. DNSResolvers effectively serves as an ad demonstrating the competence and usefulness of parent company easyDNS), by providing a great free DNS service, which encourages some users to consider easyDNS’ billable DNS services. (Full disclosure: we pay for some of easyDNS’s commercial services).
- Google Public DNS: Almost functionally identical to DNSResolvers, Google’s standards-compliant DNS resolution service offers no blocking, filtering, or redirection. They emphasize their active resolver cache, which helps with request lookup speeds; this may be an advantage in comparison to with DNSResolvers. Your mileage may vary, however, depending on your own location and ISP.
Not surprisingly, all the people I randomly talked to about Google DNS had the same initial reactions: “Google already has enough of my information.” and “Yeah, right! Like they’re not going to correlate it to other services I use.” None of those people had actually read the privacy statement which is short and to the point. As of this writing, Google keeps DNS information private, and does not correlate it with your other Google activities.
So why is this something that Google feels is worth the time and expense? The trivial answer is monetary. But most services Google offers are visual, at some level, and thus advertising makes sense. However with DNS and Google’s stance (remember they promise not going to meddle, and to remain standards compliant) they’re not in a position to provide anything visually. This probably means Google is trying to position itself for something which might allow them to create a revenue stream: DNSSEC. It may be a stretch now, but depending on how DNSSEC plays out, there could be opportunity for providing secure DNS services which could very well roll back into something like Google Apps – think key management, generation, and rotation services. This also gives them an incredible source of information – every single website anyone using the service is visiting. Even without any identifying information, such data is incredibly useful – especially combined with all their advertising and indexing data. Ka-ching.
Back to our main point, though: external DNS resolvers and you. The first three bullets above are generally sufficient reason not to use your ISP’s DNS service, but add to that the fact that most ISPs today are trying to monetize your typos when typing domain names (Comcast, for example, has a service called “Domain Helper” in which they oh-so-helpfully enrolled their all subscribers in last August). Additionally, ISP resolvers are generally behind the curve on security updates compared to dedicated services. This really became apparent when Dan Kaminsky was exposing serious DNS flaws. DNS is an essential component of Internet service, and a good place to improve security through separation of duties – in addition to the potential performance benefits. Personally I feel it’s a good thing that Google is starting to play in this space, as it raises the bar for their competitors, and draws more attention to the possibilities.
Changing your service is easy. On your computer or home router, in your network configuration there’s a setting for DNS. Each DNS resolver service provide two IP addresses (primary and secondary) and you can simply enter these manually. Any computer behind a home router uses the DNS resolvers it specifies, unless you manually override them on the computer. Don’t forget that if you have a laptop, even if you set a new DNS resolver on your home router, you will also want to set it directly on the laptop for when you connect to other networks.
Better security, speed, and reliability. What more could you ask for?
–David J. Meier
Posted at Tuesday 8th December 2009 9:22 pm
(5) Comments •
One of the more difficult aspects of medical research is correlating treatments/actions with outcomes. This is a core principle of science based medicine (if you’ve never worked in the medical field, you might be shocked at the lack of science at the practitioner level).
When performing medical studies the results aren’t always clean cut. There are practical and ethical limits to how certain studies can be performed, and organisms like people are so complex, living in an uncontrolled environment, that results are rarely cut and dried. Three categories of studies are:
- Pre-clinical/biological: lab research on cells, animals, or other subsystems to test the basic science. For example, exposing a single cell to a drug to assess the response.
- Experimental/clinical: a broad classification for studies where treatments are tested on patients with control groups, specific monitoring criteria, and attempts to control and monitor for environmental effects. The classic double blind study is an example.
- Observational studies: observing, without testing specific treatments. For example, observational studies show that autism rates have not increased over time by measuring autism rates of different age groups using a single diagnostic criteria. With rates holding steady at 1% for all living age groups, the conclusion is that while there is a perception of increasing autism, at most it’s an increase in diagnosis rates, likely due to greater awareness and testing for autism.
No single class of study is typically definitive, so much of medicine is based on correlating multiple studies to draw conclusions. A drug that works in the lab might not work in a clinical study, or one showing positive results in a clinical study might fail to show desired long-term outcomes.
For example, the press was recently full of stories that the latest research showed little to no improvement in long-term patent outcomes due to routine mammograms for patients without risk factors before the age of 50. When studies focus on the effectiveness of mammograms detecting early tumors, they show positive results. But these results do not correlate with improvements in long-term patient outcomes.
Touchy stuff, but there are many studies all over medicine and other areas of science where positive research results don’t necessarily correlate with positive outcomes.
We face the same situation with security, and the recent debate over password rotation highlights (see a post here at Securosis, Russell Thomas’s more-detailed analysis, and Pete Lindstrom’s take).
Read through the comments and you will see that we have good tools to measure how easy or hard it is to crack a password based on how it was encrypted/hashed, length, use of dictionary words, and so on, but none of those necessarily predict or correlate with outcomes. None of that research answers the question, “How often does 90 day password rotation prevent an incident, or in what percentage of incidents did lack of password rotation lead to exploitation?” Technically, even those questions don’t relate to outcomes, since we aren’t assessing the damage associated with the exploitation (due to the lack of password rotation), which is what we’d all really like to know.
When evaluating security, I think wherever possible we should focus on correlating, to the best of our ability, security controls with outcomes. Studies like the Verizon Data Breach Report are starting to improve our ability to draw these conclusions and make more informed risk assessments.
This isn’t one of those “you’re doing it wrong” posts. I believe that we have generally lacked the right data to take this approach, but that’s quickly changing, and we should take full advantage of the opportunity.
Posted at Tuesday 8th December 2009 11:16 am
(7) Comments •
On Friday I asked a simple question over Twitter and then let myself get dragged into a rat-hole of a debate that had people pulling out popcorn and checking the latest odds in Vegas. (Not the odds on who would win – that was clear – but rather on the potential for real bloodshed).
And while the debate strayed from my original question, it highlighted a major problem we often have in the security industry (and probably the rest of life, but I’m not qualified to talk about that).
A common logical fallacy is to assume that a possibility is a probability. That because something can happen, it will happen. It’s as if we tend to forget that the likelihood something will happen (under the circumstances in question) is essential to the risk equation – be it quantitative, qualitative, or whatever.
Throughout the security industry we continually burn our intellectual capital by emphasizing low-probability events.
“Mac malware might happen so all Mac users should buy antivirus or they’re smug and complacent”. Forgetting the fact that the odds of an average Mac user being infected by any type of malware are so low as to be unmeasurable, and lower than their system breaking due to problems with AV software. Sure, it might change. It will probably change; but we can’t predict that with any certainty and until then our response should match the actual (current) risk.
Bluetooth attacks are another example. Possible? Sure. Probable? Not unless you’re at a security or hacker conference.
There are times, especially during scenario planning, to assume that anything that can happen will happen. But when designing your actual security we can’t equate all threats.
Possible isn’t probable. The mere possibility of something is rarely a good reason to make a security investment.
Posted at Monday 7th December 2009 2:32 pm
(21) Comments •
By David Mortman
My Friday post generated some great discussion in the comments. I encourage you to go back and read through them. Rocky in particular wrote an extended comment that should be a blog post in itself which reveals that he and I are, in fact, in violent agreement on the issues. Case in point, his first paragraph:
I think we’re on the same page. As an industry we need to communicate more clearly. It wasn’t my intent to fault any information professionals as much as I’m hoping that we all will push a bit harder for
the right conversations in the future. We can’t just let the business make poor decisions anymore, we need to learn their language and engage them in more meaningful dialogue. We’re yelling in the
wrong language. We just need to put that effort into learning their language and communicating more effectively. How is it that we can read HEX in real time but can’t converse with a MBA at any time?
Read the last sentence again. It is that important. This is something I’ve been fighting for for a long time. It’s not about bits and bytes and until we get that through our heads, the rest just doesn’t matter because no one in command will listen to us.
Rocky closed out his comment with this though:
What would IT security look like if we spent as much time on those thoughts as we do on compliance tools, dashboards and monitoring?
I think it’d be much more business centric and hopefully significantly more respected in the C-suite. What do you think?
Posted at Monday 7th December 2009 12:41 pm
(8) Comments •
By David Mortman
Rocky DeStefano had a great post today on FudSec, Liberate Yourself: Change The Game To Suit Your Needs, which you should read if you haven’t already. It nicely highlights many of the issues going on in the industry today. However, I just can’t agree with all of his assertions. In particular, he had two statements that really bothered me.
Information Security Leadership. We need to start pushing back at all levels here. It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally
secure - or if you prefer having better visibility into real risk. Risk to the mission, risk to the business not the risk to an asset. We continue to create irrelevant measurements - irrelevant because they
are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary.
In a perfect, security and risk oriented world, I would agree with this 100%. The problem is, that from the business perspective, what they have in place is usually sufficient to do what they need to do safely. I’m a big fan of using risk, because it’s the language that the business uses, but this isn’t really a compliance versus security vs risk issue. What needs to be communicated more effectively is what compliance to the letter of the law does and doesn’t get you. Where we have failed as practitioners is in making this distinction and allowing vendor and marketing BS to convince business folks that because they are compliant they are of course secure. I can’t count the number of times I’ve had folks tell me that they thought being compliant with whatever regulation meant they were secure. Why? Because that’s the bill of sale they were sold. And until we can change this basic perception the rest seems irrelevant. Don’t blame the security practitioners; most of the ones I know clearly express the difference between compliance and security, but it often falls on deaf ears.
But what really got my goat was this next section:
As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives? We sold our souls because we lacked the knowledge of the
business and how to apply what we do in a meaningful way to the business. We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for
the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting
our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim?
I don’t know who Rocky has been talking to, but I don’t know a single security practitioner who thinks that compliance was the way to go. What I’ve seen are two general schools of thought. One is to rant and rave that everyone is doing it wrong and that compliance doesn’t equal security, but then engages in the compliance efforts because they have no choice. The other school is to be pragmatic and to accept that compliance is here to stay, and do our best within the existing framework. It’s not like we as an industry ‘let’ compliance happen. Even the small group of folks who have managed to communicate well with the business, be proactive, and build a mature program still have to deal with compliance. As for Rocky’s “buildng codes” and “point in time” snapshots, for a huge segment of the business world, this is a massive step up from what they had before.
But to answer Rocky’s question, the failure here is that we told the business, repeatedly, that if they installed this one silver bullet (firewalls, AV, IDS, and let’s not forget PKI) they’d be secure. And you know what? They believed us, every single time, they shelled out the bucks and we came back for more, like Bullwinkle the Moose “This time for sure!” We told them the sky was going to fall and it didn’t. We FUDed our way around the business, we were arrogant and we were wrong. This wasn’t about selling our souls to compliance. It was about getting our asses handed to us because we were too busy promoting “the right way to do things” and telling the business no rather then trying to enable them to achieve their goals.
Want an example? Show me any reasonable evidence that changing all your users’ passwords every 90 days reduces your risk of being exploited. No wonder they don’t always listen to us.
Posted at Friday 4th December 2009 11:50 am
(39) Comments •
By Adrian Lane
Jaikumar Vijayam has posted an article at ComputerWorld regarding the Express Scripts Data Breach class action suit. This is the case where, in 2008, Express Scripts received a letter demanding money from the company under the threat of exposing records of millions of patients. The letter included personal information on people covered by Express Scripts, including birth dates, Social Security numbers and prescription information. Many of the insured were seeking damages, and the judge has thrown the case out citing lack of evidence.
Without any actual harm being done, there can be no damages sought.
To me, this means that privacy is worthless.
“Abstract injury is not enough to demonstrate injury-infact,” Judge Buckles wrote. “The injury or threat of injury must be concrete and particularized, actual and imminent; not conjectural or hypothetical.”
“Plaintiff alleges that he would be injured “if” his personal information was compromised, and “if” such information was obtained by an unauthorized third party, and “if” his identity was stolen as a result, and “if” the use of his stolen identity caused him harm.” These multiple “if’s” put his claims in the realm of the hypothetical, Judge Buckles noted.
I get the argument. And I get that laws don’t protect our feelings. But Express Scripts has been entrusted with the data, and they earn revenue from having this data, which means they inherit the custodial responsibility for the security and privacy of that information. Not being able to quantify damages should not be considered the same as not being damaged. Should the burden of proof on this point fall on the person who had their information stolen?
Considered in light of credit card processors, health insurers, 3rd party service providers, and law enforcement not sharing information about breach specifics, it will be neigh on impossible for average citizens to gather information necessary to demonstrate the chain of events that led to damages. Damages and costs come in many forms, most of which are not fully quantifiable, so it becomes a quagmire. This sets a bad precedent, IMO, and does not promote or incentivize companies to secure data. When it gets bad enough, consumers will push for legislation to curb the behavior, and we have seen how that works out.
Posted at Friday 4th December 2009 9:55 am
(3) Comments •
I had one of those weird moments today where I found an unrelated part of my life unexpectedly influenced by my martial arts background.
I was asked to critique a research paper by someone I haven’t worked with before. Without going into details, this particular paper had a fatal flaw.
It opened with a negative position, then attempted to justify the positive. It started defensively, and in the process lent credence to the opposing view, as opposed to strengthening the author’s position. In other words, it started with, “here’s what you say about X, and why I think Y” as opposed to, “here is position Y, and why it is correct and X is wrong”.
In advising the author, I remembered a lesson I learned when I first started teaching martial arts (traditional taekwondo). I was giving a class on unarmed restraint techniques, which adapted some experiences in physical security to martial arts. They’re similar to police restraint techniques, but adjusted for not having a firearm (police techniques involve protecting the firearm so the bad guy can’t grab it while being restrained) or handcuffs. In the class were two of my instructors, helping me learn to teach. I started by saying something like, “I’m no expert”, and one of them walked off right then and there.
At a break he came back and asked if I knew why he had left. He told me to never start a lesson or debate by disqualifying myself as an authority. I essentially told the class they shouldn’t listen to me, because I didn’t know what the frack I was talking about. Self-deprecating humor, applied appropriately, is fine – but never start from a position of weakness. I was trying to be humble, but instead destroyed any reason someone would want to learn from me.
Over time I expanded this lesson to “Never start with a negative when your goal is to prove a positive.” Essentially, that places the opposing view ahead of yours and forces you into a defensive position. If I’m writing research to show the value of DLP, I sure as heck better not start it with all the criticisms against DLP.
It’s kind of like a fight. If you allow the opponent to control the ring and dictate the pace, your odds of winning are much lower. You can never win on defense alone.
One important corollary is that you also shouldn’t expect someone to agree with your position based on your credentials alone. I get seriously annoyed by other analysts/pundits who make pronouncements, yet never back them with evidence. Start from a position of strength (assuming you are the expert), but also lead the reader, with evidence and logic, to reach your conclusions for themselves.
Most black belts are crappy martial artists and teachers… if their techniques suck, find another one. Respect still needs to be earned.
Enough with the preachy stuff…
On to the Summary:
Webcasts, Podcasts, Outside Writing, and Conferences
Favorite Securosis Posts
Other Securosis Posts
Project Quant for Databases:
Favorite Outside Posts
Top News and Posts
Blog Comment of the Week
This week’s best comment comes from David in response to Quick Thoughts on the Point of Sale Security Fail Lawsuit (there were a TON of good comments in this thread, including some from Anton Chuvakin):
With the Radiant POS Lawsuit one wonders if a Micros POS suit will follow? As a QIRA forensics investigator, I saw a 10 to 1 compromise rate of Micros over Radiant systems. Micros REM had such bad stretch of PCI failures.
Posted at Thursday 3rd December 2009 10:31 pm
(1) Comments •
By Adrian LaneRich
In our last post on Project Quant for Database Security Metrics, we started to examine Planning. To finish Planning, we need to address access controls, database monitoring, and data classification strategies. Once again, we are following the pattern of determining requirements, determining how the requirements apply to the business, figuring out how to accomplish the goals, and then documenting intentions. We will list the specific metrics later in this series, but at this stage research time will be the biggest cost.
- Define Requirements: What are the access control guidelines? Determine which business functions are being supported, which systems support those functions, who needs access to the system, and what facilities they are allowed to use. For administrative roles, determine what tasks are performed. Identify additional security and compliance requirements.
- Define Groups, Roles, & Ownership: Based upon requirements, develop roles and groups to support business functions and enforce security constraints. Determine object and data ownership and formulate a permissions model for the database, schemas, and tables. Plan how users will obtain permissions, revocation, and use cases not accounted for in the model. Identify service account usage.
- Define Implementation: Database permissions are established within the database, and externally from the database. Define which facilities are responsible for policy enforcement. Define method for verification of policy. Remember, this is a strategic planning exercise; don’t get too bogged down in the details.
- Document: Document requirements. Clarify database use models from administration. Train administrative staff on policy.
Remember that this is the planning stage, and is either focused on general requirements (policies for administrator accounts), or planning for a specific database. For existing systems, we’ll document their current AAA configurations in later phases.
Database monitoring verifies database usage. It provides near-real-time analytics to detect usage violations, usage profiling, and anomaly detection. While secure configuration serves as a preventative control; monitoring is detective, and used to verify the database is being used as intended. Think of it as similar to having black and white lists for database transactions. But to build those lists, you need an idea of what you wish to accomplish, or what activities should never occur. As every database is used differently, you have to define what is appropriate and what isn’t. Identify events you are interested in, then define acceptable behaviors and outcomes.
- Define Activities: Investigate business processes. Define critical operations and functions. What activities does the system support, and what subset are you interested in monitoring. Identify security and compliance in relation to data privacy, fraud detection, and system misuse.
- Define Violations: Determine which events indicate problems. Consider users, time of day, function, data volume, and other available attributes that can identify suspect transactions. Identify criticality of events and specify desired response. Consider periodic review of general database usage in order to refine policy.
- Identify Event Collection: How will you capture events? Determine what event collections are available. Map policies to event collection for misuse detection.
- Define Event Notifications: When a policy violation is discovered, how will you react? Specify how event notification will happen and who will be responsible.
- Document: Ensure all concerned parties are aware of their responsibilities and coordination points with other groups.
Data classification for databases is a necessary step for many compliance and data privacy regulations. In a practical sense, it often devolves into a giant data labeling or classification project that wastes time and effort. You will need to investigate requirements and best practices, but we recommend that you avoid using an overly detailed model that nobody will actually use. Figure out what needs to be secure, but be general and pragmatic your data security approach.
- Identify Requirements: What is your high level scheme? What is considered sensitive, and how will you define it?
- Specify Data Security: What will you do with sensitive information? Formalize intent and security levels for the different data types, and different audiences for the information.
- Select Access Method: What is your classification model? Siloed, hierarchical, and labeling are all options.
- Map to AAA: How will your access control system implement the data security model. Based upon the security model, map access controls to systems capabilities. This step comes after access control review, but iterative adjustments to the plan are common. These models are implemented on top of access controls, but in some cases underlying data features such as labeling support more granular control.
- Document: Data classification affects usage, requiring education of users, IT, and application developers.
Keep in mind that this is all strategic planning. At this stage of analysis you will not be examining specific statements or policies. During this planning, there is a tendency to begin delving into implementation specifics that are simply not helpful at this stage. Focus on the big picture: how data moves and is used within the organization. This series will delve into the specific later.
Posted at Wednesday 2nd December 2009 11:19 am
(1) Comments •
We hate that we have to moderate comments, but the spammers are relentless and there’s no way we’ll let those jerks ruin our site.
I realized I can disable moderation on a per-account basis without having to give you editing or moderation rights. All you have to do is register with the site, and drop us an email with your username at firstname.lastname@example.org. We’ll add you to our super secret group, and you can login and skip all that moderation silliness.
A few of you comment on the blog pretty regularly, and we hate that we have to review everything first and slow the discussion down. Hopefully this will help ease the problem.
Posted at Tuesday 1st December 2009 5:51 pm
(0) Comments •
By Adrian Lane
I spent about 8 hours on the phone yesterday discussing the Guardium acquisition with press, analysts, security vendors, and former associates in the Database Activity Monitoring space. The breadth of questions was surprising, even from people who work with these products – enough that I thought we should do a quick recap for those who have questions. First, for those of you looking for a really quick overview of Database Activity Monitoring, I just completed an introductory series for Dark Reading on The ABCs of DAM and What DAM Does. Here are some specific questions I have gotten pertaining to the acquisition, in no particular order:
- What does this mean for the remaining DAM vendors? It means lots of good things. It means that a major firm has placed a big bet on Database Activity Monitoring, spotlighting the technology in a such way that a wider set of customers and competitors will be paying attention to this technology. That means more press coverage. But most importantly it means IBM will now advocate the suitability of DAM for compliance. Additionally, the remaining DAM players will be furiously tuning their marketing materials to show competitive differentiation.
- What did IBM want to accomplish and how will the software group roll this out? and What does this say about IBM’s security strategy? These are great questions and will require a more in-depth examination of IBM’s security strategy. I will tackle this in a future post.
- Is this justification for DAM as a compliance platform? Yes it is. IBM provides validation in a way that companies like Fortinet and Netezza simply cannot. DAM has never had a single “must have”, killer application, and may never. But with thousands of Global Services personnel trained on this technology and out educating customers on how it helps with security, operations management, and compliance; I expect a big uptick in acceptance.
- How does this fit with existing IBM products? Great, poorly, and both. Philosophically, it’s a great fit. IBM has a handful of auditing technologies for every one of their database platforms, and they have the SIM/Log Management platform from the Consul acquisition, so there are some complimentary pieces to DAM. In many ways, DAM can be used as a generic database event collection and analysis engine. It can fit a lot of different purposes from real time security analytics to detailed forensic analysis. On a more practical level this is a poor fit. The Guardium product is not on an IBM stack (Websphere, DB2, Tivoli, etc). IBM really needs a comprehensive vulnerability assessment product to fill in compliance gaps even more than it needed DAM. This is one of the reasons many felt Application Security Inc. would have been a better fit. And despite what was said at the press launch, Guardium is still viewed as a hardware firm, not a software vendor. I am going to get hate mail on these last two points, but I have spoken with enough customers who share this perspective that IBM has more to worry about than my opinions.
- Does the mainframe database security market needs a facelift? OK, no one really asked this specific question, but was behind several different questions on DB2 security. Mainframe database security is old school: Access controls (ACF2, RACF, Top Secret), small numbers of administrators with SOD, use of tailored audit trails and physical isolation. Encryption to secure backup media is fairly common. While the use cases for mainframes continue to grow as companies look to leverage their investments, the security model has changed very little in the last 10 years. Monitoring provides the capability to verify usage, near-real-time analysis and non-database event collection. These all advance the state of mainframe DB security.
- Is this an internally-facing deal to serve existing customers or is there a genuine security global strategy? It’s a little of both. I do not believe what was said in the press call: that this is all about heterogenous database security. They have it and they will use it, but the focus will be on existing IBM customers. IBM Global Services will absolutely want support for every database environment they can get because their customers have everything, but the rest of IBM will want mainframe support first and foremost. I know firsthand that there were many in IBM pushing for iSeries-AS/400 support, and a smattering who wanted Informix capabilities as well. I imagine for the time being they will continue with the current support matrix, provide deeper and more seamless mainframe monitoring, and then service the squeakiest of the wheels. I am not exactly sure which that will be, but believe the first efforts are introspective.
- Does this mean that DAM is mature? DAM products have been reasonably mature for a while now. Once the vendors fixed their gawd-awful UI, had appropriate compliance and security policy bundles, and offered multiple data collection and deployment models, it became a mature product space. Visibility and a must-have use case have been elusive; so DAM has not gained the same kind of traction as DLP, email, and web security.
- Who is going to be bought next? Probably the most common question I got and, really, I don’t know. You tell me who the interested buyer is and I can tell you who the best fit would be and why. But as [shameless promotion] product and market analysis is how I make my living [/shameless promotion], I am not sharing that information unless you are serious.
Posted at Tuesday 1st December 2009 2:48 pm
(1) Comments •
Let the games begin.
It seems that Radiant Systems, a point of sale terminal company, and Computer World, the company that sold and maintained the Radiant system, are in a bit of a pickle. Seven restaurants are suing them for producing insecure systems that led to security breaches, which led to fines for the breached companies, chargebacks, card replacement costs, and investigative costs. These are real costs, people, none of that silly “lost business and reputation” garbage.
The credit card companies forced him to hire a forensic team to investigate the breach, which cost him $19,000. Visa then fined his business $5,000 after the forensic investigators found that the Radiant Aloha system was non-compliant. MasterCard levied a $100,000 fine against his restaurant, but opted to waive the fine, due to the circumstances.
Then the chargebacks started arriving. Bond says the thieves racked up $30,000 on 19 card accounts. He had to pay $20,000 and managed to get the remainder dropped. In total, the breach has cost him about $50,000, and he says his fellow plaintiffs have borne similar costs.
The breaches seemed to result from two failures – one by Radiant (who makes the system), and one by Computer World (who installed and maintained it).
- The Radiant system stored magnetic track data unencrypted, a violation of PCI standards.
- Computer World enabled remote access for the system (the control server on premise) using a default username and password.
While I’ve railed against PCI at times, this is an example of how the system can work. By defining a baseline that can be used in civil cases, it really does force the PoS vendors to improve security. This is peripheral to the intent and function of PCI, but beneficial nonetheless. This case also highlights how these issues can affect smaller businesses. If you read the source article, you can feel the anger of the merchants at the system and costs thrust on them by the card companies. Keep in mind, they are already pissed since they have to pay 2-5% on every transaction so you can get your airline miles, fake diamond bracelets, and cheap gift cards.
The quote from the vendor is priceless, and if the accusations in the lawsuit are even close to accurate, totally baseless:
“What we can say is that Radiant takes data security very seriously and that our products are among the most secure in the industry,” Paul Langenbahn, president of Radiant’s hospitality division, told the Atlanta Journal-Constitution. “We believe the allegations against Radiant are without merit, and we intend to vigorously defend ourselves.”
Maybe they can go join a certain ex-governor from Illinois on the next season of The Celebrity Apprentice, since they are reading from the same playbook.
There are a few lessons in this situation:
- The lines have moved, and PCI now affects civil liability and government regulation.
- PCI compliance, and Internet-based cardholder security, now affect even small merchants, even those without an Internet presence.
- We have a growing body of direct loss measurements (time to revise my Data Breach Costs model).
- We are seeing product liability in action… by the courts, not legislation.
- As with many other breaches, following the most basic security principles could have prevented these.
I think this last quote sums up the merchant side perfectly:
“Radiant just basically hung us out to dry,” he says. “It’s quite obvious to me that they’re at fault… . When you buy a system for $20,000, you feel like you’re getting a state-of-the-art sytem. Then three to four months after I bought the sytem I’m hacked into.”
Posted at Tuesday 1st December 2009 11:37 am
(24) Comments •
I’ve been working with the Cloud Security Alliance on the next revision of their official Security Guidance document, and we decided to include a short note on risk in the beginning, to help add some context. Although we are deep in the editorial process, I realized this is the sort of thing I should put out for some public comment, as it’s at the beginning of the document and will help frame how it’s read.
With so many different cloud deployment options – including SaaS vs. PaaS vs. IaaS, public vs. private, internal vs. external, and various hybrid scenarios – no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk-based approach to moving to the cloud and selecting security options. The following is a simple framework to help evaluate initial cloud risks and inform security decisions.
This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick mechanism for evaluating your tolerance for moving an asset to various different cloud computing models. There is a full section on risk management in the Guidance, and I’m also working on a data security specific post to mesh with the other cloud data security content I’m developing.
Identify the asset for the cloud deployment
At the simplest, assets supported by the cloud fall into two general buckets:
We are either moving information into the cloud, or transactions/processing (from partial functions, all the way up to full applications).
With cloud computing our data and applications don’t need to reside in the same location, and we can even shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service.
The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud, to account for scope creep. Data and transaction volumes are often higher than expected, and cloud deployments often scale higher than anticipated.
Evaluate the asset
The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is.
For each asset, ask the following questions:
- How would we be harmed if the asset became public and widely distributed?
- How would we be harmed if an employee of our cloud provider accessed the asset?
- How would we be harmed if the process or function was manipulated by an outsider?
- How would we be harmed if the process or function failed to provide expected results?
- How would we be harmed if the information/data was unexpectedly changed?
- How would we be harmed if the asset was unavailable for a period of time?
Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how those are affected if all or part of the asset is handled in the cloud. It’s very similar to assessing a potential outsourcing project, except that with cloud computing we also have a wider array of deployment options including internal models.
Map the asset to potential cloud deployment models
Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models – private, public, community, or hybrid and internal vs. external options.
For the asset, determine if you are willing to accept the following options:
- Private, internal/on-premises.
- Private, external (including dedicated or shared infrastructure).
- Community; taking into account the hosting location, service provider, and identification of other community members.
- Hybrid. To effectively evaluate a potential hybrid deployment, you must to have at least a rough architecture of where components, functions, and data will reside.
At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations best fit your security and risk requirements.
Evaluate potential cloud service models
In this step focus on the degree of control you’ll have at each SPI tier (Software, Platform, or Infrastructure as a Service) to implement any required risk management. If you are evaluating a specific offering, at this point you might switch to a fuller risk assessment.
Your focus will be on the degree of control you have to implement risk mitigations in the different SPI tiers. If you already have specific requirements (e.g., for handling of PCI regulated data) you can include them in the evaluation.
Sketch the potential data flow
If you are evaluating a specific deployment option, map out the data flow between your organization, the cloud service, and any customers/other nodes. While most of these steps have been high-level, before making a final decision it’s absolutely essential to understand whether, and how, data can move in and out of the cloud.
If you have yet to decide on a particular offering, you’ll want to sketch out the rough data flow for any options on your acceptable list. This is to insure that as you make final decisions, you’ll be able to identify risk exposure points.
You should now understand the importance of what you are considering moving to the cloud, your risk tolerance (at least at a high level), and which combinations of deployment and service models are acceptable. You’ll also have a rough idea of potential exposure points for sensitive information and operations.
These together should give you sufficient context to evaluate any other security controls. For low-value assets you don’t need the same level of security controls and can skip many of the recommendations – such as on-site inspections, discoverability, and complex encryption schemes. A high-value regulated asset might entail audit and data retention requirements. For another high-value asset not subject to regulatory restrictions, you might focus more on technical security controls.
Not all cloud deployments need every possible security and risk control. Spending a little time up front evaluating your risk tolerance and potential exposures will provide the context you need to pick and choose the best options for your organization and deployment.
Posted at Tuesday 1st December 2009 10:49 am
(1) Comments •
By David J. Meier
Let’s try this again. Obviously I didn’t do a very good job of defining what ‘clientless’ means, creating some confusion. In part, this is because there’s a lot of documentation that confuses ‘thin client’ with ‘clientless’. Cisco actually has a good set of definitions, but in case you don’t want to click through I’ll just reiterate them (with a little added detail):
- Clientless: All traffic goes through a standard browser SSL session – essentially, a simple proxy for web browsing. A remote client needs only an SSL-enabled web browser to access http – or https web servers on the corporate LAN (or the outside Internet, which is part of the problem we’re talking about).
- Thin Client: Users must download a small, Java applet for secure access to TCP applications that use static port numbers. UDP is not supported. The client can add security features, and allows tunneling of non-web traffic, such as allowing Outlook to connect to an Exchange server. [Other vendors also use ActiveX.]
- Client: The SSL VPN client downloads a small client to the remote workstation and allows full, secure access to all the resources on the internal corporate network. It’s a VPN that tunnels all traffic over SSL, as opposed to IPSec or older alternatives.
OK, so these definitions are a bit Cisco specific, but they do a good job. By “clientless” we’re stating no Java or ActiveX is in play here. This is key, because both the thin and full client models are immune to the flaw described in the US-CERT VU. The vulnerability is only when using a real, completely clientless, SSL VPN through the browser.
Speaking of the CERT VU, I think everyone can agree that it was poorly written. There are vendors in there who have never provided any sort of clientless SSL VPN (i.e., glorified proxy) functionality, so it’s better not to use that list even though most are marked as “Unknown”.
At this point if you’ve identified a true clientless SSL VPN in your environment, and are wondering how to mitigate the threat as much as possible, the best thing you can do is to make sure that the device only allows access to specified networks and domains. The more access end users have to external sites, the wider the window of opportunity is open for exploit. That being said, it is still generally a bad idea to use clientless VPNs on public networks, since they always provide a lower barrier against attacks can be provided in a (thin or full) VPN client, especially in light of all the threats to DNS in such an environment. It’s not hard to mess with a user’s DNS on an open (or hostile) network, or perform other man-in-the-middle attacks.
Clientless SSL VPNs are ultimately very fancy proxies, and should be carefully in tightly controlled environments. In situations where full control or public access is required there are far more secure solutions, including client-based SSL VPNs (OpenVPN, etc…) and IPsec options.
–David J. Meier
Posted at Tuesday 1st December 2009 10:44 am
(1) Comments •
By David J. Meier
Good job! You paid tens of thousands of dollars for that shiny new name-brand VPN, and then decided to deploy its web VPN functionality because, well, it was just easier than deploying software clients.
What does this mean for you? If your implementation allows dynamic URL rewriting (i.e., end users can put in any URL and have the web VPN fetch it) it’s GAME OVER, since every website a user views through that service appears to come from the same domain – your trusted VPN server. This is worst-case, but there are many other scenarios where an attacker could set up shop to exploit the session, especially if the end user is on a public network where DNS is compromised. There are a bunch of ways to exploit this, especially in multi-step attacks when the bad guy can get on the internal network (easy enough with malware). Don’t be surprised if this shows up in BeEF (a comprehensive tool for exploiting browser vulnerabilities) soon.
Friends don’t let friends connect clientless – fix it the right way. Read the US-CERT vulnerability note for more detailed information. You can mitigate many of the potential problems by only authorizing the SSL VPN to manage traffic for trusted domains, and avoid tunneling to random destinations. If it’s a full SSL VPN product with a re-browsing feature, turn that capability off!
Oh, not to add to the confusion, but Sun’s JRE is also recently vulnerable to same origin policy violations as well.
–David J. Meier
Posted at Monday 30th November 2009 8:01 pm
(12) Comments •