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.

Weekend Security Humor

Because sometimes you just have to post some.

I think it was the sheep carefully lining up that butt-shot as much as anything.

Best Practices: Built-In Security Failure

Years ago, Intel hired me to do hardware-related work in semiconductor fabrication, as part of a group called 'Improvement Engineering' in what was a hole in the New Mexico desert. So, yeah, it needed a lot of improvement in order to become the cleanest clean-room on earth.

We didn't use the term Best Practices which is so prevalent in the compliance (I did not say Security, as they are emphatically not the same thing) industry of 2013, and you shouldn't either. Best Practices implies received wisdom, and slow responses to rapidly changing threats. We spoke of BKMs, or Best Known Methods. The 'Known' cannot be emphasized enough. It implies a seeking, driving, dynamic approach that is often lacking today; it implies currently Unkown Methods, waiting to be discovered by motivated, data-driven people.

Examples of where it has been proven that there can be no better way (from hardware, software, or procedural perspectives) are rare. This is fertile ground. More specifically, it drives Continuous Improvement, and various other all-to-corporate buzz phrases, past and present, into corporate culture.

The Best Practices approach demonstrably is, and has been, failing, by every available metric.  Emphasize that, take a data-driven approach, and reward those who demonstrably improve the state of the Best Known Method.

Privacy Advocacy Turns Out to Be Common

It is fairly common for security people to also be privacy advocates--it's security on a personal scale. So the NSA/Snowden thing is something I follow. And, while I don't really want this blog to become focused on something so politicized, some additional commentary is in order.

Here is a graphic I found particularly striking.

I am not a fan of Anonymous. The Guy Faulkes masks work, and they have been known to do what seemed useful cult-control. A large amount of media attention was a foregone conclusion, as was a commensurate amount of attention from law enforcement.

I can't approve of their methods, or admire their approach to operational security. If you are going to declare <Operation Whatever>, which often enough consists of a DDoS attack, don't use a tool like LOIC, which reveals the IP number of everyone you talked into the gig. Duh. Law enforcement did it's thing, and anons are being busted left and right. This will continue, and it is unfortunate that so many people were, in the end, victimized by Anonymous.

Idealism always carries a high cost, and it is usually dis-proportionally borne by the young and not yet cynical, so this is not a surprise.

It is a pretty sad state of affairs, as usual. Law enforcement is supposed to do it's thing. That's what we pay them for. If we, as a society, find the idea of the future of our children being ruined abhorrent, what needs to happen is fairly obvious. The law, and government accountability under the law, has to change.

It turns out that there are economic incentives to fix this. So even we cynics have some cause for hope. I'll either update this post, or point to new post(s) with updates. I'd prefer to just update this post.

Things are really busy right now.

I have a new project: documenting what I did, and the rationale for the choices I made, for one of the recent data analysis projects. I always write docs, but this is more in the spirit of a HOWTO for people that need some basic instruction on how data analysis pipelines (or workflows, if you will) are commonly constructed on Linux, and does not depend on humans clicking around, enduring the horrors of statistics in Excel, etc.

It's mostly about pre-processing data, feeding only what you need into a sane database (why give up three orders of magnitude in speed for the bits that will not have relational queries run), when to do matrix math, when to fire a decision-support plot because a threshold has been exceeded, etc.

Somewhat at variance with physics pipelines, it was written in bash, Python, R, and Go. I should do a post about that. But like I said, things are busy right now.

Fedora 17 reached EOL on 7/30/13

Why does that matter? Well, Fedora is regarded as upstream of Red Hat Enterprise Linux. RHEL, and derivatives such as CentOS, ScientificLinux, and Oracle Linux (though Oracle will never admit that). What that means is that Red Hat chooses a moment to grab the current Fedora distribution, and make some of the various bits more robust. Meaning supportable, at sane cost structures. That forms the basis of the forthcoming Red Hat Enterprise Linux. Running a current, or near-current, Fedora provides insight into the oncoming RHEL, which will be RHEL7, by the end of the year.l

This is useful, particularly as this will be the most powerful RHEL ever, by a wide margin. Mondo cloudy stuff is going to be in there. That should be another post; it is by no means all marketing.

But right now, I have to rebuild some lab machines. This isn't a huge deal--that's what labs are for. But it will keep me busy for a bit, because I have to characterize what I am doing.

How do you secure this stuff?

As Frank Zappa once wrote, "The crux of the biscuit is the apostrophe." Secure what? Against what threat? At what cost?

I have never been a fan of PCI-DSS. The standard cannot change rapidly enough to reflect changes in the threat envelope. Compliance costs are out of control, and it is not clear to me that there is any rational means of choosing any particular solution to a PCI-DSS line-item. Sometimes I hate to even talk about PCI-DSS; there are other requirements in other industries that are more interesting (medical record security comes to mind), and some things (design flaws in cryptographic protocols, etc.) apply to any industry.

The basics apply in any environment. Control access, authentication, and authorization, and the majority of your risk goes out the window. This is doable, even via bash scripting. From a Director Information Security at Fiserv (Acumen platform)

"we did get our PCI-DSS ROC and the assessors loved the hardening scripts and the way you listed the hardening steps by control number."

Write a master script that calls subscripts by control number. The downside is that it adds complexity; you will be touching some configuration files more than once. It works, and assessors love it. You do however, need a capable and auditable version control and build system. Git works fine, if you bolt on some additional tooling.

The point is that RHEL7 will offer more controls--you will have more power to meet any standardization, legal, or regulatory challenge.

We still fail at log analysis

Recently I've been working a couple of data analysis projects, and writing  
some software in support of that. Much of it has direct application to 
automated log analysis, alerting, and decision-support. While I am still tweaking, 
I have been pleased with those results.

Which is a Good Thing, because we need to be lot better at it than the data 
suggests we currently are. Good data are scarce, but the Verizon Data Breach 
Reports do provide some. Exactly what is reported each year, and the format 
in which it is reported changes each year. To some extent it has to; the 
landscape changes rapidly.

Back in 2010

• 86% of victims had evidence of the breach in their log files
• 3% of breaches were discovered by log analysis or review
• 4% were detected by the combination of event monitoring and log analysis (This is a drop from the 6% of 2009)
• 30% were in compliance with PCI Requirement 10: "Track and monitor all access to network resources and cardholder data." A better number than the abysmal 5% in 2009

Fast forward to the report for 2012 (published in 2013), where the data 
are again presented in a slightly different way. Overall, detection via logs was 
1%, broken into undefined Small (nothing reported), Large (4%), and Overall (1%).

There was no figure for how many victims had evidence of the breach in their logs, 
but there is no reason to believe it is substantially different than the 86% 
reported in 2010. So it would appear that there is significant room for 
improvement in log analysis.

I think we can all agree that the worst-case scenario is to not only suffer a 
breach, but to have it discovered by an external party. Anyone doing incident 
response is (or should be) aware that the clock is ticking. If it's public, 
there could be a lot of people watching it tick.

Perhaps it's time to look at your log analysis systems again, including a check 
to ensure that the system is inclusive enough. It's common for organizations to 
not even know where all the logs are. The problems can be as varied as that 
they're being written by unfamiliar or misconfigured software, or systems 
being installed incorrectly or surreptitiously. 

If any of that is found, the problems are obviously more extensive than just logs.

First Actionionable Item From Snowden NSA Leaks

Here it is, the Fourth of July, and I am putting up a post. That is dedication!

Actually, the barbeque is going, and the spud salad and the rest of it is done. Even though the recent Oregon heat wave has broken, I don't want to be sitting next to that barbeque, since I cleverly placed it in the hottest, most uncomfortable place available. I really need to take care of that. I just spent a couple of hours at a state park, I'll be outside most of the afternoon and evening, and I managed to get a bit of sunburn standing in the river behind my house yesterday, which I do not want to make any worse. So I'm good with being in a nice cool office for a bit, and I'll probably finish up sometime later today.

On June 7, I posted 

NSA overreach: is it actionable, or just random news? in which I intimated that there is little that is actionable from the perspective of a security practioner.

Since then, the revelations have continued, and NSA are about as FUBARed as it is possible to be. The popular press is where much of this is coming from, and this issue is not going away. I may talk about why in another post. I do keep up with this stuff, out of professional interest. Still, you might roughly classify news organizations into members of the

generic mass media,

generic IT media,

pop security media,

technical security media,

though the lines occasionally wander. I use many news sources, which I divide into tiers, based on accuracy, level of detail (these are not the same thing), frequency of update, political skew, etc. Efficiently keeping up with security news (and it must be done efficiently, lest it become a full-time job), is a difficult to do well. Note that this does not include research papers, or what corporate white papers have become over recent years. Those have to be read too, but I don't regard them as media, in the same sense as the above list.

Here is something you do not see every day.  Another piece from The Guardian, New NSA leaks show how US is bugging its European allies, the UK newspaper (generic mass media) which was one the first to take this whole thing public, reveals information on attacks against diplomatic embassies and  missions of the EU and member nations.

The generic IT media and pop security media have already begun to lump this entire thing into PRISM. It's easy to remember and search for, which is an advertising revenue win. Without which, they do not exist. Meanwhile, the generic mass media Guardian is more accurate than generic IT media, or pop security media  in their code names for attacks (NSA will have changed all these the moment they were revealed, but they may become useful search terms, if only for students of history).

BLACKFOOT: French diplomatic mission to the UN

WABASH: French embassy in Washington

BRUNEAU, HEMLOCK: Italian embassy in Washington

POWELL: Greek UN diplomatic mission

KLONDYKE: Greek embassy in Washington

PERDIDO: EU UN diplomatic mission

Crucially, they also provide a graphic related  to DROPMIRE, an attack against secure FAX. Specifically against Cryptofax, a product of the Swiss firm Crypto AG. As an aside, there have been rumors and accusations (since confirmed to my satisfaction) since the 1980s of collusion between Crypto AG and NSA. I am surprised that The Guardian didn't pick up on that.

This where things get actionable, in two areas. The first depends on how technically well-resourced your likely adversaries may be in a pure security context.

That image was enough for Dr. Markus Kuhn, of the Computer Laboratory, University of Cambridge to go on. In a convincing post to Light Blue Touchpaper (technical security media published by the Computer Lab) he has convinced me that this was a TEMPEST attack. Another codename, referring most commonly to radio emanations. Specifically, in this case, to monitoring the radio-frequency energy emitted as the FAX machines laser was switched on and off. That may be very much actionable.

TEMPEST attacks have a long history. I am actually a bit disappointed in the EU, and EU member states for allowing a TEMPEST attack to succeed; note that the home of the University of Cambridge is the UK, an EU member state.

The second area that might be actionable depends on whether you are in the midst of, for instance, sensitive negotiations with German counterparts.

In the real world, even friendly or allied governments spy on one another. Despite the public expressions of shock and dismay that you can expect to hear from members of EU governments, they almost have to. At the nation-state level, even friendly or allied governments do not have completely aligned interests (it's almost as if they are different countries or something), and you need to know if a friendly or allied government is about to stop being friendly or allied. Even if it is limited to a single issue, if that issue is important enough. An intelligence agency that gets this wrong will be said to have suffered an intelligence failure (Google that), and will be barbequed. 

In this case, the other guys have a bit of egg on their faces, as the expertise to prevent this was available to them, but wasn't effectively used. Of course, politicians being much the same in any Western nation, they will hope it blows over, and to attempt to cover with indignation if it does not. Or cover with the 'hackers on steroids' defense that was used by so many US organizations who were hacked to the bone by the script-kiddies of Anonymous. This is entirely predictable.

Make no mistake: this is not going away soon, even if the leaks stopped immediately. The politicians, and NSA, will be disappointed. It is not going to blow over, and will feel the need to be perceived as Doing Something, even if it is The Wrong Something. Repercussions seem likely to be large and long-lived -- consider that a federal election will occur September 22 in Germany. Germany is a NATO ally, the leading economic power of the EU, and a justifiably privacy-sensitive nation. Particularly given what came out about the East German Ministry for State Security (Stasi) before reunification. It has been revealed that NSA collected against Germany, and has classified them as a valid target.

Nor is Germany the only trouble spot that lies ahead.

On a final note, I am not defending all that NSA have done; their surveillance of US citizens, and lying to all and sundry to cover it up are heinous. NSA have a history of doing things that are either dubious, or simply illegal, and they need to be reigned in periodically. I am not defending the politicians who failed to do what they were elected to do, though at least Senators Ron Wyden and Mark Udall of the Senate Intelligence Oversight Committee tried.

There is a far greater likelihood of a whistleblower going to prison than an NSA official who breaks the law. We need to fix that if we intend to become a more just society. Possibly some of the more damaging leaks may have been intended to find a sympathetic ear; to find a safe haven after the hue and cry went up from the US government. If that is the case, a trustworthy whistleblower program would have prevented the majority of the damage to our foreign relations that has so far occurred. 

Whether the service that he has undoubtedly rendered to his fellow citizens by revealing the latest NSA overreach event is outweighed by the damage that he has done to foreign relations is for history, and more practically, a jury of his peers to determine.

Wednesday, August 28, 2013 Update

And the NSA has indeed become an election issue in Germany, according to Der Spiegel, Peer Steinbrück, Chancellor Angela Merkel's challenger in Germany's September general election, called for a suspension of trans-Atlantic free trade Peer Steinbrück, Chancellor Angela Merkel's challenger in Germany's September general election, called for a suspension of trans-Atlantic free trade talks.