Wednesday, September 25, 2013

Has done NIST done enough damage control?

We really need to be able to trust NIST, and the Patrick Gallagher keynote did little to re-enable that I didn't watch the General Alexander keynote because my lack of trust in this individual is such that it simply isn't worth the bother.

Michael Daniel is a Special Assistant to the President, and Cyber-Security Coordinator at the White House.

In the first couple of minutes of his keynote, there was a nice mention of Northrup-Grumman, a huge defense contractor, a buyer of 0-day exploits, etc. as the lunch sponsor. I don't want to go into vulnerability disclosure here, save mentioning that the No More Free Bugs argument does have merit -- this is yet another complex issue.

From there the keynote promised to be more spin and politics. I really didn't have the time to spare for this one, as I have no trust in a national effort for identities in cyberspace. So I only half listened to Mr. Daniel.

Here is the lead URL that links to all three keynotes.

http://www.c-span.org/Events/Top-Cyber-Commanders-Speak-at-Cybersecurity-Summit/10737441649-3/

I am a bit busy right now, as I indicated in Back to Back Projects. Yes, a very 'duh' title. But that is just one reason that I am so very, very annoyed that I have to be dealing with this stuff right. As a society, we decided back in the 90s that there would be no mandated back-doors. No key escrow, no Clipper Chip. The NSA has apparently just decided that they would do it anyway, behind everyone's back.

I would *really* like to see someone go to prison over this, and that is an entirely non-political desire. This dates back to the Clinton administration, intervening Republican administrations have been at least as thoughtless, and President Obama has never, since before he was elected for his first term, shown much concern for doing the right thing in this regard.

Politics is a dirty business. Always has been, always will be.

And now, back to the salt mines. Some of us actually have to demonstrably help people, on daily basis. To us, the cyber-whatever politics game is, at best, bemusing. For instance, don't get me started on critical infrastructure protection.

Sunday, September 15, 2013

Back to Back Projects

There are a couple back-to-back projects coming up. The first involves writing formal docs, and producing a bit of material related to a slide deck (they could have chosen a better (meaning any) graphic artist) that has to be created related to The Risk of Temporary Systems. These people are not foolish—they want to ensure that they are never bitten by this problem again. They Get It, on a fundamental level. Which makes them a pleasure to do business with.

That's 2-3 days of work, and I will likely sink the latter half of the week into the usual (overhead, but interesting) research, rebuilding more of the lab, etc.

Beginning tomorrow (Monday, 9/16/13) I am on a project that will probably run for two or three months, more or less full time. As usual in this business, both sides are subject to NDAs. In this case, they are highly restrictive. But there are still things I can post. Research and reporting, even if only to an internal database, and an occasional blog chirp, never stops, and I hope you continue to visit.

If nothing else, I'd like to talk about OS updates (patching, and I hate that term), and how patch failure increases exposure.

Friday, September 13, 2013

The Risk of Temporary Systems

Here is an example of the classic 'temporary system' problem, which I have seen in various forms, up to a rogue server that some developers installed on the DMZ. Scenario:

  • Client installs new servers at a low rate--never more than 10 per year
  • Client has an incoming QA procedure that involves a burn-in  (Yay!)
  • Client burn-in procedure is to install an ancient OS, and some scripts that were written years ago  via optical drive (Boo!)
  • Client has no subnet for this, just some reserved IP numbers. (Boo!)
  • Cient just lets systems "soak for a while" (Boo!)
  • Client discovers a temporary system is compromised (Yay!)
  • Me gets money (Yay!)

The Yay count is three, though "Me gets money" probably wouldn't count, from the client's perspective, so let's just toss that one, and call it two. The Boo count is a definite three.

What Went Right

  1. They were sharp enough (or had been burned enough) to not just rack a new system up and place it into production. Infant mortality is real. Look at Google's publications on disk failures or something if you don't think that is an issue.
  2. They spotted the compromise in a much shorter than average period. It's not uncommon for compromised systems to remain undetected for months, so that is a huge Yay!

What Went Wrong

  1. Ancient code. The install rate was low enough that they didn't see much benefit from modernizing how they did this. Though it was a manual process, hence expensive. The irony is that they could have used provisioning/patching automation I'd already built for them, and this would never have happened.
  2. Improper subnetting. Ancient code, if running at all, should have been partitioned away. Particularly as it was just admin stuff, not a creaky old legacy business system that nevertheless had to be widely available, despite the risk.
  3. Procedures that need work. A Post-It note, with a start-of-run date, stuck to the front of a system is not good doc. 

Lessons


Most of this should be obvious from What Went Wrong. But it's worth stressing that countless problems are caused by organizations not being fully aware of what systems (and their security posture) are running behind the corporate firewall, or even full knowledge of what Internet connections exist. The thought of the odd T3 connection being forgotten about may seem strange to some, but it commonly happens in large organizations.

'Temporary' resources will become a larger problem than it is today. Virtualization, software-defined-everything, and the power of modern provisioning systems ensure this. Compute and storage nodes can be spun up with a few clicks of a mouse, and an interconnect with a few more clicks. The economic imperative is obvious.

There are things that the security community needs to work on, as always, but I would argue that the most important thing that organizations can do is embrace continuous audit.

Monday, September 9, 2013

rageface, NSA, NIST, and SP800-90revised_March2007.pdf.

There's an image I would love to paste in here, but I don't know what the associated rights are, and I am way too busy to research it. Search for 'rageface', if you care. You will come up with several variants of the same image.

Years ago, when I did hardware and metrology, I developed a lot of respect for what was then the National Bureau of Standards, now NIST. NIST still has an important role in much that I do, but these days you have to look at some of their work with a careful eye, always wondering if you are paranoid enough.

I am referring, of course, to the famous 'back-door' associated with SP800-90revised_March2007.pdf, which is related to random number generation. Which is, of course, a vital component in all cryptosystems.

I completely FUBARed this. I have a lot of bookmarks related to that 2006 issue, and some notes related to whether this might be a 'double-think' due to NSA influence, vis-a-vis RSA/DSA versus elliptic curves, but I don't have a copy of SP800-90revised_March2007.pdf. There is no copy in the archives, so all I could do is request one via email.

I will update this post if and when I get any response, with a SHA of what I receive. Because I no longer trust NIST.

Questions related to NSA influence of standards date back to DES. The consensus of the DES discussions was that there was no undue influence. Fine. That is something that historians of crypto can argue about--no sane architect currently specifies DES or 3DES in 2013.

SP800-90revised_March2007.pdf is more recent, and I should have kept better track of this stuff. FUBAR. Under my federal/nist/sp800 directory, there is no 'historic' directory, and there should be. There are groups of files with the same dates, due to my trusting NIST, and not practicing careful backup procedures on a workstation. This is a result of just dragging files around as I've upgraded the system over the years, etc.

I should have known better than to trust NIST due to monthly exposure; they publish a monthly bulletin which has changed file-naming conventions several times, sometimes carried no title at all, etc. And some of the 'advice' is about as useful as what my bank provides in their annual CYA surface-mail inclusion.

This is not the hallmark of a standards organization I should have trusted. So now I have to control file dates, take cryptographic hashes,  etc. I also have to write and maintain software to do it all, because it is too much to keep up with manually, on a daily basis. Because I can no longer trust an organ of my own government. Hence the rageface reference.

This has already caused huge economic repercussions in that several large-scale organizations are now unwilling to host data, or allow data to pass through (that will be tough, given that routing is a complex dynamic system), the United States. But it also has repercussions below the level of multinational corporations. Due to this, and similar issues, my overhead increased. So did the fees I have to charge, and that doesn't make things easier on anyone.

Thanks, NSA, but I am more interested in why no charges have been brought against General Keith B. Alexander (NSA is a military organization, and they have different goals), than, say
National Cryptologic Museum Offers Music and Movie in 20th Anniversary Festivities
though that definitely has its place.

Update September 11, 2013

I plowed through a lot of backups looking for this file, and came up dry.

The sleepless folk at archive.org (just coming back online after an extended periodic maintenance evolution) had the file. No, there is no evidence here for conspiracy theorists to get even crazier over. They were just doing database maintenance, and ran into some problems. These things happen. 

But let us put any potential crazies to rest, as best we can. I obtained a copy from http://web.archive.org/web/20070714022758/http://www.csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf. While it is possible to forge PDF documents, it would be stupid to do so in a manner that is easily detected, and there are bound to be many copies of this PDF floating around. Possibly some would generate a different hash (it only takes a single flipped bit), but the differences would be easily discovered. The NSA is not collectively stupid, and this would not happen. So here is a hash of the file I obtained from archive.org.

$ sha256sum SP800-90revised_March2007.pdf 
467100ea1fc8f98d24af3b9203687d828d601dfb6205e0424bbd2c5a40275bba  SP800-90revised_March2007.pdf

A quick note on backups. I looked at media dating back to 1999, though I didn't know it as I was swapping CDs (yes, CDs). The earliest media were apparently randomly burned from a workstation whenever I got sufficiently paranoid about losing work. They were all Imation CD-R.  As much as fourteen years old, and all disks were still readable. Anecdotal, and I wouldn't dream of doing backups as I did then. Or I would never have had to hunt for the file. But I was impressed with Imation media of the period.