Slashdot Mirror


Trust Is For Suckers: Lessons From the RSA Breach

wiredmikey writes "Andrew Jaquith has written a great analysis of lessons learned from the recent RSA Cyber Attack, from a customer's perspective. According to Jaquith, in the security industry, 'trust' is a somewhat slippery concept, defined in terms ranging from the cryptographic to the contractual. Bob Blakley, a Gartner analyst and former chief scientist of Tivoli, once infamously wrote that 'Trust is for Suckers.' What he meant is that trust is an emotional thing, a fragile bond whose value transcends prime number multiplication, tokens, drug tests or signatures — and that it is foolish to rely too much on it. Jaquith observed three things about the RSA incident: (1) even the most trusted technologies fail; (2) the incident illustrates what 'risk management' is all about; and (3) customers should always come first."

18 of 79 comments (clear)

  1. Trust is required by houstonbofh · · Score: 4, Insightful

    The problem is that trust is also required to have a functioning society. The higher the trust, the better a society can function. The lower the overall trust (More corruption) the less effective it is. I think "Trust but verify" is the best.

    1. Re:Trust is required by RightSaidFred99 · · Score: 2

      Yeah, those shitty 80's. We're all much better off now!

    2. Re:Trust is required by flaming+error · · Score: 4, Insightful

      > trust is also required to have a functioning society.
      Maybe, to a degree.

      >"Trust but verify" is the best.
      Indeed it is. Trust works when claims can be supported.

      Problems happen when information is just not verifiable, such as in closed source products, secret negotiations, undisclosed business interests, or whenever information is withheld or misrepresented.

      When "trust me" is all the verification a vendor offers, trust is for suckers.

    3. Re:Trust is required by houstonbofh · · Score: 3, Insightful

      A whole post of information and all you see is the quote at the end. You might want to read "The Last Centurion" by John Ringo for some good information on high vs low trust societies. Or not, since he might like people you hate.

    4. Re:Trust is required by h4rr4r · · Score: 2, Insightful

      I don't hate anyone, I dislike people who work against folks I do like though. I don't like it when people idolize those who work against them either. "Trust, but verify" just makes no sense. "Never trust, always verify" at least makes good sense.

    5. Re:Trust is required by idontgno · · Score: 2

      The "verify" part implies a degree of transparency and insight that's rare nowadays. The fact that governments have to write laws that compel breached firms to notify their affected constituents in a reasonably timely and understandable manner is proof that if their reputation and sales are on the line, you'll only learn the absolute minimum dictated with the weight of unavoidable severe consequences. And that is a miserable basis for "verify", which makes "trust" a fool's game.

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    6. Re:Trust is required by hedwards · · Score: 4, Informative

      No, what it means is that you don't blindly trust anybody, but you do verify periodically that the trust hasn't been abused. It's like granting a business the right to take money out of your checking account to cover expenses, like say a CC company. You trust them not to put things on the bill which you didn't authorized. And you verify at least once a month that everything that's on the bill was authorized by you.

      Same thing here, the problem with RSA was that people trusted them, but there was no particular manner of verifying that the trust was well placed.

    7. Re:Trust is required by Anonymous Coward · · Score: 2, Informative

      I don't hate anyone

      Bullshit.

    8. Re:Trust is required by Dishevel · · Score: 2

      I use it all the time.
      I download software from people I have some trust with.
      But I always run at least a cursory virus scan and always use custom install options if available.
      I then try out the software looking for problems. making sure it behaves as I was told it would.
      If it starts communicating with the outside world where I think it should not or installing services and driver where they need not be my "trust" get revoked.
      Just because I trust you with the keys to my house does not mean that will not change when I get information that my trust may be misplaced.

      --
      Why is it so hard to only have politicians for a few years, then have them go away?
    9. Re:Trust is required by ChatHuant · · Score: 2

      Problems happen when information is just not verifiable, such as in closed source products, secret negotiations, undisclosed business interests, or whenever information is withheld or misrepresented.

      You're mixing things up, either intentionally or because zealotry trumps reason in your thought processes. Not getting source code is not the same as being lied to, either by omission or by commission. You'll never have all the information about the making of a product available. You don't have the secret Coca Cola recipe, but that doesn't stop you from drinking coke. You don't know the composition of the various alloys your car is built of, but you do drive. You don't know the maintenance history of the plane you're going to use, but you do fly. You don't normally care about all those things, because they're not normally relevant to your needs. It's the same with the source code. What you care about is whether the product actually does what it's supposed to do, and meets both explicit and implicit expectations. The only reason to mention source code in this particular context is zealotry.

      Let me give you an example: if a vendor tells you his database performs one thousand transactions a second in a given configuration, what are you going to do with the source, simulate the database using pen and paper and check the vendor's statement? Surely not. You'll build the configuration and count the transactions. If the database only performs a hundred transactions per second, you've been given false info. Or, if the database performs a thousand transactions for about a hour after which it crashes repeteadly, you've been given insufficient relevant info.

      To preempt some weak counter arguments, yes, there are a few rare cases when the source code IS relevant to the issue. When getting actual source is an condition/expectation of the sale, the vendor will submit it, or they won't offer the product at all.

  2. Like Warren Buffett said... by MetricT · · Score: 5, Insightful

    It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently.

    RSA was hacked, ultimately, because of short-term MBA thinking (I have one, so I know the type). If there's only a 10% chance of a serious security breach, then 90% of the time you can scrimp on security, and you won't merely get away with it, you'll be rewarded for "doing more with less". This same dynamic is often seen in both Wall Street and Washington.

    I really wish we were required to read Nassim Nicholas Taleb's "Fooled by Randomness" and "Black Swan" in school, instead of Thomas Friedman's dreck. At least they couldn't say they weren't forewarned.

    1. Re:Like Warren Buffett said... by GameboyRMH · · Score: 2

      They make people read Friedman to get MBAs!? Well that goes a long way to explaining why the world's so fucked up.

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
  3. History by chill · · Score: 4, Interesting

    Of the people who I've talked to with RSA tokens, most have said they're now actively planning a migration off of RSA tokens.

    It isn't that they were hacked. Shit happens, even to the best of them. It was the lack of information and lack of transparency by RSA (EMC) on the whole event. Trust has been lost.

    I'm not talking about public statements or mea culpas. I'm talking about why they weren't 100% open and upfront with existing customers right away. It gives the impression that EMC's execs were hoping no one would get hacked and it would all fade away over time. That they could just ride this out and weren't going to have to fork over a boatload of cash to replace everyone's tokens, thus not taking a hit on their stock or bonuses.

    They were wrong, and now the price they are going to pay is not only replacing everyone's tokens, but a loss of trust and hence future business.

    --
    Learning HOW to think is more important than learning WHAT to think.
  4. Serious Definitional issues... by fuzzyfuzzyfungus · · Score: 5, Insightful

    Speaking of trust issues, quoting a Gartner analyst?

    Anyway, back to the matter at hand: This article seems like a particularly bad situation for the two sharply different definitions of "trusted" to come into collision without very, very careful elucidation.

    On the one hand, you have the usual social usage of "trust": more or less "the belief that a person or device will do what it says/act in good faith/do what it says on the tin/etc."

    On the other, you have the paranoid security wonk definition of "trusted": "the state of being a component of the security system whose overall integrity depends on your integrity as a component."

    The two could really hardly be more different while still occupying the same word. The former is socially valuable, and societies become dystopian hellholes without it; but it is a very poor ingredient upon which to build technologically secure systems. The second is an unfortunate necessity; but it is one of the marks of a good security system that it knows exactly what parts of the system are 'trusted' and what parts need not be.(a second, and important, mark of a good security system is that the set of 'trusted' systems has been culled as much as possible, and that no 'trusted' systems remain that you do not have good reason to 'trust' in the usual social sense.)

    In the case of RSA, you really had a massive failure on both counts: In the social sense of "trust", RSA arguably oversold the security of their solution, was intensely cagey about the break-in until breaches at major defense contractors forced their hands, and generally fucked around as though they were trying to burn social trust. In the infosec sense, the fuckup was that(by retaining all token seed keys, RSA made themselves a 'trusted' component of every customer's security infrastructure. It is an architectural limitation of the RSA system that there must be a trusted system, with access to the seeds and an RTC, in order to perform authentication attempt validations. However, it is Not a requirement that there be other online seed stores out of the customers' control. By making themselves an extraneous, excess, trusted system, RSA weakened all their customers' security. Now that they are a 'trusted' component that no sensible people have social trust in, they are finding themselves written out of a fair few security architectures...

    That is the real crux of the matter. From what I've heard(both public-ally and informally from friends working in IT at largish RSA customers) the hack was some seriously sophisticated work, rather than somebody walking in through an unlocked door. However, it barely matters how tough their security is; because they never should have set themselves up as part of their customers' systems in the first place. Had the customers done the keyfill for the tokens, it wouldn't have mattered whether they had been hacked or not.

  5. Trust what? by lazlo · · Score: 3, Interesting

    From my understanding, the RSA breach basically broke into the database that ties serial numbers to the internal "secret" that's used to generate OTP's. So go back to before the breach, and assume you're an RSA customer. To be their customer, you have to trust them. You can trust them to:

    1. 1) securely wipe their copy of the database once they've delivered your tokens to you
    2. 2) keep their database secure against attackers
    3. 3) provide you with a copy of the database after you lose yours.

    Note that options 1 and 3 are mutually exclusive. Now, it would be nice to be able to choose your level of risk tolerance yourself and decide on #1 vs #2 + #3, but there are a reasonable number of customers who actively dislike being forced to make choices. And there would be a whole lot of customers who would be really mad if, after losing their database, were told by RSA "Sorry, all of your tokens are now useless keyrings. No choice but to replace them all"

    To me it's like the evolution of passwords. In the beginning, if you forgot your password, your admin could tell you what it was. Then passwords got hashed, and your admin couldn't tell you what it was, but could reset it for you, and security was enhanced. Then passwords were used as encryption keys, and now your admin couldn't tell you what it was or reset it. If you forgot it, your data was gone. Once again, a security enhancement, but now a greater danger of data loss through forgetfulness.

    --
    Pound! Bang! Bin! Bash! is this a shell script or a Batman comic?
  6. most trusted technologies? by blair1q · · Score: 2

    "(1) even the most trusted technologies fail;"

    Uh, dudes.

    THE INTERNET IS NOT SECURE

    If you hooked your database up to the Internet, then you are the fail.

  7. Two Words: Yubikey by VortexCortex · · Score: 3, Informative

    Yubikey has secure tokens that you can "seed" yourself, for use with your own authentication servers. The scam is that RSA made some idiots think think there was no way to do this without their auth servers; Thereby fooling fools into using a less secure system with a mandatory recurring payment for RSA (to access the auth servers).

    Re-configuration of YubiKeys by customers

    For high security environments, customers may select not to share the
    AES key information for their YubiKeys outside of their organization.
    Customers may also for other reasons want to be in control of all AES
    keys programmed into the Yubikey devices. Yubico therefore supports the
    use of a personalization tool to reconfigure the YubiKeys with new AES
    keys and meta data.

    Additionally, I prefer the model that has RFID for physical access.

    Relying on an outside source to have our cryptokeys is just adding another point of failure. EVERYONE relying on them is just creating THE BIGGEST point of failure possible... Every time I talked to security minded folks that used RSA tokens, I asked them, "So. How secure are RSAs severs? You do any security audits on them lately?" The blank expressions were priceless.

  8. Blake's 7 by HTH+NE1 · · Score: 2

    Cally: My people have a saying: "A man who trusts can never be betrayed, only mistaken."
    Avon: Life expectancy must be fairly short among your people.

    Avon: Cally was murdered. So were most of her people.

    --
    Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?