Emergent Chaos

Va Pbaterff Nffrzoyrq, Whyl 4 1776

My usual celebration of Independence day is to post, in its entirety, the Declaration of Independence. It's very much worth reading, but this year, there's a little twist, from a delightful story starring Lawren Smithline and Robert Patterson, with a cameo by Thomas Jefferson. Patterson sent Jefferson a letter which read, in part:

“I shall conclude this paper with a specimen of such writing,” he boasted, “which I may safely defy the united ingenuity of the whole human race to decypher to the end of time….”

Well, perhaps it didn't last until the end of time, but the cipher apparently lasted until now, which is pretty darn good. There's an article in Harvard Magazine, and one in American Scientist, but it's behind a paywall. Finally, the Wall St Journal has an article, which mentions, both without linking to either.

I think what I really like about this story is how a mathematician bothered to send his new ciphertext to the author of Virginia's statue on religious liberty (as our third President preferred to be remembered). Having just finished Steven Johnson's very enjoyable "The Invention of Air," I'm struck by how broadly engaged with science and the useful arts the founders were. I think that sending an encrypted letter to President Obama would get you ... well, I don't really want to think about it, having just read the Declaration.

Torture is a Best Practice

I was going to title this "Painful Mistakes: Torture, Boyd and Lessons for Infosec," but then decided that I wanted to talk about torture in a slightly different way.

The Washington Post reports that "Detainee's Harsh Treatment Foiled No Plots" and [UK Foreign & Commonwealth Office] Finally Admits To Receiving Intelligence From Torture. From the Post story:

When CIA officials subjected their first high-value captive, Abu Zubaida, to waterboarding and other harsh interrogation methods, they were convinced that they had in their custody an al-Qaeda leader who knew details of operations yet to be unleashed, and they were facing increasing pressure from the White House to get those secrets out of him.

The methods succeeded in breaking him, and the stories he told of al-Qaeda terrorism plots sent CIA officers around the globe chasing leads.

In the end, though, not a single significant plot was foiled as a result of Abu Zubaida's tortured confessions, according to former senior government officials who closely followed the interrogations.

The torture committed in our names undermines our claim to moral superiority. It doesn't demolish it completely. Intentional mass murder of civilians is worse, but in war, you don't want to have such arguments. You want to clearly have a right side and a wrong side, and torture usually sets you on the wrong side. Boyd laid out conflict as happening in a moral-mental-physical atmosphere, with moral being the most important. If you don't have a moral claim to rightness, then your side's mental willingness to fight for the cause is subject to alienation through propaganda. (This is why Al Qaeda shows so many videos of Guantanamo, Abu Ghraib, etc.) More on this in Chuck Spinney's When Strategic "Genius" is Mortal Blunder."

So why do people commit acts of torture? It's because they believe that it works, and under the ticking time bomb theory, it's the lesser evil. That what counts is "why the President thinks he needs to do that."

There are two arguments against torture, the moral and the practical. Both are outlined in the articles cited at the top. I'd now like to turn back to the idea of best practices.

Best practices are ideas which make intuitive sense: don't write down your passwords. Make backups. Educate your users. Shoot the guy in the kneecap and he'll tell you what you need to know.

The trouble is that none of these are subjected to testing. No one bothers to design experiments to see if users who write down their passwords get broken into more than those who don't. No one tests to see if user education works. (I did, once, and stopped advocating user education. Unfortunately, the tests were done under NDA.)

The other trouble is that once people get the idea that some idea is a best practice, they stop thinking about it critically. It might be because of the authority instinct that Milgram showed, or because they've invested effort and prestige in their solution, or because they believe the idea should work.

The next time someone suggests something because it's a best practice, ask yourself: is this going to work? Will it be worth the cost?

Mr Laurie - Don't do that

Ben Laurie has a nice little post up "More Banking Stupidity: Phished by Visa:"

Not content with destroying the world’s economies, the banking industry is also bent on ruining us individually, it seems. Take a look at Verified By Visa. Allegedly this protects cardholders - by training them to expect a process in which there’s absolutely no way to know whether you are being phished or not. Even more astonishing is that this seen as a benefit!

Ben's analysis seems pretty good, except for one thing--he doesn't say anything about what to do. Right now, we can see that organizations are flailing around, trying to address the problem. And pointing out problems can be helpful, "you're wrong" is a pet peeve of mine. (While, Michael Howard's really, but I've adopted it.)

So Mr Laurie, don't do that. Don't just say what not to do. Say what to do.

The security engineering community needs to come together and speak out on what the right design is. I'm going to ask Ben, Gunnar Peterson, Rich Mogull and Mike Dahn to ask what should we do? Can the four of you come to agreement on what to recommend?

(My recommendation, incidentally, stands from August 2005, in the essay "Preserving the Internet Channel Against Phishers." Short version: bookmarks, although I need to add, empower people to use the bookmarks by giving them a list of pending actions from the login landing page.)

Photo: "The Matt Malone experience"

[Update: edited title. Thanks, @mortman. Update 2: Fixed Mike Dahn's URL; Firefox still not happy, I don't think I can fix the post URL.]

Joseph Ratzinger and Information Security

Joseph Ratzinger (a/k/a Benedict XVI) made some comments recently made some comments that got some press. In particular, as Reuters reports: "Pope in Africa reaffirms 'no condoms' against AIDS." Quoting the story, "The Church teaches that fidelity within heterosexual marriage, chastity and abstinence are the best ways to stop AIDS."

Many of you are likely outraged. Saying, "sure, if only people would do that, then we wouldn't need condoms. But people don't behave that way."

I'd like to explain what this has to do with information security. Some of you may be saying "sure, but we're not that bad."

In information security, we often keep saying the same thing over and over again, because we know it's right. We tell people to never write down their passwords, to always validate their input, and to run IDS systems. Deep in our hearts, we know they don't, and yet we keep saying those things. We tell them they "have to" fix all the security problems all the time.

It's my hope that we in information security will be less religious than the Pope, but there's plenty of evidence that, like him, we offer advice that makes people shake their heads in disgust.

Wherever you work, whatever you do, it's worth asking yourself: am I being dogmatic in what I'm asking of people?

Me, I'm being dogmatic about asking you all to keep it civil in the comments.

"No Evidence" and Breach Notice

According to ZDNet, "Coleman donor data breached in January, but donors alerted by Wikileaks not campaign:"

Donors to Minnesota Senator Norm Coleman’s campaign got a rude awakening this week, thanks to an email from Wikileaks. Coleman’s campaign was keeping donor information in an unprotected database that contained names, addresses, emails, credit card numbers and those three-digit codes on the back of cards, Wikileaks told donors in an email.

and

We contacted federal authorities at that time, and they reviewed logs from the server in question as well as additional firewall logs. They indicated that, after reviewing those logs, they did not find evidence that our database was downloaded by any unauthorized party.

I wanted to bring this up, not to laugh at Coleman (that's Franken's job, after all), but because we frequently see assertions that "there's no evidence that..."

As anyone trained in any science knows, absence of evidence is not evidence of absence. At the same time, sometimes there really is sufficient evidence, properly protected, that allows that claim to be made. We need public, documented and debated standards of how such decisions should be made. With such standards, organizations could better make decisions about risk. Additionaly, both regulators and the public could be more comfortable that those piping up about risk were not allowing the payers to call the tune.

What Was Wrong With the Old FISA?

The Get FISA Right group is publicizing our need to re-think the laws. They have discussion going on on their site, as well as on The Daily Kos. I recommend catching up there, or reading Adam's recent post here.

I have to ask what was wrong with the old FISA? It wasn't a bad system, had a lot tradeoffs as well as emergency provisions. The government could, for example, get a warrant after the fact in an emergency.

But the old FISA was very Cold War. It was also very much adapted to the previous century's technology in which wired technologies were static and protected and wireless or mobile technologies were highly regulated.

So let's look at some of the things that are indeed worth changing.

• I think it is important to note upfront that getting a warrant trumps all this discussion. We are talking about Fourth Amendment considerations, and that means what can be done without a warrant. But it also concerns a certain amount of how the government can operate when it has one, when they're operating completely above board.

• In the past, FISA was overly concerned with devices rather than persons. Changing it so that it affects persons is a good idea. If there is permission to spy on a person, then it should be to spy on the person. Making it the person and device is awfully restrictive, especially when it's hard to know what counts. Rather than debate about what happens when DHCP gives you a new address, it's better to just make things apply to persons. That probably makes the law adapt better to changing technology.

  I would not want end up having interesting new technologies like femtocells end up in some odd legal limbo because of some peculiarity of the technology. It's better for us all to just agree that when it is okay to spy on a person, it's that person.

• In the past, FISA worried a lot about about where the pipes were. It also seems reasonable to have that abstracted away. This goes along with focusing on the persons. A phone call between non-US persons does not suddenly become a US thing just because some glass runs across the US.

  Now, this has consequences. I wouldn't blame non-US telecom companies to proudly avoid the US as a result of that. It's from the viewpoint of a civil libertarian who is trying to make sense out of the rules of spying that I think that.

  It is also the converse of thinking that when I am in another country, they'll spy on me or not according to their rules, not mine.

• The flip side of this is that US persons are protected everywhere. It seems fair that if we're going to tune the law to make it easier to spy on non-US persons no matter where they are, the US persons should get full protection. This strikes me as being the way that things ought to be. My government shouldn't spy on me (without a warrant) just because I'm traveling outside the country. This may be as things ought to be, but it used to be at least de facto that if you were outside the country, your calls would be monitored.
• It is a point of our common law that non-US persons are subject to US law when they are in the US. If a foreigner is arrested in the US, they get a jury trial, for example. In this particular case, however, non-US persons in the US should have some extra measure of protection, the question is what.

I can go on, particularly about the new features of the new FISA. However, that strays away from this discussion. What didn't work well in the old one.

"A Scientific R&D Approach to Cyber Security"

Charlie Catlett, CIO of Argonne National Labs has released a report on "A Scientific R&D Approach to Cyber Security" (Powerpoint summary, community wiki).

It's a very interesting report. There's a lot to agree with in terms of a research agenda. They're looking to compose trustworthy systems from untrusted components, to create self-protective data and software, and to use mathematicsc for predictive awareness for secure systems.

I have two issues with it, one small and one large. The small issue is that the report places mathematics on a pedestal, and goes so far as to refer to economic analysis as a 'metaphor.' Mathematics is clearly quite useful, but the problems we experience are often no longer mathematical, but about the meaning of things, and that is a human problem.

Much bigger is that in all the discussions of bringing to bear the power of science, there's no mention of the data acquisition problem. That is, you can do all the modeling you want, but if you're not gathering rich data sets about what goes wrong, you can't test those models or craft informed hypotheses.

I applaud Catlett for seeing the need for real science, and hope that the future research agenda will involve partnerships with those who handle the human side of computer security, as well as joining the New School call for more and more data.

A few Heartland links

Well, Mordaxus got the story, but I'll add some links I found interesting or relevant.

StoreFront BackTalk has From The Heartland Breach To Second Guessing Service Providers. Dave G at Matasano added "Heartland's PCI certification." The Emergent Chaos time travel team already covered that angle in "Massachusetts Analyzes its Breach Reports:"

What's exciting about this is that we're seeing the PCI standard being tested against empirical data about its effectiveness. Admittedly, the report jumps to conclusions from a single data point, but this is new for security. The idea that we can take a set of "best practices" and subject them to a real test is new.

Rich Mogull points out that:

This was also another case that was discovered by initially detecting fraud in the system that was traced back to the origin, rather than through their own internal security controls.

IDS users, vendors or advocates care to comment on why that's happening?

Breach Misdirection

While we were all paying attention to the Inauguration and having merry debates about how many Justices can deliver the Oath of Office on a pin, what may be the biggest breach ever tried to tiptoe past.

Heartland Payment Systems may have lost 100 million credit card details, surpassing the 94 million that was lost in the TJX breach.

There aren't many details, yet. Apparently the hackers were on the network for months, having gotten in through malware.

We will of course hear many more details on this. The USA Today article has some news. AP has the best reporting I've read, but they are ambivalent about pixels, so you'll have to find it on your own.

Rethinking Risk

Now it's no secret to those of you who know me that I'm a big believer in using risk management in the security space. Iang over at Financial Cryptography think's it is "a dead duck":

The only business that does risk management as a core or essence is banking and insurance (and, banking is debatable these days). For all others, risk management is just an ancilliary aspect, a nice-to-have, something that others say is critical to you, but you ignore because you've got too much to do. So we have a choice: is security like finance, or is it like "the rest of business?"

I disagree while it's true that financials and insurance have done a much better job then anyone else of formalizing their risk management practices, every business does risk management to some degree, it's part of the job of the C-Suite. Arguing that we don't have data so trying to do it in security is pointless is taking the lazy way out. It's true we don't have as much data as we'd like, but as Hubbard said, (more or less) "You don't need as much data as you think, and you have more data then you think." or in other words, we have to start somewhere.

On a related note, The Economist ran an article at the beginning of this year, from which I took the title of this post "Rethinking Risk.

What makes the current situation so dire is the way in which so many major risks are converging all at once: a credit crisis, volatile commodity prices, soaring government debt, rising unemployment and its attendant impact on consumer spending — the list goes on.

None of those risks are lost on CFOs, of course, who now have an additional impetus to address them: more pressure from boards. Corporate directors in most industries have gotten risk religion, says Henry Ristuccia, U.S. leader of Deloitte's governance and risk-management practice in the Northeast. "More external directors are asking senior management: What are the company's major risk issues? What are the dimensions of governance and risk management? What levers and tools does the company have in place for risk management?

Now, The Economist doesn't explicitly talk about security but as several companies including Hannaford and TJ Maxx learned, just because you're not in the finance industry doesn't mean you don't face significant financial or security risk. A shame neither of them had real risk management in place.

Checking in on the Security of Chequing

I remember a conversation back in 1995 or 1996 with someone who described to me how the Automated ClearingHouse (ACH) for checking worked. He explained that once you had an ACH merchant account, you sent in a message of roughly the form (src, dest, amount, reason) and money got moved. I argued with him that this was inconceivable (yeah, yeah), and he must be mis-understanding. He assured me that no, he was right, and that the reason they ran this way was because it was cheaper, and because only trustworthy people could get ACH merchant accounts.

Fast forward a few years, to a fellow who sends out cheques for bugs:

Leading banks and investment funds have been foundering, because of bad debts and lack of trust; and other, less well-known kinds of fiscal chaos are also on the horizon. For example, due to an unfixable security flaw in the way funds are now transferred electronically, worldwide, it is no longer safe to write personal checks. A criminal who sees the numbers that are printed at the bottom of any check that you write can use that information to withdraw all the money from your account. He or she can do this in various ways, without even knowing your name --- for example by creating an ATM card, or by impersonating a bank in some country of the world where safeguards are minimal, or by printing a document that looks like a check. The account number and routing information are all that international financial institutions look at before deciding to transfer funds from one account to another. (Donald Knuth, "Financial Fiasco.")

The Skype Issue

According to The New York Times in, "Surveillance of Skype Messages Found in China," the Chinese provider TOM has software in place that reads Skype text messages, and blocks ones that use naughty words and terms, like "Falun Gong," "Independent Taiwan," and so on.

A group of security people and human rights workers not only found out that TOM-Skype is not secure, but found the list of banned words because, as usual, someone didn't set up their servers very well. A report can be found here.

Skype president Josh Silverman replied to the issue today in this article. He says that yes, it's happening:

It is common knowledge that censorship does exist in China and that the Chinese government has been monitoring communications in and out of the country for many years. This, in fact, is true for all forms of communication such as emails, fixed and mobile phone calls, and instant messaging between people within China and between China and other countries. TOM, like every other communications service provider operating in China, has an obligation to be compliant if they are to be able to operate in China at all.

He's right: one of the quandaries of business in China is that you have to put your belief in freedom in a trust when you go there. This is why many of us do not like doing business there.

However, he also said:

We also learned yesterday about the existence of a security breach that made it possible for people to gain access to those stored messages on TOM's servers. We were very concerned to learn about both issues and after we urgently addressed this situation with TOM, they fixed the security breach. In addition, we are currently addressing the wider issue of the uploading and storage of certain messages with TOM.

In other words -- it's bad for the Chinese to spy, and bad for people to catch them at it. Oh, naughty Chinese, and shame on you too, Infowar for dragging this into the daylight.

This comes on top of April's flap in which the German and Austrian governments essentially said that they have no trouble listening in to Skype. Skype hasn't commented on that. This is a different issue, as it appears that the surveillance is being done via malware.

Despite the fact that we still don't know what goes on inside of Skype, it appears that the software is basically secure -- or at least the voice parts are. Or was at one time. The noted cryptographer Tom Berson did an analysis of Skype and showed that it was reasonably secure. There were also reverse-engineering analyses done on Skype by Philippe Biondi and Fabrice Desclaux, presented at Black Hat in 2006 that showed it was secure, if eccentric in its design.

However, despite the security of the voice parts, the text parts are obviously not secure. And we have this uncomfortable set of circumstances:

• Skype voice, while apparently secure in architecture, can be compromised by commercially available malware.
• Skype text chat is obviously not secure, as shown by TOM-Skype in China.
• Josh Silverman has washed his hands of l'affaire TOM-Skype.
• We still don't know what's in the Skype source code.

The problem here is one of labeling, and the market effects. I'm sophisticated enough to know that when Josh Silverman says:

... Allowing the world to communicate for free empowers and links people and communities everywhere.

that he is stating that free (as in beer) is important, even if he's unable to do a lot about free (as in speech) in repressive countries and in the face of law enforcement technologies.

But Skype has always touted itself as a secure technology. The reason that it became popular for free (as in beer) conversations was that we thought and were assured that it was also free (as in speech). Skype themselves paid for a security analysis.

Skype thus became not only the proverbial eight-hundred pound gorilla, but (it seems) the proverbial dog in the manger. Skype's presence has actively hindered other secure-voice technologies. Phil Zimmermann's Zfone, for example, has had to answer the question, "why do we need you when there's Skype?" It seems that he'll be answering that question less. Josh Silverman needs to do something to show us the basic integrity of the system. Presently it appears that he has empowered us to have communities everywhere but China, or Germany, or any place with a sophisticated and powerful government. At the very least, he should protect eBay's investment, because if people conclude that Skype is not secure, eBay may wish they'd invested that $1.6 billion in mortgage-backed instruments instead.

Regulations, Risk and the Meltdown

There are obviously a large set of political questions around the 700+ billion dollars of distressed assets Uncle Sam plans to hold. If you care about the politics, you're already following in more detail than I'm going to bother providing. I do think that we need to act to stem the crisis, and that we should bang out the best deal we can before the rest of the banks in the US come falling like dominos. As Bagehot said, no bank can withstand a crisis of confidence in its ability to settle. I think that knowing how distasteful and expensive it is, and with far better things to do with the $5,000 or so it will personally cost me as a taxpayer. (That $2,300 figure is per person.) I also think that knowing how poorly this administration has done in handling crisis from 9/11 to Katrina, and how poorly it does when forced to act in a moment of crisis. (Sandy Levinson has some interesting comments at "A further Schmittian (and constitutional?) moment.") Finally, we are not bailing out the banks at the cost of a free market in banking. We gave up on a free market in banking in 1913 or so, after J.P. Morgan (not his eponymous bank) intervened to fix the crises of 1895 and 1907.

What I did want to look at was the phrase "more regulation," and relate it a little to information security and risk management.

US banks are already intensely regulated under an alphabet soup of laws like SOX, GLB, USA PATRIOT and BSA. They're subject to a slew of additional contractual obligations under things like PCI-DSS and BASEL rules on capital. And that's leaving out the operational sand which goes by the name AML.

In fact, the alphabet soup has gotten so thick that there's an acronym for the acronyms: GRC, or Governance, Risk and Compliance. Note that two of those three aren't about security at all: they're about process and laws. In the executive suite, it makes perfect sense to start security with those governance and compliance risks which put the firm or its leaders at risk.

There's only so much budget for such things. After all, every dollar you spend on GRC and security is one that you don't return to your shareholders or take home as a bonus. And measuring the value of that spending is notoriously hard, because we don't share data about what happens.

Just saying that measurement is hard is easy. It's a cop out. I have (macro-scale) evidence as to how well it all works:

• Bear Stearns
• Fannie Mae
• Freddie Mac
• Lehman Borthers
• AIG
• Washington Mutual
• Wachovia
• (Reserved)

I have a theory: in competition for budget within GRC, Governance and Compliance won. They had better micro-scale evidence as to their value, and that budget was funded before Risk was allowed to think deeply about risks.

There's obviously immediate staunching to be done, but as we come out of that phase and start thinking about what regulatory framework to build, we need to think about how to align the interests of bankers and society.

If you'd like more on these aspects, I enjoyed Bob Blakley's "Wall Street's Governance and Risk Management Crisis" and Nick Leeson, "The Escape of the Bankrupt" (via Not Bad for a Cubicle. Thurston points out the irony of being lectured by Nick "Wanna buy Barings?" Leeson.)

I'm not representing my co-author Andrew in any of this, but at least as I write this, his institution remains solvent.

Blaming the Victim, Yet Again

John Timmer of Ars Technica writes about how we ignore dialog boxes in, "Fake popup study sadly confirms most users are idiots."

The article reports that researchers at the Psychology Department of North Carolina State University created a number of fake dialog boxes had varying sorts of clues that they were not real dialog boxes, but sham ones. The sham dialog boxes had varying levels of visual clues to help the user think they were sham. One of the fake dialogs is here:

The conclusion of many people is summed up in the title of the Ars Technica -- that people are idiots.

My opinion is that this is blaming the victim. Users are presented with such a variety of elements that it's hard to know what's real and what's not. Worse, there are so many worthless dialogs that pop up during normal operation that we're all trained to play whack-a-mole with them.

I confess to being as bad as anyone. My company has SSL set up to the mail server, but it's a locally-generated certificate. So every time I fire up the mail client, there's a breathless dialog telling me that the certificate isn't a real certificate. Do you know what this has taught me? To be able to whack the okay button before the dialog finishes painting.

The idiots are the developers who give people worthless dialog boxes, who make it next to impossible to import in local certificates, who train people to just make the damned dialog go away.

Computing isn't safe primarily because the software expects the user to be a continuously alert expert. If the users are idiots, it is only because they stand for this.

Help fund historic computers at Bletchley Park

Bletchley Park, the site in the UK where WWII code-breaking was done, has a computing museum. The showpiece of that museum is Colossus, one of world's first computers. (If you pick the right set of adjectives, you can say "first." Those adjectives are apparently, "electronic" and "programmable.") It has been rebuilt over the last fourteen years by a dedicated team, who have managed to figure out how it was constructed despite all the plans and actual machines having been dismantled.

Of course, keeping such things running requires cash, and Bletchley Park has been scrambling for it for years now. The BBC reports that IBM and PGP have started a consortium of high-tech companies to help fund the museum, starting with £57,000 (which appears to be what the exchange rate is on $100,000). PGP has also set up a web page for contributions through PayPal at http://www.pgp.com/stationx, and if you contribute at least £25 (these days actually less than $50), you get a limited-edition t-shirt complete with a cryptographic message on it.

An interesting facet of the news is that Bletchley Park is a British site and the companies starting this funding initiative are each American companies. Additionally, while PGP is an encryption company and thus has a connection to Bletchley Park as a codebreaking organization, one of the major points that PGP and IBM are making is that Bletchley Park is indeed a birthplace (if not the birthplace) of computing in general.

This is an interesting viewpoint, particularly if you consider the connection of Alan Turing himself. Turing's impact on computing in general is more than his specific contributions to computers -- he was a mathematician far more than an engineer. He was involved in designing Colossus, but the real credit goes to Tommy Flowers, who actually built the thing.

If we look at the history of computing, an interesting thing seems to have happened. The Allies built Colossus during the war, and then when the war ended agreed to forget about it. The Colossi were all smashed, but many people involved went elsewhere and took what they learned from Colossus to make all the early computers that seemed to have names that end in "-IAC."

(A major exception is the work of Konrad Zuse, who not only built mechanical programmable computers before these electronic ones, but some early electronic ones, as well.)

This outgrowth from Colossus also seems to include the work that turned IBM from being a company that primarily made punched cards and typewriters to one that made computers. It is thus nice to see IBM the computing giant pointing to Colossus and Bletchley as a piece of history worth saving along with the cryptographers at PGP. It is their history, too.

I think this dual parentage makes Bletchley Park doubly worth saving. The information economy has computers and information security at its core, and Colossus sits at the origins of both. Please join us in helping save the history of the information society.

Risk Managers Are Just Like Security People

Or is that vice-versa? A few weeks ago, Security Retentive posted about an article in the Economist: "Confessions of a Risk Manager". Both his analysis and the original story are quite interesting and I encourage you to read them as well as a letter to the editor that was published in last week's print edition of the Economist. In "Risky Business", David Howat, a self described past risk manager share his thoughts on the roles of risk managers:

Risk managers can’t do a proper job if they aren’t part of the team that develops the proposal. They are enablers, not gatekeepers: their job is to ensure that each new transaction, product and service is developed with safety as well as profitability in mind. Weaknesses need to be identified early so that, if they can’t be corrected, the proposal can be dropped before anyone gets too attached to it.

Sounds familiar doesn't it? I can't count the number of times I've used a similar argument for security being involved from the beginning. It's heartbreaking to hear that an industry that's been around much longer then ours is still fighting the same battles. Yet on the plus side, it's yet another group that we can learn from to improve our own stance and hopefully avoid making some of the same mistakes. Time to go re-read the original article again.

Signal Boosting Amrit Williams

File this under "Posts I Wish I'd Written". Amrit Williams' "
The 7 Greatest Ideas in Security," really highlights a lot of my basic thoughts on how security should work. His conclusion sums things up cogently, but go read the entire post:

Some may argue that something has been forgotten or that the order is wrong, but I would argue that we must learn to develop securely, implement the proper security controls, verify the functioning of these controls, leverage the research of the greater community, ensure that what cannot be protected is hidden, and from the beginning to the end properly plan, prepare, and set the right expectation - these are the greatest ideas in security and if we learn to embody these principles, we would be moving the industry forward as opposed to constantly feeling like we can only clean up the incompetence that surrounds us.

Also, extra points for the great turn of phrase "Inspect What You Expect".

Write Keyloggers Professionally!

GetAFreelancer.com has a job for you if you need some high-paid work -- write a remote keylogger.

Here are the project requirements:

We need a keylogger that can be installed remotely.

Description:
The main purpose is that the user A can send an email with a program to install (example: a game or a funny program) to the person B. When the person B install the program on his computer, he is installing at the same time an invisible keylogger on his computer. Then the person A is receiving the report by email of every keystrokes that the person B is doing on his computer.

They only want to pay $250 to $750, which seems fair given that the requirements don't include undetectability. For that low a contract price, it seems only fair to give the victim a fighting chance.

Photo "Keylogger 1.0 Beta" by soulrift.

Privacy Enhancing Technologies and Threat Modeling

Steven Murdoch and Robert Watson have some really interesting results about how to model the Tor network in Metrics for Security and Performance in Low-Latency Anonymity Systems (or slides). This is a really good paper, but what jumped out at me was their result, which is that the right security tradeoff is dependent on how you believe attackers will behave. This is somewhat unusual in two ways: first, it implies the need for a dynamic analysis, and second, that analysis will only function if we have data.

We often apply a very static analysis to attackers: they have these capabilities and motivations, and they will stick with their actions. This paper shows a real world example of a place where as attackers get more resources, they will behave differently, rather than doing more of what they did before. So actually operating a secure Tor system requires an understanding of how certain attackers are behaving, and how they choose to attack the system at any given time.

There's a sense in which this is not surprising, but these dynamic models rarely show up in analysis.

Call Centers Will Get More Annoying

There's an article in "destination CRM," Who's Really Calling Your Contact Center?

...the identity questions are "based on harder-to-steal information" than public records and credit reports. "This is much closer to the chest than a lot of the public data being used in other authentication systems," she says, adding that some companies using public data include Acxiom, ChoicePoint, and LexisNexis. Higginson gives the example of asking someone the birth date of an individual who used to share an address with him. "There is no public data source to have a question like that answered," Higginson says, arguing that it would take multiple documents to try and piece together exactly who the other individual is, where she lives now, verify that she did at one time share an address with the caller -- and then still have to verify her birth date.

A couple of comments:

• This seems tremendously intrusive. I don't want some random call center drone to think they know "everything" about me, to quiz me about my life, or to tell me that I'm wrong if I disagree with their database.
• This perpetuates the idea that we are our data shadows. I'm not a line in a database. I am a living, breathing person.
• Errors in databases, such as those created by ID theft become more damaging to both the customer and your relationship with them.
• The data being used is likely something like Choicepoint's Bridger Insight (PDF). Quoting the press release:

  ProID Quiz lets users authenticate customers’ and prospects’ identities with greater certainty. Prior to servicing an account or conducting a transaction, a customer service representative can generate a “quiz” composed of random, multiple-choice questions. The questions are based on “out of wallet” information such as former roommates or one’s previous home builder.

  So access to the Choicepoint database becomes even more valuable to thieves.

A company which deploys these sort of things will lose me as a customer. As Debix points out, your real customer knows who they are. Involve them via multi-factor or multi-channel communications.

More generally, this seems like it would be symptomatic of a company that had lost sight of their customers. Who stops and thinks, "what our customers really want is to be interrogated. That will make them feel better?"

Putting the fun back in threat modeling

I have an article in the latest MSDN magazine, "Reinvigorate your threat modeling process:"

My colleague Ellen likes to say that everyone threat models all the time. We all threat model airport security. We all threat model our homes. We think about threats against our assets: our families, our jewelry, and our sentimental and irreplaceable photographs (well, those of us old enough to have photos that never existed in digital form do). We model threats based on architecture: there's a wall here, a picture window there, and an easily climbed tree that we can use when we forget our keys. And we model threats based on attackers. We worry about burglars and kids falling into pools. We also worry about the weather, be it earthquakes, snow, or tornadoes.

If I wanted to sound like a management consultant, I'd say you employ a mature, multi-dimensional assessment process, with a heavy reliance on heuristics and low reproducibility across instances. At the same time, it's likely you won't have thought of everything or implemented defenses against every possible attack. It's very unlikely you have a home defense management plan or have ever run a penetration test against your home.

There's a lot in there talking about how and why some threat modeling methods became "heavy" and what to do about it. Underlying that is the start of a way of thinking about threat modeling as a family of related activities, and some ways of breaking that down. In particular, there's a breakdown into asset-centric, architecture-centric, and attacker-centric threat modeling, which I think is a useful step forward.

What works for you in threat modeling? What hasn't worked that you needed to replace?

Massive Coordinated Vendor Patch For DNS

Dan "Doxpara" Kaminsky today released information about a fundamental design flaw in the architecture of DNS which if properly exploited would allow a malicious party to impersonate any website they wanted to. This issue effects every single version of DNS. The flaw primarily effects the DNS server but it can also effect clients as well in certain scenarios. Patches are available or will be available soon from Microsoft, Sun, ISC and Cisco to name just a few. Due to the potential risks of this vulnerability details of the vulnerability are not being currently released. In order to allow users time to patch, Dan will not release full details until Blackhat 2008. What I do know at this point is that the flaw allows a malicious party to poison dns caches and that the fix improves the situation by increasing the level of randomness of port selection. Dan has posted a widget on this website that allows users to check and see if their DNS servers are vulnerable or not. Feel free to throw out your theories as to the actual nature of the vulnerability or your feelings on whether or not this was responsible disclosure.

[Edit: More details from ISC and Microsoft.]

[Edit2: Transaction ID (16 bits of randomness) is not random enough. The patch also adds randomness to the source port and requires that both the source port and transaction id must match for a query to be considered valid.]

[Edit3: DJBdns is in fact not affected as DJB had already implemented port randomness even though he didn't know it was an issue.]

[Edit4: Executive Overview from securosis.]

[Edit5: More reading here via the crypto mailing list.]

[Edit6: And more reading: from djb and Paul Vixie.]
[Edit7: Matasano's Ptacek has peeked inside the kimono and says it's the real deal. -- cw]

On Banking Security

Dave Maynor comments:

Blizzard is going to sell a One Time Password device...Isn't it kind of funny when an online game has better security than most banks?

Blizzard Entertainment, Inc. today introduced an optional extra layer of security for World of Warcraft®, its award-winning massively multiplayer online role-playing game. Designed to attach to a keychain, the lightweight and waterproof Blizzard® Authenticator is an electronic device that generates a six-digit security code at the press of a button. This code is unique, valid only once, and active for a limited time; it must be provided along with the account name and password when signing in to the World of Warcraft account linked to it.

Damnit, Dave, I have nothing to add to that analysis!

Study: Firefox patched quickest, IE a laggard

A new technical report out of ETH Zurich, Understanding the Web browser threat, should appeal to EC readers.

The authors were granted access to the USER-AGENT information recorded globally by Google between January2007 and June 2008. By examining the first visit per day by each browser, the authors are able to determine which clients were running which browser, and when. This allows them to calculate how long older versions continue to be used after being superseded by an update.

The results are interesting:

[F]rom January 2007 to June 2008,
most users updated to a new version of Firefox within three
days of a new public release, resulting in up to 83% of usershaving the most current and secure Firefox version installed.
It took users of the Opera Web browser an average of 11 days
before reaching an update saturation at a level of up to 56%
of the users running the most current and secure Opera version.
While Firefox and Opera check for updates when the
browser is used, Safari relies on an external Apple-updater
that appears to only poll for new updates at scheduled regular
intervals while Internet Explorer gets updated as part of the
monthly distributed Windows patches.

Whether "patch and pray" maximizes uptime is debatable, but for the home user auto-update of browsers seems to be a win (I'm sure Dean Shostack of the New School has some informed thoughts on this).

The paper makes some usability suggestions which may stir discussion.

All in all, a good paper which relies on solid empirical data but goes beyond the numbers and makes suggestions which are informed by an interdisciplinary awareness. The only missing element is the Kandinsky.

In the land of the blind..

Jeff Lowder takes PCI to the New School in "PCI DSS Position on Patching May Be Unjustified:"

Verizon Business recently posted an excellent article on their blog about security patching. As someone who just read The New School of Information Security (an important book that all information security professionals should read), I thought it was refreshing to see someone take an evidence-based approach to information security controls.

First, thanks Jeff! Second, I was excited by the Verizon report precisely because of what's now starting to happen. I wrote "Verizon has just catapulted themselves into position as a player who can shape security. That's because of their willingness to provide data." Jeff is now using that data to test the PCI standard, and finds that some of its best practices don't make as much sense the authors of PCI-DSS might have thought.

That's the good. Verizon gets credibility because Jeff relies on their numbers to make a point. And in this case, I think that Jeff is spot on.

I did want to address something else relating to patching in the Verizon report. Russ Cooper wrote in "Patching Conundrum" on the Verizon Security Blog:

To summarize the findings in our “Control Effectiveness Study”, companies who did a great job of patching (or AV updates) did not have statistically significant less hacking or malicious code experience than companies who said they did an average job of patching or AV updates.

The trouble with this is that the assessment of patching is done by

...[interviewing] the key person responsible for internal security (CSO) in just over 300 companies for which we had already established a multi-year data breach and malcode history. We asked the CSO to rate how well each of dozens of countermeasures were actually deployed in his or her enterprise on a 0 to 5 scale. A score of “zero” meant that the countermeasure was not in use. A score of “5″ meant that the countermeasure was deployed and managed “the best that the CSO could imagine it being deployed in any similar company in the world.” A score of “3″ represented what the CSO considered an average deployment of that particular countermeasure.

So let's take two CSOs, analytical Alice and boastful Bob. Analytical Alice thinks that her patching program is pretty good. Her organization has strong inventory management, good change control, and rolls out patches well. She listens carefully, and most of her counterparts say similar things. So she gives herself a "3." Boastful Bob, meanwhile, has exactly the same program in place, but thinks a lot about how hard he's worked to get those things in place. He can't imagine anyone having a better process 'in the real world,' and so gives himself a 5.

[Update 2: I want to clarify that I didn't mean that Alice and Bob were unaware of their own state, but that they lack data about the state of many other organizations. Without that data, it's hard for them to place themselves comparatively.]

This phenomenon doesn't just impact CSOs. There's fairly famous research entitled "Unskilled and Unaware of it," or "Why the Unskilled Are Unaware:"

Five studies demonstrated that poor performers lack insight into their shortcomings even in real world settings and when given incentives to be accurate. An additional meta-analysis showed that it was lack of insight into their errors (and not mistaken assessments of their peers) that led to overly optimistic social comparison estimates among poor performers.

Now, the Verizon study could have overcome this by carefully defining what a 1-5 meant for patching. Did it? We don't actually know. To be perfectly fair, there's not enough information in the report to make a call on that. I hope that they'll make that more clear in the future.

Candidly, though, I don't want to get wrapped around the axle on this question. The Verizon study (as Jeff Lowder points out) gives us enough data to take on questions which have been opaque. That's a huge step forward, and in the land of the blind, it's impressive what a one-eyed man can accomplish. I'm hopeful that as they've opened up, we'll have more and more data, more critiques of that data. It's how science advances, and despite some mis-givings about the report, I'm really excited by what it allows us to see.

Photo: "In the land of the blind, the one eyed are king" by nandOOnline, and thanks to Arthur for finding it.

[Updated: cleaned up the transition between the halves of the post.]

I'd bet on security prediction markets

In his own blog, Michael Cloppert writes:

Adam, and readers from Emergent Chaos, provided some good feedback on this idea. Even though the general response is that this wouldn't be a supportable approach, I appreciate the input! This helps me focus my research intentions on the most promising theories and technologies.

I'm glad my readers helped with good feedback, but I think he's taking the wrong lesson. The lesson should be that there are lots of skeptics, not that the idea won't work.

And Adam from InklingMarkets has offered to help.)

Haft of the Spear points to an Inkling market, "Group Intel" who are taking bets on bin Laden's being captured or killed before the end of Bush II. There have only been a few trades with hefty price swings, but why not try it out for infosec? Maybe some chaos would emerge.

(Incidentally, new, interesting comments are still coming in on "Security Prediction Markets: theory & practice.")

Password Validation

An amusing comic from POPsickleSTRIP.

Science isn't about Checklists

Over at Zero in a Bit, Chris Eng has a post, "Art vs. Science":

A client chastised me once for making a statement that penetration testing is a mixture of art and science. He wanted to believe that it was completely scientific and could be distilled down to a checklist type approach. I explained that while much of it can be done methodically, there is a certain amount of skill and intuition that only comes from practical experience. You learn to recognize that “gut feel” when something is amiss. He became rather incensed and, in effect, told me I was full of it. This customer went on to institute a rigid, mechanical internal process for web app pen testing that was highly inefficient and, ultimately, still relied mostly on a couple bright people on the team who were in tune with both the art and the science.

Certifications only test the science.

I want to disagree strongly. Science isn't about checklists. It's about forming and testing hypothesis. In the case of pen tests, you have an overarching hypothesis, "this thing is secure." You conduct experiments which demonstrate that hypothesis to be false. (Lather, rinse, repeat, you can't test security in.)

The design of good experiments is an art. Some people are better at it than others. Great science is driven by a small number of great scientists who have both a comprehension that something is wrong with today's theories, and a flair for great experiments which illuminate those issues.

The problem isn't science versus art, the problem is checklist and bureaucracy versus skilled professional.

Department of Justice on breach notice

There's an important new report out from the Department of Justice, "Data Breaches: What the Underground World of “Carding” Reveals." It's an analysis of several cases and the trends in carding and the markets which exist. I want to focus in on one area, which is recommendations around breach notification:

Several bills now before Congress include a national notification standard. In addition to merely requiring notice of a security breach to law enforcement,200 it is also helpful if such laws require victim companies to notify law enforcement prior to mandatory customer notification. This provides law enforcement with the opportunity to delay customer notification if there is an ongoing criminal investigation and such notification would impede the investigation. Finally, it is also helpful if such laws do not include thresholds for reporting to law enforcement even if certain thresholds – such as the number of customers affected or the likelihood of customer harm -- are contained within customer notification requirements. Such thresholds are often premised on the large expense of notifications for the victim entity, the fear of desensitizing customers to breaches, and causing undue alarm in circumstances where customers are unlikely to suffer harm. These reasons have little applicability in the law enforcement setting, however, where notification (to law enforcement) is inexpensive, does not result in reporting fatigue, and allows for criminal investigations even where particular customers were not apparently harmed. ("Data Breaches: What the Underground World of “Carding” Reveals," Kimberly Kiefer Peretti U.S. Department of Justice, Forthcoming in Volume 25 of the Santa Clara Computer and High Technology Journal, page 28.)

I think such reports should go not only to law enforcement, but to consumer protection agencies. Of course, this sets aside the question of "are these arguments meaningful," and potentially costs us an ally in the fight for more and better data, but I'm willing to take small steps forward.

Regardless, it's great to see that the Department of Justice is looking at this as something more than a flash in the pan. They see it as an opportunity to learn.

Security Prediction Markets: theory & practice

There are a lot of great comments on the "Security Prediction Markets" post.

There's a tremendous amount of theorizing going on here, and no one has any data. Why don't we experiment and get some? What would it take to create a market in breach notification prediction?

Dan Guido said in a comment, "In security, SOMEONE knows the RIGHT answer. It is not indeterminate, the code is out there, your network is accessible to me and so on. There's none of this wishy-washy risk stuff."

I don't think he's actually right. Often times, no one knows the answer. Gathering it is expensive. Translating from "there's a vuln" to "I can exploit it" isn't always easy. For example, one of my co-workers tried exploit a (known, reported, not yet fixed) issue in an internal site via Sharepoint. Something in Sharepoint keeps munging his exploit code. I've even set my browser homepage to a page under his control. Who cares what I think, when we can experiment?

What would be involved in setting up an experiment? We'd need, in no particular order:

• A web site with some market software. Is there a market for such sites? (There is! Inkling will let you run a 45 day pilot with up to 400 traders. There's likely others.)
• Terms & conditions. Some issues to be determined:
  1. Can you bet on your employer? Clients? Customers?
  2. Are bets anonymous?
  3. What's the terms of the payoff? Are you betting company X has a breach of PII, or a vuln? Would Lazard count?
  4. What's the term of a futures option? What's the ideal for a quick experiment? What's the ideal for an operational market?
  5. Are we taking singleton bets (Bank A will have a problem) or comparative (Bank A will have more problems than bank B.)
• Participants. I think that's pretty easy.
• Dispute arbitration. What if someone claims that Amazon's issue on Friday the 6th was a break-in? Amazon hasn't yet said what happened.

So, we could debate like mad, or we could experiment. Michael Cloppert asked a good question. Let's experiment and see what emerges.

Photo: "Better living..." by GallixSee media.

Messing with the RIAA and MPAA

Some very smart people at the University of Washington figured out how to leverage the bittorrent protocol to cause the RIAA and MPAA to generate takedown notices. From the website:

* Practically any Internet user can be framed for copyright infringement today. By profiling copyright enforcement in the popular BitTorrent file sharing system, we were able to generate hundreds of real DMCA takedown notices for computers at the University of Washington that never downloaded nor shared any content whatsoever.

Further, we were able to remotely generate complaints for nonsense devices including several printers and a (non-NAT) wireless access point. Our results demonstrate several simple techniques that a malicious user could use to frame arbitrary network endpoints.

* Even without being explicitly framed, innocent users may still receive complaints. Because of the inconclusive techniques used to identify infringing BitTorrent users, users may receive DMCA complaints even if they have not been explicitly framed by a malicious user and even if they have never used P2P software!

* Software packages designed to preserve the privacy of P2P users are not completely effective. To avoid DMCA complaints today, many privacy conscious users employ IP blacklisting software designed to avoid communication with monitoring and enforcement agencies. We find that this software often fails to identify many likely monitoring agents, but we also discover that these agents exhibit characteristics that make distinguishing them straightforward.

For more details check out the technical paper.

Security Prediction Markets?

In our first open thread, Michael Cloppert asked:

Considering the contributors to this blog often discuss security in terms of economics, I'm curious what you (and any readers educated on the topic) think about the utility of using prediction markets to forecast compromises.

So I'm generally a big fan of markets. I think markets are, as Hayek pointed out, a great way to extract information from systems. The prediction markets function by rewarding those who can make better predictions. So would this work for security, and predicting compromises?

I don't think so, despite being a huge fan of the value of the chaos that emerges from markets.

Allow me to explain. There are two reasons why it won't work. Let's take Alice and Bob, market speculators. Both work in banks. Alice thinks her bank has great security ("oh, those password rules!"). So she bets that her bank has a low likelihood of breach. Bob, in contrast, thinks his bank has rotten security ("oh, those password rules!"). So he bets against it. Perhaps their models are more sophisticated, and I'll return to that point.

As Alice buys, the price breach futures in her bank rises. As Bob sells, the price of his futures falls. (Assuming fixed numbers of trades, and that they're not working for the same bank.)

But what do Alice and Bob really know? How much experience does either have to make accurate assessments of their employers' security? We don't talk about security failures. We don't learn from each other's failures, and so failure strikes arbitrarily.

So I'm not sure who the skilled predictors would be who would make money by entering the market. Without such skilled predictors, or people with better information, the market can't extract the information.

Now, there may be information which is purely negative which could be usefully extracted. I doubt it, absent baselines that Alice and Bob can use to objectively assess what they see.

There may well be more sophisticated models, where people with more or better information could bet. Setting aside ethical or professional standards, auditors of various sorts might be able to play the market.

I don't know that there are enough of them to trade effectively. A thinly traded security doesn't offer up as much information as one that's being heavily traded.

So I'm skeptical.

CSO's FUD Watch

"Introducing FUD Watch:"

Most mornings, I start the work day with an inbox full of emails from security vendors or their PR reps about some new malware attack, software flaw or data breach. After some digging, about half turn out to be legitimate issues while the rest - usually the most alarming in tone - turn out to be threats that have little or no impact on the average enterprise.

The big challenge for security writers is to separate the hot air from the legitimate threats. This column aims to do just that.

But for this to work, audience participation is a must.

I'm highly in favor of reducing the FUD. I hope that Bill Brenner's efforts will help constrain and shame some of the worst of the FUD. However, it won't go all the way. Bill admits that he's working from opinion not data. In The New School, we talk about how we need data on how often various problems actually manifest. When we get that data, we won't need as much audience participation. In the meantime, go mock the FUDsters.

Sing it shrdlu

Over at Layer8, shrdlu lays it out there and tells us what it takes to appear to be effective:

In all the initiatives I’ve rolled out in my (checkered) career, the ones that have gotten the most acclaim from my management have always been the ones that were most visible to the users. They turned out to be popular if they:

- were used directly by the users
- allowed the users to do something better, or faster, or better AND more securely
- helped reduce the risk of a legal problem

and

In the eyes of the business—the ultimate risk decision maker—the more it affects/helps the users, the bigger the win. So from a practical point of view, they’re using a very different set of risk factors than we are from behind our consoles and our dashboards.

These are both huge points, that highlight the difference between what we as practitioners often think is important and what the business thinks is important. The trick of course is balancing the two correctly. My recommendation is whenever possible leverage adding security by packaging it with a new offering that users want. For instance, at one employer, there was a big push from users to be allowed to move from dial-up to VPN over their home broad-band connections. We gave it to them, but took the opportunity to move from passwords for authentication to tokens. We got almost no complaints from users about it being harder or more complicated because it was bundled with something they really wanted. This had the added bonus, that down the road when we later required it for accessing certain critical systems, it was a well understood technology that people were used to using, so we got very little push-back and got compliments from our auditors for being so conscientious.

This May Be FUD

You may have seen this article from the India Times, "Govt may get keys to your BlackBerry mailbox soon." Many people have been commenting on it, and the hand-wringing should build up to a good storm in a few days.

The gist of the article is that the Indian Government has told RIM that if they can't read BlackBerry email, they might just ban all BlackBerries from India, and that RIM is caving.

Being the sort of person I am, I called someone who actually knows something. I can't tell you anything more, precisely because they actually know something.

What I was told is that this is complete FUD and false. The BlackBerry crypto is real crypto, just like SSL, PGP, S/MIME or anything else. The keys are generated on the handsets and on the BES server. There is end-to-end crypto, using real protocols like SPEKE. RIM doesn't have the keys to give. RIM cannot give the keys over because only the devices have them.

Of course, as is true in all hatchet jobs, the lead is with weasel-words:

In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys.

See that? It's the word may.

Here's my own text, which I know may be true because I just may have made it up:

In a major cryptographic breakthrough, Canada-based Research In Motion (RIM) may soon put quantum cryptography in all new handsets, preventing any interceptions, because it's well, you know, quantum, and quantum is cool.

Or this:

In a major scientific advancement, Canada-based Research In Motion (RIM) may have accepted an order for 10 million BlackBerrys from space aliens living on Epsilon Erandi. A faster-than-light (FTL) email relay server may be installed at Barnard's Star as part of this groundbreaking, er, space-breaking agreement.

And even:

In a major economic development, Canada-based Research In Motion (RIM) may have purchased the Large Hadron Collider from CERN. According to officials close to the development, Canadian High Commissioner David Malone may have approved the deal not merely despite, but actually because of the chance that the LHC could create a small black hole that would devour all of France. "Canada is just fed up with the pointy-lips in France making fun of their accents and may have decided to take proactive action. Details on this one will be provided in two or three weeks," sources close to the deal may have told Emergent Chaos. No comment was available from the United Nations at posting time.

May, while a merry month, may also be the tool of liars.

RIM, I know you're reading this, not only because we are one of the top 25 blogs, and not at all because we speak for the President of the United States, but because Adam used to live in Montréal and is no pointy-lips. Please, please give us a definitive statement. You have to call bullshit on this sort of thing before it becomes destructive.

I know and you know that there would be no better publicity for you than to call their bluff and say, "D'accord, pas des mûres pour vous." We would all cheer. BlackBerry sales will soar.

Photo "Indian BB" by Edlimagno.

The Difference Between Knowledge and Wisdom

If you haven't heard about this, you need to. All Debian-based Linux systems, including Ubuntu, have a horrible problem in their crypto. This is so important that if you have a Debian-based system, stop reading this and go fix it, then come back to finish reading. In fact, unless you know you're safe, I'd take a look at updating your system anyway.

The problem is that they "fixed" the random number generator so that it doesn't generate random numbers, but a semi-fixed stream of pseudo-random bytes.

A friend of a friend is now working on generating the whole set of possible keys, and will release them to the world here. (Agree or not with this, but remember that the bad guys have them by now.)

Ben Laurie has written about it in gory detail here and here. If you want a summary, this problem comes about because the OpenSSL random number generator does some things that are unconventional, but not wrong. The unconventional coding was flagged by a code-analysis tool, and a Debian person removed it. That change made all randomness vanish from the random number generator.

Plenty of people have debated the whole thing. For example, there's the debate that says the Debian developer was an idiot, adn the people who say that the folks who did unconventional things were idiots.

I think that this is the sort of expected failure that happens in complex systems. I am reminded of code optimizers that see that a programmer clears a variable and then doesn't use it, so they optimize out the clearing, not realizing that that is erasing keys or passwords or whatever.

I'll add in that what leapt out at me was that the unconventional coding had an excessively vague comment noting that the analysis tool wouldn't like it. It would have been much better to have an over-the-top comment.

I was once notorious for a comment I had in some extremely hairy code that said something akin to:

This code is delicate. Don't modify it unless you understand it. If you think you understand it, you don't. I wrote it and I don't understand it.

That's what I meant by an over-the-top comment. I wanted the poor person who maintained my code to think three times. When you do something unconventional, you need to point out to the other developers in the ecosystem that you did what you did intentionally.

And for those of you who read the whole of this article before patching -- shoo. Go. Install that update. Now.

Photo "Random # 15 MSH" by Saffanna.

Jack Jones on Risk Management

I really enjoyed watching the podcast version of a talk that Jack Jones gave at Purdue, "Shifting focus: Aligning security with risk management."

I liked the opener, about what it's like for executives to talk to security professionals, and the difference between what might happen and what's likely to happen. The screenshot is from a discussion of how to play Russian Roulette.

I also like the way he critiqued best practices (you'll have to watch). It's a little hard for me to assess his risk management methodology from a podcast, but it's a very worthwhile 45 minutes.

(Now only if he had some Kandinsky in there, I'd have no doubt that the Risk Management Insight Institute, which Jack heads, is part of what we call the "New School.")

Hiring Fraudsters?

PARIS — Jérôme Kerviel, the Société Générale trader who used his knowledge of the French bank’s electronic risk controls to conceal billions in unauthorized bets, has a new job — at a computer consulting firm.

Mr. Kerviel, who was given a provisional release from prison on March 18, started work last week as a trainee at Lemaire Consultants & Associates, which specializes in computer security and system development, a spokesman for the former trader, Christophe Reille, confirmed on Friday. (" After Trading Scandal, Banker Gets I.T. Job," The New York Times.)

First let me say that I'm fond of the phrase "paid his debt to society." It's out of fashion, but it used to mean that someone, after their sentence was carried out, was done. That they ought to be allowed to get on with their lives. I've publicly commented on Frank Abagnale being in this class.

Kerviel clearly understands how to get around IT controls. I expect that there's a great deal which he might be able to teach people about what's important in security design, and some about what isn't. (His ability to generalize his approach hasn't been tested yet.)

At the same time, he hasn't yet been tried for his actions. What would be the right framework for making a hiring decision like this?

Photo: REUTERS/Benoit Tessier

Security Metric?

Ross Anderson has made PDF versions of several chapters of his Security Engineering (second edition) available on-line. The entire first edition has been available for some time.

I am sure this second edition will be outstanding. I would rank the first edition as one of the top three technical books I've read. It would likely be number one. I have high expectations for the second edition, stemming in large part from the author's academic discipline.

How many security titles have a 104 page bibliography?

Congratulations to the CVE team!

The CVE Web site now contains 30,000 unique information security issues with publicly known names. CVE, which began in 1999 with just 321 common names on the CVE List, is considered the international standard for public software vulnerability names. Information security professionals and product vendors from around the world use CVE Identifiers (CVE-IDs) as a standard method for identifying vulnerabilities, and for cross-linking among products, services, and other repositories that use the identifiers.

See the CVE News page. I remember proposing that we have a CVE-1. I'm tremendously proud to have helped get such a useful thing off the ground, and really happy for the CVE team.

User Friendly Gets It

In his inimitable way, Illiad has hi-lighted that the miscreants have moved from the operating system to the applications.

Threat Modeling Blog Series

Over on my work blog, I just wrapped up a series on threat modeling. Because blogs display the content backwards, I've put the entire series up as a Word doc: The Trouble With Threat Modeling.

[Update: If you want to see all the threat modeling posts, they're at Threat Modeling SDL blog posts. They're displayed latest to oldest, which we're looking into.]

Dubai banks hiring hackers (no word on if a drug test is needed)

Dubai, as Adam pointed out, is in something of a branding quandary. A hard line - some would say a retrograde and counterproductive line - on victimless crime doesn't mix well with an image as a fun spot for the well-heeled.

Meanwhile, there's this (from Emirates Business 24-7, retrieved 2/21/2008):

Dubai-based banks are recruiting former hackers to shore up their information security systems, said an information technology expert.

Addel Wahab Ahmed Mostafa, an IT consultant and chief of the technical committee at information company UAE Data Warehouse PM, said banks were hiring hackers in a bid to stay one step ahead of potential breaches.

Most of the big organisations are employing ex-hackers.

In Dubai banks are hiring hackers to protect themselves because how else do you protect yourself from hackers?

You must figure out the measures they use and use them yourself.

He said 60 per cent of hacking originated inside organisations or was carried out by former employees.

(emphasis mine)

I see a mixed message being sent here. And by the way, from the tone of the article it is clear the "ex-hacker" doesn't mean "broke the law ten years ago", so let's not start that flame war.

Time To Rethink The Efficacy Of That Hard Drive Crypto

As we love to say, if you have physical access to a machine, then you have access to all the data on it. Today Ed Felten et al. proved that yet again when they released a paper describing cold boot attacks on encryption keys. In it, they DRAM can be stripped (even after a full shutdown) of passwords and encryption keys. It turns out that DRAM doesn't lose it's memory immediately even after losing power. As a result, they have been able to successfully extract keys for Bitlocker (Vista), TrueCrypt (multiplatform open source) and FileVault (OS X). They can even take the DIMMS out of the target computer move them to another machine then find the keys without interference from the original host OS. How cool is that? I imagine it won't be long before this gets implemented in forensics software and/or hacking tools.

[Via Boing Boing]

Back in the ring to take another swing

Via Kable's Government Computing, comes news that the British House of Lords "Science and Technology Committee has announced a follow-up inquiry to its 'Personal Internet Security' report".

Chair of the committee Lord Sutherland said: "The committee was disappointed with the government's response to its report. We felt they had failed to address some of our key concerns about people's security on the internet.

"The House of Lords is likely to be debating the report in the summer and to ensure that the debate is as well informed as possible we have decided to seek key stakeholders' views on the government's response."

Kable's Government Computing, 2008-02-21

I speak American english, so I may not be up on the nuances, but I think Lord Sutherland is saying that they're going to line up a bunch of experts to say what absolute dolts the government were in ignoring the recommendations put forth by the Committee last year.

Excellent.

Computer Capers and Progress

We're coming up on the 30th anniversary of the publication of "Computer Capers: Tales of electronic thievery, embezzlement, and fraud," by Thomas Whiteside.

What, might you ask, can we learn from a 30 year old text?

Nothing has changed.

Except, for some of the names. Donn Parker is in there, as are a melange of consultants. But read this:

As the result of such revelations of security weaknesses in IRS computer systems--and, in particular, the critical [date] GAO report--the commissioner of the IRS, while conceding that the IRS had not been as aggressive in the past as it might have been in correcting situations that potentially weakened its overall security, declared that he is committing the IRS to a "vigorous course of improvement" in the management of computerized tax data in order to assure the maximum security for information on taxpayers. (pp71 of the paperback)

That was in 1977. Compare and contrast this 2008 Associated Press article:

IRS records, including taxpayer information, are vulnerable to tampering or disclosure because it has not yet fixed dozens of information security weaknesses, according to a government report issued Tuesday.

The existing problems, the GAO said, included giving too many people access to sensitive material, failure to encrypt all sensitive data and weak physical security controls.

...

Acting IRS Commissioner Linda Stiff, in response to the report, wrote that the agency recognizes "there is significant work to be accomplished to address our information security deficiencies and we are taking aggressive steps to correct previously reported weaknesses." (Associated Press, 2008, "Report Cites IRS Security Flaws"

I could go on about similarities between what's in Computer Capers, oh, ok, one more:

Top management people in large corporations fear that publicity about internal fraud could well affect their companies' trading positions on the stock market, hold the corporation up to public ridicule, and cause all sorts of turmoil... (Computer Capers, page 72)

I could go on quoting, but can we as a profession go on making the same mistakes?

The fetishization of secrecy has got to stop, or in thirty years, we'll be looking back at the same problems.

A Cha-cha all the way to the bank

On the beaches of Mexico, they're talking about Copacabana, a new cipher-cracker that works on DES and other ciphers with a 64-bit key. Yes, this has been done before, but this is interesting for a number of reasons.

First is the price. About €9,000. Second, there's the performance. A complete DES keyspace sweep in a fortnight. That's not bad. If you think about Deep Crack and what you'd expect from normal semiconductor advances.

The news, however, is that apparently there are banks using two-factor authentication tokens with DES-based keys, and if you're clever, you can break this token with far less than a full key search. You only need to observe the supposedly one-time password (or two or three of them), and then with a fortnight's of computing, you can generate any one-time password the real owner can.

Maddeningly, there are other systems based on AES or some other crypto that aren't at all vulnerable to this attack -- because they have better keys. People who are vulnerable to this attack need not be.

Apparently, these banks have fallen in love with DES. But falling in love is dangerous. It's also negligent, when it's so easy to get shot.

Photo courtesy of Imagem Compartilhada.

Adam's Law of Perversity in Computer Security

Rybolov had an interesting comment on my post, "How taxing is it to read a tape?" He wrote about how hard it can be, and closed:

I think the key is that it's hard for the average person to read tapes if they found/stole them, but for a moderately-large organization/attacker, it's possible.

I think this is a great example of what I call perversity in computer security. When a fellow with the best of intentions is trying to do something, it's hard, and when the bad guy tries it, it's easy. It's like when you want your computer to keep data, it loses it. But when you're trying to delete it, it's awfully hard. Similarly, your computer often behaves in seemingly random ways. But when you're trying to get what cryptographers call good randomness, it's perversely hard.

There's another place this routinely shows up, and that's around the question of "are IP addresses personal information?" If you want to use IP addresses for security purposes, they're notoriously poor. But if you want to use them to invade privacy, they're often good enough. As Eric Rescorla writes in "Uh, yeah IP addresses are identifying:"

It's certainly true that many home users have IP addresses that are assigned via DHCP, so in principle they're dynamic, but that doesn't mean that you don't regularly get the same IP. From what I hear, common practice for full-time Internet connections is to regularly assign the same IP addresses to the same host. The IP addresses change occasionally, but mostly they're semi-static, so the IP address is generally a pretty useful identifier. And of course, even if your IP address does change regularly, it's still possible to cross-correlate activities at multiple sites at the same time.

This is up there with my other law: "All Non-Trivial Privacy Fears Come True."

How dumb do we think spammers are?

Why is it we easily admit that spammers are people smart enough to run massive bot nets, design custom malware, create rootkits, and adapt to changing protection technologies but we still think that they're unable to write a pattern to match "user at domain dot com"?

Kudos to the first person who puts such a pattern in the comments below.

TSA's insecure "Traveller Identity Verification" site slammed by Oversight Committee

First exposed nearly a year ago, by DIY boarding pass mastermind Chris Soghoian, a TSA web site intended to help travelers improperly recorded on watch lists has been slammed by a House Oversight and Government Reform Committee report:

TSA awarded the website contract without competition. TSA gave a small, Virginia-based contractor called Desyne Web Services a no-bid contract to design and operate the redress website. According to an internal TSA investigation, the “Statement of Work” for the contract was “written such that Desyne Web was the only vendor that could meet program requirements.”

The TSA official in charge of the project was a former employee of the contractor The TSA official who was the “Technical Lead” on the website project and acted as the point of contact with the contractor had an apparent conflict of interest. He was a former employee of Desyne Web Services and regularly socialized with Desyne’s owner.

TSA did not detect the website's security weaknesses for months. The redress website was launched on October 6, 2006, and was not taken down until after February 13, 2007, when an internet blogger exposed the security vulnerabilities. During this period, TSA Administrator Hawley testified before Congress that the agency had assured “the privacy of users and the security of the system” before its launch. Thousands of individuals used the insecure website, including at least 247 travelers who submitted large amounts of personal information through an insecure webpage.

TSA did not provide sufficient oversight of the website and the contractor. The internal TSA investigation found that there were problems with the “planning, development, and operation” of the website and that the program managers were “overly reliant on contractors for information technology expertise” and had failed to properly oversee the contractor, which as a result, “made TSA vulnerable to non-performance and poor quality work by the contractor.”

House Oversight and Government Reform Committee

As for accountability,

Neither Desyne nor the Technical Lead on the traveler redress website has been sanctioned by TSA for their roles in the deployment of an insecure website. TSA continues to pay Desyne to host and maintain two major web-based information systems: TSA’s claims management system and a governmentwide traveler redress program. TSA has taken no steps to discipline the Technical Lead, who still holds a senior program management position at TSA.

Vulnerability Disclosure Agents Part N

Recently Dave G of Matasano (and smoked salt) fame two interesting articles on Vulnerability Disclosure Markets. In the second one, he reposted a user's comment:

Based on the failing (due to agenda) of (particular) Researchers, Coordinators (i.e. FIRST Members) and Vendors - Which “trusted person or organization” is left “that can represent vulnerability researchers whose reputation is at stake when dealing with vendors.”?

Let's assume for a moment that, in fact, there is no one that currently fills this role to everyone's satisfaction. Furthermore, let us assume that (at least for certain large vendors) that while the extant systems more or less works, everyone wishes it were smoother and easier.

How do we improve the situation? Vendors really don't like the vulnerability markets, researchers, quite understandably, fear liability and users just want fixes. How role for a vulnerability disclosure agent straddle this three sided fence? It seems to me that ideally, the agent would be a respected disinterested third party who was preferably a not-for-profit who didn't accept funding from either vendors or researchers. Coming from the corporate side, that sounds like a good balance to me. What say you? Does this make sense? Are there pitfalls I'm missing?

Splunk'd?

I have been playing with Splunk, for about 45 minutes.

So far, I like it.

I've previously been exposed to Arcsight, but what I have more of an affinity for psychologically is not so much a correlation engine, but a great visualization tool that automagically can grok log formats without making me write a hairy regex. I have no idea whether I will use Splunk for anything real, but it made a good first impression. Since my budget is zero, the price of the non-enterprise version looks good, too. I am sure that for those of a less penurious station, there are many more fine contenders.

Today's Free Advice from David Litchfield

Just because you can't see it, doesn't mean it's not there. Also it doesn't mean you can't figure out what it is.... Much like traffic analysis what you show and how you show it, can reveal a lot about what is going on behind the scenes.

Beat To The Punch

Yesterday, Sammy Migues talked about the risk of too much risk management. The only problem is that he completely misused the term Risk Management. I was all set to post a rant about that here, and in fact spent far too much time last night writing up a response. In the meantime, the Hoff and Alex responded with far better explanations and analysis then I had. So just go there and read what they had to say instead.

Looking for a challenge? Life dull?

If you need a change in your life, consider this job posting:

Title: IT Security Architecture Manager Needed

Company: TJX Companies

Location: Framingham, MA

Skills: Very strong technical security background in both the mainframe and distributed environments.

Term: Full Time

Pay: DOE

Length: Full Time

Detail:

TJX Companies is seeking an IT Security Architecture Manager who has at least 6 years experience in Information Technology and certification related to the security profession (CISSP, CISA, CISM) preferred.

Read on. If you like being the sheriff who cleans up town, this could be for you!

Making a Positive Impression With The Business

Larry Hughes has a great post over on Riskbloggers with tips on how to demonstrate that security is invested in the success of the business. There's some really good stuff here. Especially these two:

Say “no” by saying “yes.” Somebody wants to uncork that remote access bottle, and let a thousand new contractors VPN into the corporate net from anywhere in the world with their own laptops? Of course you’d like to help them explore how they can meet their objectives in a way that’s neutral to the business’ security posture.

I can't agree with this one more. The only thing I've seen that gets more traction and people playing nice with us is a major security event. All saying no does is to make things more confrontational and put everyone in a resistant mood. So you want to avoid that, unless of course you like being called "Dr. No". By saying "How can I help?", you are putting yourself in a position where you are making things happen, not being a roadblock.

Learn when to say “That’s good enough for now.” Scratching and clawing for every inch of ground this time, because you know how hard it’ll be next time, only leaves you with bloody fingernails. Nobody wants to buy things from people with bloody fingernails.

As Ken Van Wyck and Mark Graff remind us Secure Coding, it's not about being secure. It's about being secure enough. It's never going to be perfect, so the question is whether there is enough protection from threats for the foreseeable future.

This is similar to how we need need to understand how businesses work. But we also need to understand how people work and learn how to interact with them better. As usual the people are indeed the weakest link, but in this case, it is us.

Invasion Of The Password Snatchers

As I've mentioned in the past my wife is a linguistics professor. Yesterday she came home from work with the following poster. A little research revealed that it and several others were originally commissioned in 2005 by Indiana University as part of their security awareness program that they assembled for national cyber security awareness month. While posters are hardly the be all and end all of awareness programs, these 50s horror movie-themed ones are far better then most.

When Hackers Don't Strike

Today the New York Times asks us: "Who Needs Hackers?" The article itself which discusses the recent outages at LAX and with Skype is fairly fluffy but has some great quotes which really cover the issues that we should be looking at as an industry. Security isn't just about hackers, but about managing threats and risks and we need to remember that much more often.

Peter "Comp.Risks" Neumann:

We don’t need hackers to break the systems because they’re falling apart by themselves.

Steve Bellovin:

Most of the problems we have day to day have nothing to do with malice. Things break. Complex systems break in complex ways.

and Avi Rubin:

Maybe we have focused too much on hackers and not on the possibility of something going wrong. Sometimes the worst problems happen by accident.

Evolve or Die

Or at least become more vulnerable. I've recently been helping a client with their secure coding initiative and as a result I've been reading Mike Howard and Dave LeBlanc's Writing Secure Code which reminded me of an important aspect of maintaining a secure code base which often gets overlooked: That is that as code ages it becomes insecure.

This is most readily apparent with web applications, but is true for any code base. I've worked with several clients who brought in organizations such as @stake, ISS, isec partners, etc several years ago for an assessment and then addressed all the found problems. Time goes by and customers using applications like NT Objectives and Watchfire start sending in bug reports. So the client calls me up and says something like: "What happened, those security guys we hired years ago must have been crappy, suddenly customers are calling up claiming we are insecure! How can that be? We haven't changed the code in those modules in ages!"

The explanation is pretty straight forward. The state of the art of finding vulnerabilities has moved forward and the clients' controls for dealing with vulnerabilities has stayed the same. As a result, the source code has naturally regressed and become more vulnerable over time, much like a piece of machinery wears out over time. We like to say that old, well understood, well tested code is far better than new code and while in general I'm inclined to agree, one needs to remember, that well tested means adjusting the tests to keep up with the advancement of vulnerabilities.

While this regression is inevitable there are some things that can be done to slow it down. Most notably, practices that reduce the attack surface as much as possible by implementing applications with least necessary privilege and the other security principles of Saltzer and Schroeder. Similarly designing filters to permit acceptable data as opposed to attempting to enumerate bad behavior will also get you a long way in the right direction, but in the end, you have to just keep on testing.

Steganography in the News

In Australia, Jeffrey Ismail has been convicted of "using a carriage service to menace, harass or offend" meaning using his mobile to coördinate reprisal attacks against a rival gang.

Despite registering his phone under the name "John Gotti" and being careful enough to tell his "clerics" to "bring 'ankshays' and 'atbays'" police recorded his calls and managed to decode the message. Recognizing it as Pig Latin, and careful explaining the lexical analysis required, police extracted a confession and obtained a conviction this week.

Photo courtesy of shutterberry.

The first salami attack?

A salami attack is when you take a very small amount of money from an awful lot of accounts. The canonical example is a bank programmer depositing sub-cent amounts of interest in a special account. These rounding errors add up.

I'm trying to find the first actual documented theft or attempted theft using this attack.

I'm hoping that a reader will know, when the first reports of salami attacks came out.

Please comment if you have an idea.

Photo: "Salami & cheese - food heaven," taken by SanFranAnnie with a Cannon SD400, which is not the camera mentioned in Mordaxus' post yesterday.

[Update, Jan 5, 2008: Steve Lipner provided me with a cite! Thomas Whiteside, Computer Capers, 1978. The copyright page states that most of the material first appeared in the New Yorker.]

You can't spell "Really pointless flamefest" without R-O-I

Rich Bejtlich, with whom I do not want to argue about definitions unless I have a much thicker dictionary than he, has taken aim at the (mis?)use of ROI by security people.

EC readers may be interested in a blog post by Ken Belva, in which the guy who literally (co)wrote the book on establishing a methodologically sound and empirically defensible business case for information security spending -- Lawrence Gordon -- weighs in via email.

Hopefully, Gordon is a sufficiently authoritative source to put this question to bed for a while.

Wretched Term of the Week: Best Practice

This is a peeve I learned from the great Donn Parker. The term "Best Practice" should be avoided. It is inaccurate. misleading, and self-defeating. Here's why:

1. Best is a superlative. By using it, one implies that there a single choice that surpasses all others. Rarely is this the case in real life. Security gurus are known for asking probing questions like "What's your threat model?" or "What goal do you wish to achieve?" Different goals yield different practices.

   Shortly after 9/11, some physical security people I know put some physical security plans in place that many people, including me, sneered at. Harumph, harumph, it doesn't actually improve security. It's there just to look like you're doing something. Some time later, one of them took me quietly aside and told me that the reason they did it was to lower insurance costs. If you're faced with your insurance bills going up by a million bucks and you can avert that with fifty grand of security theatre, out comes the greasepaint and tap shoes followed shortly by an amateur production of songs from Chicago.

2. Something that is best doesn't actually have to be good. If you're faced with having to choose between a number of bad alternatives, you still look for the best. But best implies good. Admittedly, using best allows you to weasel out of the fact that the decision sucks. In such a dilemma, least bad is better than best because it's honest.
3. A superlative implies that it cannot be surpassed. That makes it hard to replace a best practice with one even better. Smart people know that best is always within context and often the life of it being superlative is shorter than the implementation time. But that word works in favor of the clichpoop with the budget. Why set yourself up be on the defensive?

What do you say, then? Parker recommended "Good Practices," but noted that many best practices need improvement before they can get to good. This the problem -- we're always having to do things that may not be quite so good. Grading on the curve is an old technique, and the same budget holder who will question improving a best practice may not appreciate honesty. Some organizations use "Best Current Practices" which manages to keep from tacitly chiseling them in stone, but still keeps the superlative, and I believe that the superlative is a problem. I think I can count practices that are truly best on one hand once they get more complex than, "look both ways before crossing the street" or "cook the popcorn for only two minutes."

I recently heard Stephen R. Katz, another pioneer of computer security -- the world's first CISO, mention the same peeve and suggest the term "Standard Acceptable Practice." The great thing about a term like "Standard Acceptable Practice" is that no one is going to disagree with either, "We have to get this organization to follow Standard Acceptable Practices," or "We need to improve our Standard Acceptable Practices." Photo by andai.

What If The Hokey Pokey Is What It's All About?

I've always thought that folks in operation security and product security had a whole lot to learn from each other. Unfortunately for the product security people, they now also get to learns about the pain of vendors swooping down on them trying to sell them the latest and greatest crap.

Last night, Mary Ann Davidson shared her spot on opinion of automated testing tools. Her post (go read it now) can be best summarized by this paragraph:

f you are scratching your head saying, "But didn't you rhapsodize over automated tools in a previous blog entry?," you are right, I did. But there is a big difference between "this tool helps us do good things in security as one among many good things to do" and "this tool is a substitute for all the other things you need to do to create secure products."

As operational folks have had the joy of learning over and over again, there are no silver bullets. Firewalls didn't do it (either as network or host based devices), IDS didn't do it, IPS isn't that much of an improvement and AV is only helpful after the fact. Are all these useful as part of a larger strategy?

It's all about defense in depth and it doesn't matter if we're talking about about product security, physical security or operations security. There is no magic button and there are no silver bullets. Don't believe the hype.

Whose Line Is It Anyway?

For quite a while now, I've been claiming that in order for InfoSec to do it's job properly, it needs to understand the business. Yesterday, Jack Jones again showed that he's in the same camp when he asked us: "Risk Decision Making: Whose call is it?" There he shares his thoughts how to decide whether or not the Information Security team should be making information risk decisions for a company or if that should come from upper management. True to form, Jack clearly lays out the issue (complete with great graphs). Read the entire post, because it's really worth it. In particular though, check out the things to consider section.:

The simple fact is, security leadership will never know as much about the business-related elements at the top of the illustration, and business management will never know as much about the risk elements at the bottom. Consequently, if security is empowered to make the major decisions, then they need to spend the time and effort to learn as much as they can about the business-related elements. On the other hand, if business leadership is making the major risk decisions, then security must provide clear, unbiased, and useful information so that the decisions are well informed.

I don't disagree with Jack in the least. However it's important to really that even if we're dealing with that later scenario, this means that security still needs to know a whole lot about the business or they can't possibly articulate the correct information in a way that senior management can understand.

And if the above rationale isn't good enough on why you as a security professional need to understand the business, try this on for size:

A decision-maker will to some degree ALWAYS apply his or her own personal risk tolerance to a decision. Consequently, if security leadership has been empowered to make major risk decisions, they should try very hard to be as aware as possible of business management’s risk tolerances. If security leadership isn’t careful on this, then they will, invariably, run into issues where business management doesn’t support security’s decisions. And if the misalignment is bad enough (and I’ve both witnessed this and come close to having it happen to me – long ago) then it can become a “terminal” condition. At the very least it makes the waters far choppier than necessary.

Movie Plot Threat No Longer a Metaphor

Director Mike Figgis flew into LAX airport and was detained for five hours because he oopsed. He said, "I'm here to shoot a pilot."

On the one hand, yes indeed, on the list of things you shouldn't say while in Immigration, "I'm here to shoot a pilot" is right up there with being careful how you greet your friend John.

But on the other hand, is the US government really filled full of so many beady-eyed, mouth breathers with brains the size of cashews that it takes five hours to clear this up? And in Los Angeles, of all places? Dear God, click on the link above. It's a Google search for "Mike Figgis." All ten links on the first page point to the director, celebrity, and film maker Mike Figgis. Link #1 (IMDB), link #3 (filmbug.com), and link #5 (mooviees.com) all have pictures of him.

Admittedly, IMDB says he was born in Cumbria, England, and hollywood.com (link #4) says he was "Kenyan-born." Hmmm. Highly suspicious. But filmbug says,

Born in Carlisle, England, Figgis moved to Nairobi, Kenya as a baby. He lived there until his family relocated to Newcastle in the north of England when he was eight.

And that seems to clear it up a bit. Mooviees tells us: Born: Saturday, February 28, 1948 (Carlisle, Cumbria, England, UK), and that seems to let us know that Carlisle is in Cumbria, and hey, there's a date that might be on his passport! Wikipedia (link #2) agrees with that date, but says, "Cumberland" instead of "Cumbria" and unless you've taken Latin, that might look suspicious as well.

So what happened? Did the dates not match properly? Did he cut the curls and go all Bruce Willis? Surely there must be some reasonable explanation. Maybe they really hated Leaving Las Vegas. Or perhaps it was that Sopranos episode. Maybe he called the Immigration agent "Sugartits."

Tip of the hat to 27 B Stroke 6. Original article from The Guardian. Photo of the perp along with Saffron Burrows shamelessly stolen from IMDB, whom I would have linked to if they'd made it easy.

Update on 31 May 2007: This story is apparently too good to be true. Boing Boing got told by people in the know that it's not true.

893 Million, and Whadda Ya Get?

♫Another DHS network, and we're not sharing yet.♫

So reports Haft of the Spear, in "You'll Share and You'll Like It!"

The Homeland Security and Justice departments have spent $893 million on information-sharing networks in the last two years but still do not have effective networks in place, according to a report from the Government Accountability Office.

Admittedly, there are more problems in sharing intelligence data than there are in sharing breach data. The fear of change runs deep, as does our unwillingness to give up control of the little bits of data we can see. It would be funny, if it wasn't so painful.

.BadIdea, Mikko

Mikko Hypponen suggests in an article that's getting a lot of press ("Masters of Their Domain") that banks get their own domain space, '.bank.' He argues that this would make phishing harder, and suggests we could charge banks a lot of money for the domains.

I have three problems with this:

1. Crooks are already investing in their attacks. If that money will have a high return, by convincing more people that the URL is safe, then crooks will invest it.
2. Some banks, such as credit unions, can't really afford $50,000 for a domain name, and so won't have one. (Thanks to Alex at RiskAnalys.is, " .bank TLD, An Idea Whose Time Has Come?"
3. Finally, and most importantly, it won't work. People don't understand URLs, and banks create increasingly complex URLs. The phishers will make foo.bar.cn/.bank/ and people won't understand that's bad.

The easy solution to preserving the internet channel against phishers is to use bookmarks. But that's too simple for anyone to make money at it. Certainly, no one's gonna make $50,000 a bank. That money is better spent on other things. .Bank is a bad idea.

[Updated: See also, "more .shenanigans" at Matasano, and "New .TLDs: Panacea for Security?" at SecureWorks.]

Speaking of Crypto -- Code Talkers

Today's xkcd, just seems apropos

Encryption Is Security Theater

Last night I was talking with a certain analyst from a large company that we've all heard from and we got into a discussion about most security people not understanding encryption at all, to the point that it is assumed to be a cure-all. In fact, with the exception of encrypting data at rest (and in many cases not even then), use of encryption serves as nothing more than providing a false sense of security.

This is particularly true in the case SSL. SSL is probably the most deployed, least useful security technology since tin foil underwear. Gene Spafford (as usual) put it best years ago, and nothing has changed:

"Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench."

Take a look through the various breach databases. Is there a single case where the breach could have been prevented by the use of transport level encryption? I have yet to find one.

But what about CA1386 and it's brethren? Or PCI? They mandate encryption. PCI dropped the requirement with the move to 1.1 so clearly they didn't see any real benefit of it. As for CA1386 and the like, although use of encryption does provide one with a get out of jail free card, all of the practical ways of applying encryption to online systems means that hacking the server means you have access to either the encryption keys or that the database is already decrypted for use.

Which brings us to data at rest. Encryption is only as good as the password/passphrase that protects the keys. Users are notoriously bad at selecting good passwords. This combined with the fact that the more popular disk encryption programs automatically decrypt the data for you on the basis of your login credentials (EFS, Bitlocker, FileVault, etc) so in many cases again one actually isn't that well protected. On the plus side, tools like PGP, BitLocker and others are well suited for protecting data at rest when they are separated from their keys. Particularly USB drives and the like.

So when doing a risk assessment, please don't assume something is secure because it uses encryption and please don't assume that whatever issues there are can be fixed by adding encryption. After all it is just security theater.

[Edit: Corrected a typo. Thanks Gavin.]

Quantum Cryptography Cracked!

Nature reports that, "Simulation proves it's possible to eavesdrop on super-secure encrypted messages." A summary of the attack is that the attacker instigates a quantum entanglement of properties of the photons so that they can infer the information (encoded in polarization) by measuring the entangled property (like momentum). It isn't a real attack, but as they say, attacks don't get worse, they only get better.

Despite the fact that quantum cryptography is an extremely cool technology, the quantum crypto crowd has hyped it to the point of being snake oil salesfolks.

It's understandable why they get overenthusiastic. Let's suppose you have two buildings and you want a secure link between them. You can set up quantum crypto, or you could use something off-the-shelf, like IPsec. IPsec is cheap. A couple of vpn boxes costing about $50 each would do it. Or you could set it up yourself using open source. On the other hand, a quantum crypto box costs about $50,000. They have to justify why you'd spend three orders of magnitude more for the coolness.

In the past, their justification has included some non-entirely-unfair slams at mathematical cryptography (there is, for example, no proof that factoring is hard), but it's been followed up with claims that somehow quantum mechanics is better than math.

This has ignored the fact that the math of quantum mechanics has had to dance around dividing by zero as one of the least of the counter-intuitive things in it. If you believe in RSA, you have to believe factoring is hard. If you believe in quantum crypto, you have believe that we understand quantum mechanics and there's nothing else really weird in it. As near as we can tell, Einstein was wrong when he grumbled about God not playing with dice. It's a stretch to think that God plays with dice, but doesn't make them come up snake eyes when someone's getting pompous.

Apparently, not only does God play with dice, but God has an evil sense of humor, is making faces, thumbing his nose, and snickering behind our backs. Me, I like it that way.

Security Through Stupidity

In my last post on security, I promised a tale, and I ought to deliver on that before it becomes nothing more than a good intention.

Some time ago, so long ago that it no longer matters, I bought a piece of network stereo equipment. It was one of these little boxes that lets you play MP3s, etc. through your stereo. I got it because it was a cute little system running Linux, had a MIPS processor, a web site for developers, extension and enhancement tools in Java, and so on.

I used it for a couple of months, and played with the Java-based remote control application for it and then decided to do some more serious work on it. I rolled my eyes that it only had telnet to get to it, but telnetted to it and was met with:

#

which I just stared at for a moment. It didn't even register for a good twenty or thirty seconds before I had the wit to type

ls

and was met with something akin to:

bin   dev  home  mnt  proc  tmp
boot  etc  lib   usr  sbin

and that didn't even register with me until I finally then typed

pwd

and was met with

/

and I made a loud two-word exclamation, of which the former was "oh" and the latter is left as an exercise for you, Gentle Reader, but there are two obvious candidates.

Yup, for the last couple of months, sitting bear-ass nekkid on the Internet was a Linux box with open telnet and a root shell. No username, no password, just a root shell. I said the other obvious candidate word. I also considered (again) getting a firewall. My network doesn't have a firewall. Part of it is that I like the road feel of the packets whizzing by. Part of it is that by the time I open up enough ports to do useful things, I'm just closing down the ones that don't have services on them anyway. Part of it is also that of the three times I've had serious security problems on my network, one of them was because my IDS box got rooted, and one was because the firewall got rooted. For me, adding a firewall adds complexity, and that lowers security. (That last time was when I was traveling with my SO who wanted to send me an email from an utterly ancient netnews program that knows nothing of SMTP-AUTH. Never reconfigure your email infrastructure from five thousand miles away while jetlagged. A couple of days later, you will ask yourself, "I wonder why the SMTP server logs have gotten so big." Fortunately for me, I caught it before the blacklists did.)

I yanked the music box off the network and connected to it directly (one cable, just it and me). Looking through the thing, I didn't see what anyone who was now using it for anything. I checked the IDS logs and there was nothing that leapt out at me to as suspicious traffic. That seemed odd, because how could it not have been owned? I thought about it for a bit, and thought about it more as I reflashed the critter. Then I laughed, because I realized that the tools that probe for vulnerable boxes are not going to be looking for #. It was then too late to tell, but I allowed myself to think that maybe the box hadn't been compromised, as the evidence suggested.

With the machine rebuilt, I connected to it directly with telnet and started probing around for putting a password (like /etc/passwd). There was none. There was no SSH, either. I fulminated on the developer fora about this security stupidity. I found the instructions on how to build the right cross-compiled Linux setup to build binaries for it, and it was filled full of warnings about how to make sure you did this, set that compiler switch, and if you didn't, things wouldn't work, and you get to reflash the box.

This wasn't how I was wanting to spend my Saturday, so I turned the box off, and went to do something else. As I did, I thought about the situation. I became increasingly amused that (apparently) the box hadn't been compromised. I convinced myself that this is because the bad guys wouldn't recognize the box as vulnerable.

As I grumbled and thought more about how to lock down the box and then something occurred to me -- anyone who wants to own the box has to go to the same trouble to make it be a productive member of their botnet community as I do to do the opposite, but they're at a disadvantage because they also have to protect it from me. Since it's easier to find some unpatched Windows box than it is to set up a MIPS cross-compile sandbox, even if they can tell that has an open root shell, it's not economically viable. Think of it as Mutual Assured Annoyance, Economic-Based Intrusion Prevention, Security Through Stupidity, or proving old adage, "In the land of the blind lion, the one-eyed zebra doesn't have to run very fast."

A couple of weeks later, I solved the whole problem when a new product was introduced that did exactly what I wanted (to be able to play music on my laptop on my stereo) at half the price and no icky telnet. The poor little music box now sits face-down, forlorn, and dust-covered on a shelf.

"What security people won't share with each other"

Scott Blake has a really interesting 3-part podcast interview with Mike Murray. See Mike's post, "it never ceases to amaze me what security people won't share with each other," and go understand why you should give Scott a demerit.

(I'd meant to post this months ago, when Scott did the interview. Oops!)

Month of Owned Corporations

Richard Bejtlich points to a very dangerous trend in his TaoSecurity blog, the "Month of Owned Corporations":

Thanks to Gadi Evron for pointing me towards the 30 Days of Bots project happening at Support Intelligence. SI monitors various data sources to identify systems conducting attacks and other malicious activity. Last fall they introduced their Digest of Abuse (DOA) report which lists autonomous system numbers of networks hosting those systems.

SI published the latest DOA report Monday and they are now using that data to illustrate individual companies hosting compromised systems. They started with 3M, then moved to Thomson Financial, AIG, and now Aflac. For these examples SI cites corporate machines sending spam, among other activities. Brian Krebs reported on other companies exhibiting the same behavior based on his conversations with SI.

He irresponsibly spreads... Oh, heck. I can't do it. This is great stuff. Let's actually look at what networks are spreading junk. I like this as a start, and the weekly Digest of Abuse claims to look at:

We analized over 22,000 ASNs for every kind of eCrime including DDoS, Scanning, hosting Malware, sending Spam, hosting a phish, or transmitting virous.

Hmmm, so while I'm glad that they're collecting and sharing data, what does it mean to be scanning? How do they define "hosting malware?" I really like the idea, and would suggest that Support Intelligence share more about what their data gathering methods look like, how they define each term, and how many of the incidents they see are of each type. (I've looked in their FAQ, how it works page, and product tour.)

Photo: The Exxon Valdez, courtesy of the Alaska Fisheries Science Center. Why? Because talking about breaches helps get them noticed and cleaned up.

From The "Wish I'd Posted That" Files

Gunnar (as usual) has a great post highlighting the lack of a real cohesive strategy in the security products arena and IT security teams losing site of the big picture. In particular, he highlights a comment from Andrew van der Stock about using SMS as an out of band authentication mechanism. Man I wish I'd thought of that...

Disclosure Laws, State-by-State

Philip Alexander writes in Intelligent Enterprise about "Data Breach Notification Laws: A State-by-State Perspective." The article is short and readable, and points to his new book, which is likely a good read.

Phriday Phish Blogging: Randomly Flagged

One of the things I really appreciate about phishing is that we pay people to discover the zeitgeist and share it with us.

There's little spam advertising fallout shelters or other ways to deal with the Red Menace. I rarely see advocacy about bimetallism in the currency in my inbox. We see what we see because spammers and phishers are motivated to get our attention. They do it by constructing plausible subject lines, like "Ebay question from seller," or, in the case of this week's Phriday Phish, "Security Measures. Your account has been randomly flagged !" That was the subject, here's the text:

Flagstar Bank Security Measures.

Dear Flagstar Bank Member,

Your account has been randomly flagged in our system as a part of our routine security measures. This is a must to ensure that only you have access and use of your Flagstar Bank account . experience. We require all flagged accounts to verify their information on file with us. To verify your information at this time, please visit our secure server webform by clicking the link below: http://0xd2.0xFF..../cgi/www.flagstar.com/ [URL edited for safety.]

I love how they claim your account was randoml