Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

Almost as bad as the Sprint PCS password reset fiasco that made the news in April, here is the Yahoo Mail password reset screen:

As you can see, you need to know the user’s birthday, country of residence, and postal code. Not difficult information to dig up in Palin’s case, as shown here. After you enter this information correctly, you are asked to type in the alternate e-mail address that’s associated with the account. But they give you hints — so if your alternate e-mail was sarah@alaska.gov, they would show you s****@a*****.gov.

Assuming you guess the alternate e-mail correctly, Yahoo mails a password reset link to that address. So it’s likely that the attacker may have also had to gain access to her alternate e-mail account. Either that, or they exploited a vulnerability in the Yahoo password reset mechanism itself, which seems less likely but not implausible.

So Yahoo itself probably didn’t get hacked, per se, even though there will probably be a lot of FUD in the media about that.

"consumers hate tokens."

"Everyone wants to be the single federation platform for everyone else."

"Federation will never work. It won’t work because the single most important consumer Web applications in the world are scared of it. Banks hate the concept because it becomes a weakest link in the chain problem."

"Tokens don’t actually solve most security problems, like man-in-the-middle, phishing, and keystroke-logging malware."

"Oh yes, and finally, consumers are going to have to carry around 13 of them just to make sure they can log into whatever they need to log into since no one will federate."

"Global federation is nowhere near a solid concept in the consumer space, despite what the vendors will try to sell you."

"This is a long term problem. If you work on it and make any progress against it, you'll find yourself much smarter at the far end, than you were at the near end.

When I was in Norway about 5 years ago, I was there very close to the summer solstice. I was wandering around town at 2 o'clock in the morning and there was plenty of light out. You come to a sign that says New Minsk about 60 km and it points south.

And I ask the lady "what country is this?"

She scratched her head for a bit, and said "well I think its Norway"

I said "well who plows the roads?"

"well Norway does, but he have to pay them."

There is a triple boundary in this town that I was in between Norway, Finland and Russia.

But what I did there, was, I had a card about wallet size, I stuck it into a machine, I punched in four digits, and it gave me about 2,000 krone, whatever the hell that is.

Now there are a lot of participants in that transaction. When I put a card into that machine, punch in a pin, and it gurgles for awhile, and finally gives me, a fairly large amount of money. There are a lot of participants in that transaction. The bank that owned the machine that gave me the money, it gave some money away -- that bank wants it back. The pin is necessary to convince my own bank that I'm me. But I don't want my pin to be broadcast all over the world. My bank in the us, it hasn't really given out or taken in any money, really. But there is a lot of credits involved here. Somebody needs to charge somebody else for having more money available. Even though there was actually no cash transfer.

And the problem that I have in mind is
- who are all the participants in an ATM transaction?
- what do those participants need to satisfy their problems?
- how is that in fact done?

In a general way, does the atm system actually work in some reasonable sense? To which the answer is by the way: yes. The atm system damn well works. With extremely high reliability and accuracy. It surprises me. Its quite a bit different than voting machines.

Complicating factors is the impact (or lack thereof) of incidents on stock price.  Many researchers who identify themselves with the New School of Information Security (yours truly included) want to immediately look at stock price as a bell-weather metric for incident impact.  I think this stems from our days of slinging FUD, back when we could scream “Buy a firewall or we’ll have an incident and you’ll be on the front page of the paper and the stock price will go down!”  But these days notable incidents seem to suggest that the impact on stock price for an incident is short lived.  With qualifications, of course.

So what would/should we make of this from Money.co.uk?

£12million ($24m) Wiped off Helphire Stock after Malicious Email Sent to Clients

Car hire firm Helphire have taken Google to court after a malicious email sent from a Gmail account saw their shares plummet £12million in a single day.

The Bath-based business who specialise in providing replacement cars to ‘no-fault’ drivers involved in accidents on behalf of car insurance companies, initiated legal proceedings against the search engine giant as part of their attempt to find out who is responsible for sending the defamatory mailing.

Google are now known to have complied with the court order and have controversially supplied details of the email account and ISP used by the meddler.

Written under the psudoname Peter Franks, the 1200 word email is know to have been sent from a gmail account that was opened specifically for this purpose and closed a few minutes after the damage had been done…

…The misdemeanour couldn’t have come at a worse time for the struggling firm who have undergone a £45million rights issue and seen a 75% drop in the value of their stock already this year.

That last paragraph, for me, explains some of the difficulty in tying reputation damage to stock decreases.  It’s like when you read the headlines from Bloomberg about why the days stocks (or commodity) prices are up or down.  You know, the “Oil closes $3 higher on news that a notable South American dictator has a rather unpleasant boil in a very uncomfortable area” type of headlines.  You really do have to question the causality and correlation.  So in the Helphire case above - is this new drop in stock really because of the email sent?  If so, should we view that $24mil number as an independent data point to describe this sort of attack on reputation, or is the magnitude aggravated due to the long-term trend of stock price?

Even when we have “Objective Data” (an in-joke for Adam S.) like this decline in stock price, it is really difficult to provide any sort of precise estimate or measurement - about the future, present or past.  The best we can do is use ranges, distributions, that are reasonable based on evidence and observation.

So it’s worth filing away this sort of datum for future use - while dutifully acknowledging the qualifiers we might place around it.

So the questions I ask here - what should we make of this new information, and how should we view the $24million drop - they’re not rhetorical.  I am very interested in your views and welcome your comments!

“FISMA Act encourages U.S. government agencies to configure their DNS servers to the DNSSEC security specifications set by the National Institute of Standards and Technology, and it has been reported that the federal government’s Office of Management and Budget (OMB) plans to begin enforcing DNSSEC requirements through an auditing process, setting the standard for DNS best practices.”

Yep, if you stamp FISMA on it, people will buy it, maybe in your PR department’s wettest and wildest dreams.  Guys, it’s been 6 years, that kind of marketing doesn’t work nowadays, mostly because we spent ourselves into oblivion buying junkware similar to yours and now we’re all jaded.

Now don’t get me wrong, DNSSEC is a good thing, especially this month.  But there is something I need to address:  FISMA requires good security management with a dozen or so key indicators, not a solution down to the technical level.  Allusions to OMB are just FUD, FUD, and more FUD because unless it’s in a memo to agency heads, it’s all posturing–something everybody in this town knows how to do very well.  OMB would rather stay out of mandating DNSSEC and maybe give a “due date” once NIST has a final standard.

My one word of wisdom for today:  anybody who tries to sell a product and uses FISMA as the “compelling event” has no clue what they’re talking about.

Bookmark to:

There’s speculation that falling VMware share prices, with no end in sight because of “poor revenue outlook” is the reason for the ouster.

Hmm. The stock went public at $29, went as high as $125 and is now at $40.26 (and falling as I write), almost a 40% premium over the first offering. Say what you will about the recently launched Microsoft Hyper-V and the Citrix offering that we never hear about, but VMware is the dominant virtualization player (and likely to remain so for at least some time given Microsoft’s track record with new product releases) in an exploding market. Gartner predictions are that the installed base of VMs will grow more than 10x between 2007 and 2011 and that by 2012 the majority of x86 server workloads will be running in a VM.

The future still looks pretty rosy for VMware – perhaps they’ll be taking a smaller chunk of the pie, but the pie’s getting much bigger. And all indications pointed to VMware moving up the stack and providing more management solutions (and more revenue streams) for the x86 virtualization market they helped to build.

So why the change? And why now? Is it a coincidence that it’s an ex-Microsoft exec taking over just as Hyper-V ships? Can only someone who knows the Microsoft Way combat the Microsoft Way? Remember this is the guy who wrote that Microsoft should “cut off Netscape’s air supply”.

So, good idea to say that Microsoft execs are better than VMware execs just as the Hyper-V juggernaut gets rolling? If I didn’t know better, I’d say this is the latest example of a MS FUD campaign…

ShareThis

So my next iteration of fun reading on security, logging and other topics.

1. "Security-as-control" vs "security-as-assurance" - a very useful idea (more here), which is often confused with bad results (e.g. "secure" software = has password authentication OR has has no overflow bugs)
2. Rich Mogul grabs GRC by the balls and kicks it, hard, again. A Burton Group guy comes and helps him by doing a nice roundhouse kick in its butt. Still, it doesn't die, as more people kick it ... Maybe 'cause Andy "loves or hates it?"
3. Good advice from Andy IT Guy: "We need to step back from time to time and evaluate what we are doing to determine if it still makes sense." (more)
4. BBC on cloud security, actually interesting. More on the same subject, albeit with a dumb name
5. Breach disclosure laws and security study by CMU, that SANS called idiotic ("What a silly study. It measures the wrong outcome. What matters about data breach notification is what it does to the quality of defenses.") AND "badly flawed" as well. More fun comments on it are here.  More discussion of this complicated subject. Rick kicks it too here.
6. Along the same line, "Data breaches at retailers are the top cause of credit and debit card theft, accounting for about 20% of all incidents." Wow!
7. "The biggest issue in both Audit and IT is a lack of strategic thought." (maybe) When I read it, it reminded me of the old wisdom from Ms Trunk: "if you think you are a 'strategist' - check maybe you think that 'cause your execution sux"
8. A very fun read: "Facing The Monster: The Labors Of Log Management." I am happy that log management has been granted a monster status :-)
9. Role of compliance for SCADA security puzzles me: think about it - you need a law to make people protect systems that control utilities EVEN THOUGH you already demonstrated (kind of) that hackers can explode generators remotely. So, people fear fines from regulators more than exploded power generators? Yep.
10. Is it time to regulate the security of cloud computing?
11. "How to Sell Security" by Bruce Schneier - a MUST read. BTW, FUD is NOT dead, and won't be dead. Ever!
12. OMG, this is huge and will grow: PCI Compliance and Virtualization (think "only one primary function per server" mandated in PCI). Same source on costs of PCI (also fun!) - still, IMHO, PCI is cheaper than properly securing your environment ... And while we are on the subject of PCI, check out Rich's "The Good (Yes, Good) And Bad Of PCI" and the discussion that followed.
13. New wave of compliance is incoooooooooooooming. Take cover!!!
14. Please shut up about ALL security being rolled into the network. Hoff says it best here.  If you want to join this bandwagon, say "all NETWORK security will be in the network."  (you'd probably still be wrong, but less embarassed :-))
15. Finally, some "Unintentional hilarity" from David: this is sooooo the world we live in :-)
    

1. We don’t believe that the goal of Quantitative Risk Analysis is to be precise.  We believe the goal is to be accurate. Subtle but important difference.
2. FAIR can be used both Quantitatively and Qualitatively.   The decision on which method to be used depends on various factors that Steve lays out nicely in the article there.
3. We believe that Risk Management is more than looking at specific vulnerabilities, their likelihood and impact.  It must encompass all aspects of the organizations ability to effect the probable frequency and magnitude of loss on an aggregate level, not just within the context of a discreet technical or policy issue.

That last point is important.  And it’s related to my post today.

WHAT DO YOU MANAGE TOWARDS?
This blog is blessed to have some very smart people be part of it.  There are security managers from all sorts of industries that read and comment and contribute.   And so today’s blog is more of an open-ended question for you all.  It’s a question that, if I have a comfortable relationship with the organization I like to first ask the senior manager, and then subsequently ask the direct reports.

When you think about it, Sales & Marketing managers have goals they manage towards.  CFO’s have goals that they manage towards.  COO’s have goals and measurement that they manage towards (cost management, production, etc…).  So what does the CSO manage towards?  I’m guessing if we took a national poll, we’d get all sorts of very nice sounding answers to that question.  I thought I’d list some of the answers I’ve heard and talk about them with you today.

1.)  Being Secure or “Managing to Security”

Generally, this concept of being secure is the most common answer.  And when I’m given that answer, it generally means that management focuses on Vulnerability Management, Patch Management, and to some degree, log analysis from various sources.  These are very basic core security functions, and the  belief is that if we do these well, we will be “secure”.  Ok, well… what does this “secure” mean, and how can we talk to management about whether we are meeting this goal?   If you examine that question, you actually find out what a “Being Secure” organization is really managing towards, another answer I hear often:

2.)  Being Incident-Free or “Managing to Perfection”

Security Person:  “Alex, our goal is not to have any incidents.”  Alex:  “Good luck with that.”

OK, that’s not what I really say, but here’s the problem I see with this common answer and the one above both of these common answers:  How do you know if you’re good or just lucky?

Well, are you, punk? (youtube link)

In my six years of working with a Penetration Testing team, nobody ever really “passed” with a perfect score*.  Some did better than others, some folks looked really, really good - but the degree  of good/bad was really more dependent on scope than the actual state of controls or the ability of the team to overcome them.  That is to say, when pressed, the mature security professional must admit that, given a strong, capable threat community -  there is no secure.   And therefore any state of “incidentlessness” deals with some combination of amount of control strength, and some lack of attacks (frequency!) by someone with enough skills and resources to overcome those controls.  If that last sentence sounds very FAIR-Like, that’s because it is.  If FAIR really accounts for those things that create Risk, then Managing to security or lack of incident means that you’re primarily concerned with FAIR Vulnerability, and ignoring other critical aspects of risk (like frequency of attacks, controls that reduce the probable impact of an event due to an ability to respond well to external stakeholders, etc…).

3.) Being Compliant or “Managing to Compliance” (External Compliance Pressures)

Because that’s what business buy, right?  They buy compliance!   Or so I’m told.  So let’s say that you go out and actually twist senior managements arm to get them to cough up enough dough so that you can be as compliant as Large Accounting Firm says you need to be.  Good on you!

But what I always wonder is, what happens when you want to manage something beyond compliance?  What happens when the checklist you’re managing towards is run by a bureaucracy that can’t keep up with a changing threat landscape?   For many people, the answer is “GOTO 1″ and try to sell upper management using FUD (hey, it used to work, maybe it’ll work again).  An alternative is to get to the next step:

4.)  Being Measured or “Managing to Metrics”

Say what you will, but “quants” have one thing right.  What gets measured gets done.  And a few mature organizations have spent a ton of time and effort on being able to create dashboards of KPI’s that attempt to measure security.  Problem is, that we don’t know if a 98% on patch levels is good or bad or just right.  We don’t know what value, if any, does creating metrics around the number and severity of vulnerabilities found in a monthly scan actually have.  So we’ve come up with this thing called “GRC” that’s supposed to make sense of those things we can measure empirically and help you find out if/when you’ve fixed them. And while GRC tools can tell you some good information about systems out of compliance, they tend to give you fantastic information like how your “risk = 57“.

Wha….?

Risk = 57 means very little to someone who doesn’t spend their life in the machinations of the GRC indicies.  So again, measurement without a (good) model still falls down when faced with that ultimate business decision.  Or, as Shurdlu so eloquently puts it in her post on GRC:

“By contract, risk is personal.  It’s variable as hell.  It “governs” what you spend your money on, and therefore, with or without a dashboard, your CEO is already doing risk assessment every time she decides what your security budget is going to be.  Will you really be able to change her mind by showing her the dashboard and saying, “But—but—the needle is pointing to RED!” when you’re sitting there with your line items in your fiscal shopping cart? “

5.)  Using Risk or “Risk Management”

Which brings us to my favorite, using risk (as defined as the probable frequency & probable magnitude of loss event(s)) as a means to manage.  Now many industry veterans will tell you how jaded we all are on the term “Risk Management”.  And we have every right to be, as Risk Management has been horribly abused by vendors, committees and standards bodies alike.

These days, the term has been narrowly defined to mean an extension of vulnerability management.   This is small, small thinking, IMHO.  To me, Risk Management isn’t the management of individual issues deemed as “risky” as much as it is measuring (see 4) our ability to make decisions through the lens of risk.  Maybe I should start saying “Risk-Based Management” instead of “Risk Management”.

This Risk-Based Management approach provides meaning to metrics. We can know what we’re measuring and why we care about it.  And why we care about it needs to match what management cares about.  If your approach to Risk Management results in some metric or KPI that non-IT (or non-security) management doesn’t understand or speak to them in an evident language, it’s time to find a new model.  This is why “Quants will win” and where risk = 57 is wrong.  Risk, expressed as “expect a once in 5 year chance to lose $875,000 if we don’t spend $90,000 now” actually gives executives something beyond an arbitrary ordinal number or color to work with.  And what’s interesting is, if your model does the right things in getting you to that expression - then metrics and KPIs - those “why/when/where” questions we have a tough time answering about metrics - they become easier to discover.

DISPROVING RISK MANAGEMENT

As a side note, originally I was going to write today a completely different post on how we can disprove whether or not OCTAVE or 800-30 or ISO 27001 risk management efforts are really “Risk Management” - and one significant point was “Does your non-IT management really care about the deliverable?”   This thought came to me after seeing a few too many emails into the ISO27001 mailing list asking “How can I get management to fund ISO 27001 certification?”  Of course, the value of implementing the ISMS and the value of certification are two separate business propositions, but if you can’t sell the first, then are those efforts really good risk management?  You know, the kind of effort that we can use to make meaningful reporting?

=============================

* I can tell you that at times we were asked to test products out for clients before they made a significant investment.  One biometric device stands out in memory as not being “hacked” in the time alloted for the engagement by a defense contractor.  After it passed the “Gummi Finger” test - we were going to try using a recently severed finger, but oddly enough nobody on the team volunteered their digit for the sake of security.  Bunch of slackers.