Erick Rudiak. Songwriter. Singer. Human.

bit.ly considered harmful (or: let's stop blaming the victims)

Thu, 2 Feb 2012 22:46:34 -0500

Dilbert from 2011/11/28

A colleague, whose company had suffered from a sophisticated security breach last year, recently shared with me some of the awareness materials that were distributed in the wake of the compromise. Not unexpectedly, one of the key points they were driving home was: verify links before clicking, e.g. by hovering over the link or by typing it into your browser's address bar by hand.

We CISOs all do this as part of our ubiquitous "security awareness" programs. We vigilantly remind our users about the dangers of being online, of how we need their help in defeating the hackers and corporate spies that are out to get us, and how information security is their responsibility. Unfortunately, we're not doing this because it's effective, or even because we think it might be effective. We do it, because if we didn't and then an adverse event occurred, we would be held in contempt, both literally as well as legally. In other words, it would be our fault. Unfortunately, the corollary to that assertion is that, by putting unrealistic expectations in front of our users, we are essentially shifting the blame: if it's not our fault, then it must be theirs. And this is wrong.

The reasons why this guidance misses the mark are multifold. Have you ever tried to hover over a link on your iPad or Galaxy S? More importantly, URL shorteners like bit.ly, t.co, and goo.gl have created a layer between our users and the sites they visit that is both trusted (they encounter these links hundreds of times daily on twitter and Facebook) and intentionally opaque. Colbert is being funny here, but he nails the underlying information security issue: that shortened link is liable to take you just about anywhere. Meanwhile, the attackers are taking advantage of our users' familiarity with shortened links and the fact that, 99.9% of the time, nothing (visibly) bad has happened to them when they followed one*. In the threat model of us versus the attackers, we've set up a game with two outcomes:

Tens of thousands of our corporate users diligently check every link they're thinking of following before they click (I'm using LinkPeelr in the screenshot above)... and make the right choice every time or...
The bad guys get what they want.

Late last year, Wired and Ars reported on a credit card skimming case in California. They got a choice quote from the CEO of a cybersecurity company who utilizes "sophisticated psychological analysis [... to] help ensure that our customers derive maximum business and security benefits without imposing any extra burden on users." Their advice:

Everyone should always check any device in which they insert/swipe a credit/debit/ATM card, or to which they touch their card, to see if it looks like it may have been modified/covered.

We can see that the behavioral incentives here are stacked against the user making the right choice: their #1 goal is to check out quickly and be on their way, but we're admonishing them to check the point-of-sale terminal and make an expert decision on whether it has been tampered with prior to providing our credit cards. There are two reasons users constantly fail to heed this advice without destroying the fiber of our financial system. First, the advice is hard for most people to act upon correctly. Second, the credit card companies have indemnified the users: the risk to the user of making the wrong choice at a POS terminal is usually nominal - $50.

While it feels instinctively naive to expect our users to consistently follow this rule of thumb for their daily credit card transactions, we persist in asking them to do the same for their thousands of daily interactions with the Internet. In the spirit of never offering problems without solutions, here are some ideas:

Browser vendors: let's build functionality like LinkPeelr's directly into the browser and safely check those 302's to their logical end. As of this evening, a whopping 2,618 users (including me) have installed LinkPeelr in their browser. Adding up all the other extensions in this space, we're still, in the parlance of a good friend, waaaaaaay to the right of the decimal point on the percent of people who have access to this space-age, link-expansion technology.

Network administrators: if protecting those assets is important enough, let's agree to take the occasional support call from a user who can't get to a website and enforce IP reputation checks when people are accessing the Internet. It's not prohibitively expensive, addresses the root of the problem (the malicious website) rather than the cause (user clicking an unverified link), and it's way better than doing nothing.

Sysadmins: let's also agree to segment our networks so that a single compromised device doesn't immediately lead to checkmate for our wily attacker. Nobody hesitates to require multi-factor authentication for critical in-house systems after they've been breached: it's silly to wait.

Bad guys: please don't roll your own URL shorteners. This is why we cannot have nice things.

CISOs: let's stop blaming the victims. Relying on every last user to make the right choice every single time is truly absurd. We will, of course, continue to educate our users; it would be negligent not to. But we also need to be aggresively transparent and educate our stakeholders, connecting the dots for them between the inconvenient controls we're proposing and the protections they will deliver. Let's help our business sponsors make informed decisions and arrive at the correct balance between user experience and safety for our organizations. Their ability to own the risk is far greater than that of the thousands of folks on their lunch breaks who just want to figure out what the heck Colbert is talking about, and whom we're currently holding accountable today.

Anonymous/RIAA kerfuffle

The trick snagged those who happened to click on a shortened link on social-media services, expecting information on the ongoing #opmegaupload retaliation for the U.S. Justice Department�s takedown of popular file sharing site Megaupload. Instead they were greeted by a Javascript version of LOIC � already firing packets at targeted websites by the time their page was loaded.

Disobeying Benford's Law, one password at a time

Fri, 2 Dec 2011 02:36:00 -0500

Is it wrong to say I was enjoying toying around with howsecureismypassword.net the other day... and, if so, is it more wrong to mention that the first thing that came to my mind was, "I wonder if Benford's Law applies to the dataset behind the site?" Turns out, it does not.

"password" was, naturally the most popular password. Since the top 10,000 passwords (i.e. the xato.net corpus) didn't cover all combinations of /password[0-9]/, I shifted over to the gargantuan rockyou corpus instead. I didn't expect the distribution to be perfectly random - humans don't work that way; I wondered, instead, if it would follow Benford, i.e. password1 at ~31%, password2 at 18%, and diminishing logarithmically from there.

It turns out that the distribution of /password[0-9]/, as predicted in Hangover 2, was weighted heavily towards password1, a whopping 70%; password2 was second at 10%, and password3 third at 4%. The other numbers did not appear in sequential order. princess and iloveyou, the next two most popular passwords, had similar results:$ bunzip2 -c rockyou-withcount.txt.bz2 | awk '$2 ~ /^princess[0-9]$/ {print}' 5187 princess1 683 princess2 410 princess7 391 princess3 266 princess5 252 princess4 224 princess8 204 princess9 145 princess6 30 princess0

Why does this matter? Because we in InfoSec justify imposing password complexity rules on our users when we say that complexity will help defeat brute-force attacks. We claim that enforcing 8-character password schemes requiring mixed case letters and numbers will result in a user community whose passwords have 47.6 bits (8 x log62 / log2) of entropy and, thus, will not fall victim to brute force password guessing attacks. In reality, most users capitalize the first letter and tack on a "1"; the most likely real entropy of an 8-character complex password is closer to 32.9 (7 x log 26 / log 2 + log 1 / log 2). In other words, real users will go out of their way to thwart our mathematically pure plans and intentionally select passwords that are no more brute-force-resistant than a random 6-character password.

What can we (InfoSec folks) do? A few things come to mind. Based on the data above, one could argue that forcing users to place a "0" in the middle of all their passwords is an extremely effective way to slow down brute-force attacks. A more practical approach I have followed is maintaining a small library of threat mitigation charts, not unlike the one below, for common situations. It helps both me and my conversation partner quickly size up the effectiveness of a given solution, and demystify the reasons why I will fight harder to preserve some controls (inexpensive, 3+ stars) and not others (expensive, 1-2 stars).

Second, I have become a fan of the of using visual password strength meters to discourage (if not altogether forbid) users from selecting weak passwords during account registration... and an equally big fan of banning absurdly weak, guessable passwords, as both hotmail and twitter* have done, ditto all those grizzled UNIX/Linux sysadmins implementing pam_cracklib. I like this approach for a couple of reasons. It's an inexpensive control: in the case of webapps, it's one of those rare cases where client-side security enforcement is acceptable. It's also a control which, unlike complexity or periodic forced change, most users will not struggle against and defeat in favor of their own convenience. Plus, if you believe the xato.net numbers are anywhere close to accurate -- that 40% of users choose a password in the top 100, 79% in the top 500, and 91% in the top 1000... and that 5% of the top 10000 passwords would still comply with the PCI DSS 2.0 (8.5.10) standard of 7 alphanumeric characters -- then restricting the top X passwords your users is a great way to reduce the effectiveness of salami slicing attacks, which are immune to intruder lockout, especially in environments where extreme length requirements are impractical.

Finally, and this will be the most controversial to-do: we must stop punishing our users with draconian requirements that add little security value and are intuitively difficult to get right. More on this later, I promise!

* Doing this client-side, as Twitter has done, apparently does involve rot-13 encoding the password strings, lest some unsavory phrases result in one's web pages being blocked by aggressive content filters.

Breaking bad news

Thu, 3 Nov 2011 23:16:00 -0400

I had the pleasure of being in Bloomington, MN, last week and met with a fellow CISO who wanted to know more about how I approached vulnerability assessments. We got to talking about some of the boutique assessment firms out there and what made the good ones so good. For me, the difference came down to their ability to answer a very important question: if someone of a certain skillset had the inclination to make my company a target, how long would it take them to succeed, and how much noise would they have to generate? Society has learned to demand this sort of information for its physical assets; this is why Underwriters Laboratories rates their safes:

Safes are rated for their resistance to attack against specific tools for a set period of time. There are a dozen different ratings, everything from ATM machines, to gun safes to bank vaults. For example, a safe that bears a Class TRTL-15x6 rating, which might be found in a jewelry store, should resist a hand tool and torch attack for a minimum of 15 minutes. A TRTL-30x6-rated safe, which would protect important documents or store money, should withstand an attack for 30 minutes. The ultimate safe rating -- a TXTL60 -- should withstand an hour's worth of attack that includes the use of 8 ounces of nitroglycerin.

What makes a good pentester is their ability to provide a similar level of assurance for a digital asset; anything less is (there... I said it...) mere compliance. When I hire someone to do this task, I am paying for the confidence of knowing, for that magical point in time when the test occurred, that a skilled attacker spent X hours trying to break in and the exact result of that exercise.

At this point, my fellow CISO asked a rather salient question:

People that good are bound to break in more often than not... how do you break the bad news???

Pausing for a brief flashback to my last gig, where we kept a copy of Grandma's Dead: Breaking Bad News with Baby Animals around for just these sorts of occasions, I responded: "knowing is never bad news." Reality is, of course, rarely that cut-and-dried. Some vulnerabilities are easier to fix than others, and some can be downright embarrassing. However, if you believe (as I do) that the CISO's role is not to prevent all bad outcomes, but to drive for informed risk management and, year over year, to raise the bar on the safety rating of his company's digital assets, then you rarely feel the need to pull out that aaaaawfully cute puppy.

My #4 and #5 favorite runners from this year's Chicago Marathon

Wed, 19 Oct 2011 21:35:14 -0400

My beloved Konica has finally succumbed to atrophy and a bit of the camera-style central serous retinopathy. I'm reluctantly learning to enjoy a newer model, which tempts me to shoot in its built-in 16:9 aspect ratio. This should explain lots of the recent updates to the gallery.

K as in "knife"

Fri, 10 Jun 2011 21:27:32 -0400

There's a scene in the new Hangover movie (hat tip: Matt M) where one of the characters is reading off the credentials needed by another to log into some online service.

Mr. Chow: "Password?"
Alan: "Bologona...One"
Phil: "Your password is bologna one?"
Mr. Chow: "Well, it used to be just bologna, now they make you add a nuuuhhhmber!"
Guy:"****ing annoying"

And there, folks, is the 4-second distillation of so much of what is wrong with information security today. The users put up with the controls, but find them absurd and annoying. They disrespect the controls, so they ignore them in practice. Frankly, it's difficult to blame them. Logically, the combination of controls we throw at our users doesn't make sense. Let's look at the most common ones and then come back around to a call to action.

minimum length: this control, which most places usually set to at least "8", as far as I can tell, originates from a 1972 paper in Advances in Computers, Vol. 12. This paper asserts that, to achieve a 1:10,000 probability that a password will be cracked at the maximum transmission rate of an attacker's line (estimated to be 300 characters per minute, or approximately 40 baud) using a 26-character alphabet, the password needs to be at least 8 characters long. Nowadays, the logical answer to brute-force attacks depends on whether they're online or offline. For online attacks, locking the account (or slowing down the line) upon detecting password guessing is considerably more effective; for offline attacks, rainbow tables and GPU-powered cracking tools have demonstrated that 8 characters isn't nearly long enough.

complexity: this is an example of a good idea taken too far, and in the wrong direction. We infosec folks understand that the space of possible passwords an attacker has to guess grows as x^y, where x is the space of possible characters used and y is the length of the password. Sure, 27^y (all lowercase characters plus spaces) doesn't grow nearly as quickly as 95^y grows (all characters you can type on a standard keyboard). The problem is that most humans' ability to memorize long, complex strings either runs out at y=5 or we naturally limit ourselves to a smaller number of choices than 95. Mr. Chow's password wasn't "bologna6", it was "bologna1." On the other hand, we're much more likely to remember three or four words strung together, so we can get better mileage out of large values of y in 27^y, as Thomas Baekdal argues so effectively in his excellent Usability of Passwords post.

periodic, forced change: again, we need to look at our threat model. If your attacker can eavesdrop on your password, this control adds no value. If your attacker can capture your keystrokes, or is a rogue sysadmin, this control adds no value. If your attacker is brute-forcing your password online, this control adds little value, certainly compared to intruder lockout. The only time this control adds value is if your attacker has an offline copy of your password database and it's a race between the user changing the password and the attacker cracking it. Per some of the articles quoted above, modern computing allows the bad guys to crack all but the longest or most absurdly complex passwords in hours or days; we typically give our users at least 30 days before changing their passwords, often longer. This is not a good race to try to win if we're the InfoSec folks.

So now it's time to bring it back to Mr. Chow, our prototypical user. We tell him that he has to have a complex password and change it regularly because, if he doesn't, Al Qaeda wins. There are at least two problems with this approach. One is that, if the adversary is well-funded and determined like Al Qaeda, they will bypass these controls through a side channel; targeted malware comes immediately to mind. The other problem is that we are creating incentives for everyone to behave badly. We force users to add a number, and they'll just keep incrementing the number. That forces us to escalate: we have the system remember what password they chose last time and force them to change multiple characters, or we prevent them from using dictionary words, or we don't let them tack the number onto the end or capitalize the first letter. Then, not only do they have the incentive to write their password down for fear of forgetting and locking themselves out, our system also has to store some additional information that may assist the offline attacker.

Here's my proposal to the InfoSec community: if we're serious about protecting something, let's station restrict it, or require two-factor authentication, preferably both. If we're protecting something because not protecting it at all would be outrageous, let's give our users a break on the silly controls and apply a reasonable threat model. Do the cheap, simple easy stuff every time: lock out intruders, encrypt (technically, salt and hash) at rest, encrypt in transit. This effectively takes care of all but your rogue sysadmin and your keystroke logger (which is, really, just an extreme, long-distance case of the shoulder-surfer or passerby who notices the stickie on the monitor); no amount of regular password changing or content complexity defeats those threats. If we have to convince someone that a lucky guess won't defeat our controls, let's pick a password entropy level that we can live with and make sure our users exceed it. Let's also help them by providing visual password strength meters when they're enrolling or changing their passwords. Maybe, just maybe, our users will give us a little credit for treating them with respect and not trying to convince them that "f@%K!7_)" is a better password than "good times van".

Aside to MSFT: if your nifty online password strength checker tool already knows that "Bologna1" is a weak password, why don't you use your position of power to get people to stop thinking that the "3 out of 4" test against {alpha_lower, alpha_upper, numeric, !alphanumeric} is some sort of gold standard? Thanks.

Aside to PCI: something you know is a piece of trivia; something only you know is a password. Apply similar logic to something you have (see The sketchy ex-roommate test), and something you are. Thanks.

Nostalgia

Sun, 1 May 2011 01:02:00 -0400

"You can fly as far as you want to, I'll be waiting for you at gate 27-C"
Terminal Love

In 1997, I acquired two hobbies: picking up my girlfriend at ORD and writing songs. That year yielded the Baltimore Sun/Terminal Love/Laura & I trilogy (which should not be mentioned as a trilogy without its Good In Bed postscript), a surprise career change to information security, and my first solo acoustic performance since giving the violin up for volleyball (sorry, mom). 2011 has turned into a year of transitions, but I'm still writing songs, going through an unexpected career change in information security and, ironically, finding myself spending a lot of time at ORD. Finally, I'm doing one last show in Chicagoland before the big move. Join me at Brothers K Coffee at 8:00 PM on Saturday, May 21st, for the farewell show. The wonderful Emily White opens.

Listen to Baltimore Sun, recorded live at Uncommon Ground!

Add the show to your calendar so you won't forget!

Real estate.

Tue, 15 Feb 2011 22:47:09 -0500

If it weren't for the opening line to this song, I would have no happy, long-lasting memories of my career as a holder of and trader in property. Also, anyone wanna buy a sweet, sweet house?

Live at Brothers K, 5 February, 2011

The sketchy ex-roommate test.

Thu, 20 Jan 2011 22:37:30 -0500

Ten years ago, when my gig was running network security, I surprised my then-CISO after he made an off-handed comment about what might happen "if you leave." I calmly explained that my team would disable my SecurID token, an automated job would put my name on a list of people whose building badge would be shut off at midnight, and everything would be fine. He was sure that I would walk away with enough information to break into the company; I was sure that my job involved building and running a network in such a way that knowledge of how we stitched things together didn't constitute a key to the kingdom.

Fast forward to 2011: twice in the past quarter, I've encountered suppliers who resisted sharing basic hosting design information with me, their paying customer. These were suppliers that my company entrusted with its most sensitive data. One claimed their firewall rules -- even the client-specific ones designed to guard my specific set of hosted data -- were private and could not be shared, even under NDA. Another was slightly more open and agreed to share their security-related operational procedures under NDA, but not in electronic form. My question to each supplier was, when an employee leaves (it would have been plain mean to ask about role changes and internal transfers), do they change their firewall rules or their ops playbooks because of the departure?

Don't get me wrong: I think that withholding certain information is a useful, often necessary, secondary defense. We put locks on doors to keep the riff-raff out; but when that sketchy roommate finally moves out (and becomes the riff-raff), we change the locks: changing it is the logical thing to do to a valuable secret when someone who has had access to it becomes untrusted. It's why we still change our passwords periodically, even though forced change is, in this day and age, the weakest of the sundry defenses we put around passwords (more on that later). This, to me, is the easy litmus test of whether an obscurity defense is appropriate. If you're prepared to change the locks when someone who has had the keys moves out, having locks make sense. If you're not, your risk model is flawed and I as your security-conscious customer will be asking you why.

Gratuitous FUD

Thu, 30 Sep 2010 22:08:05 -0400

I read the back-to-the-future Wired article about the FBI's proposed encryption backdoors with great interest this week. Jim Dempsey, the West Coast director of the Center for Democracy and Technology, is quoted throughout the article. That's good. Dempsey correctly points out the debacle that came out of the last time this issue made its way through Congress. The Clipper chip was, of course, shown to have breakable crypto and the initiative ultimately failed. Dempsey was doing quite well until he decided to go a bit overboard on the Clipper vulnerabilities:

...there are 10,000 people who can do what he did, and my worry is half of them work for Moldovian criminal hacker groups

Doing the quick math, that means that there are 5,000 qualified cryptographers working for the Moldovian mob. While I can assure you that I am in no way connected, I am willing to speculate that a well-organized, middle-of-the-road Eastern European crime outfit employs two, maybe three good cryptographers, on average of course.

Thing is, we in the information security trade don't need to make up bogeymen from Chişinău to convince people to make the right choices. Are Moldovan criminal hacker groups really the greatest threat that keeps the CfDaT up at night about the FBI's backdoor proposal? What about the fact that the development of strong encryption (i.e. SSL) was the advance that gave consumers the confidence they previously lacked to conduct commerce on the Internet? Or about the challenges of finding appropriate oversight for the key keepers?

While most of us in InfoSec don't have the heavy burden of convincing Congress to make good decisions, we each have savvy CIOs, CTOs and data owners to influence. They know FUD when they see it, and we need to retain our credibility for the next debate - and we all know there's going to be a next debate.

Lightning Strikes part II -or- getting the most from your $1500

Sat, 18 Sep 2010 22:16:00 -0400

In a previous post, I wrote about the challenge of using traditional ALE models, favored by insurance companies and CISSP curricula, in information security settings -- especially as a decision-enabling input to the constant when-to-patch debate. Having covered the impact half of the [ impact x opportunity ] risk evaluation equation, it's time to devote some attention to the other. Why do risk owners struggle with the "opportunity" question when choosing which threats to mitigate and which adversaries to outspend?

Even when we have good information, people still fall into a variety of risk assessment traps. David Brooks' excellent post-Deepwater-Horizon New York Times article highlights six common risk management mistakes we all struggle to avoid:

inability to imagine how small failings can combine to lead to catastrophic disasters
acclimation to risk
elaborate faith in backup systems and safety devices
matching complicated technical systems with complicated governing structures
spreading good news and hiding bad news
groupthink

Two potential risks that gained mainstream attention this summer crystallized the phenomenon for me. In both cases, I had friends and coworkers asking me for opinions on emerging risks: one was the imbroglio between RIM and various countries' governments over the ability to decrypt Blackberry messaging traffic; the other was an academic paper revealing attacks against the wireless tire pressure sensors that were mandated for all cars, somewhat ironically, after the Firestone tire recalls of 2000.

In the case of RIM, the maker of Blackberry smart phones, I began receiving concerned notes from friends and execs last month. One asked if we should stop using our phones due to data privacy concerns over several governments (including India's and UAE's) potentially being granted access to decrypt Blackberry communications. Having looked into the various possible scenarios and outcomes, I was able to set their minds at ease.... somewhat. The potential, new risks to corporate enterprises were far greater if a compromise was not reached. If RIM did not cooperate, the availability risk would be considerable: a RIM outage that forced enterprises to hurriedly switch wireless providers would turn into a coordination nightmare for IT, sourcing, finance, and of course all those end users. Taken to the logical extreme, there could be a potential physical safety issue for travelers who suddenly lost phone service while abroad. Conversely, a compromise by RIM did not feel like a material increase in confidentiality or integrity risk; governments already have a technique for acquiring the contents of otherwise confidential messages, one far simpler to implement than cracking RIM's encryption: the good, old-fashioned subpoena.

My recommendation to my friends and execs was to worry less about their smartphones, and more about their cars. While the headlines this summer focused on silly boffins rickrolling their cars' check engine lights, the actual guts of the paper revealed something far more troubling:

Once the researchers had gained access, they developed a number of attacks against their target vehicles, and then tested many of them while the cars were being driven around an old airstrip. Successful attacks ranged from the annoying -- switching on the wipers and radio, making the heater run full blast, or chilling the car with the air conditioning -- to the downright dangerous. In particular, the brakes could be disabled. The ignition key could then be locked into place, preventing the driver from turning the car off.

The opportunity barrier to executing this sort of attack? $1500, according to the coverage by Ars Technica. Coincidentally, that is approximately the same cost barrier as the IMSI catcher developed by Chris Paget to demonstrate call-interception weaknesses in the 2G technology still used by several major cellular carriers in the US. This comes on top of recent advances in breaking the A5/1 algorithm behind the GSM technology that encrypts most cellular phone calls today.

Alas, automobile makers have been slow to reap competitive advantage by differentiating their products from their competition's. Since the publication of this story, I have seen two ads using indie bands unnecessarily covering 70's rock classics to hawk Lincolns -- and zero promoting resistance to, in the researchers' words, the ability to "monitor and control our car remotely over the Internet."

Episodes like these cause me to come back to the Brooks article time and again. What causes risk owners to worry about outspending a potential government adversary with a legal trump card, but not to give strategic sourcing preference to a cellular provider that is no longer using crackable GSM technology to transmit confidential company calls? Understanding how the risk owners that we need to influence think helps InfoSec practitioners give them decision-enabling information about impact and opportunity. We, too, have our own trap to avoid: assuming that, because our risk-owning partners understand that they need to patch their Windows systems monthly for bugs that have been latent in the OS since (in the case of XP) the late 1990's, they will apply the same urgency and logic to the latest authorization bypass in their middleware or SQL injection bug in their home-grown application.