ROI is not a cybersecurity concept

In the cybersecurity community, much time is spent trying to speak the language of business, in order to communicate to business leaders our problems. One way we do this is trying to adapt the concept of "return on investment" or "ROI" to explain why they need to spend more money. Stop doing this. It's nonsense. ROI is a concept pushed by vendors in order to justify why you should pay money for their snake oil security products. Don't play the vendor's game.

The correct concept is simply "risk analysis". Here's how it works.

On ISO standardization of blockchains

So ISO, the primary international standards organization, is seeking to standardize blockchain technologies. On the surface, this seems a reasonable idea, creating a common standard that everyone can interoperate with.

But it can be silly idea in practice. I mean, it should not be assumed that this is a good thing to do.

Announcement: IPS code

So after 20 years, IBM is killing off my BlackICE code created in April 1998. So it's time that I rewrite it.

BlackICE was the first "inline" intrusion-detection system, aka. an "intrusion prevention system" or IPS. ISS purchased my company in 2001 and replaced their RealSecure engine with it, and later renamed it Proventia. Then IBM purchased ISS in 2006. Now, they are formally canceling the project and moving customers onto Cisco's products, which are based on Snort.

So now is a good time to write a replacement. The reason is that BlackICE worked fundamentally differently than Snort, using protocol analysis rather than pattern-matching. In this way, it worked more like Bro than Snort. The biggest benefit of protocol-analysis is speed, making it many times faster than Snort. The second benefit is better detection ability, as I describe in this post on Heartbleed.

So my plan is to create a new project. I'll be checking in the starter bits into GitHub starting a couple weeks from now. I need to figure out a new name for the project, so I don't have to rip off a name from William Gibson like I did last time :).

Some notes:

• Yes, it'll be GNU open source. I'm a capitalist, so I'll earn money like snort/nmap dual-licensing it, charging companies who don't want to open-source their addons. All capitalists GNU license their code.
• C, not Rust. Sorry, I'm going for extreme scalability. We'll re-visit this decision later when looking at building protocol parsers.
• It'll be 95% compatible with Snort signatures. Their language definition leaves so much ambiguous it'll be hard to be 100% compatible.
• It'll support Snort output as well, though really, Snort's events suck.
• Protocol parsers in Lua, so you can use it as a replacement for Bro, writing parsers to extract data you are interested in.
• Protocol state machine parsers in C, like you see in my Masscan project for X.509.
• First version IDS only. These days, "inline" means also being able to MitM the SSL stack, so I'm gong to have to think harder on that.
• Mutli-core worker threads off PF_RING/DPDK/netmap receive queues. Should handle 10gbps, tracking 10 million concurrent connections, with quad-core CPU.

So if you want to contribute to the project, here's what I need:

• Requirements from people who work daily with IDS/IPS today. I need you to write up what your products do well that you really like. I need to you write up what they suck at that needs to be fixed. These need to be in some detail.
• Testing environment to play with. This means having a small server plugged into a real-world link running at a minimum of several gigabits-per-second available for the next year. I'll sign NDAs related to the data I might see on the network.
• Coders. I'll be doing the basic architecture, but protocol parsers, output plugins, etc. will need work. Code will be in C and Lua for the near term. Unfortunately, since I'm going to dual-license, I'll need waivers before accepting pull requests.

Anyway, follow me on Twitter @erratarob if you want to contribute.

Why that "file-copy" forensics of DNC hack is wrong

People keep asking me about this story about how forensics "experts" have found proof the DNC hack was an inside job, because files were copied at 22-megabytes-per-second, faster than is reasonable for Internet connections.

This story is bogus.

Query name minimization

One new thing you need to add your DNS security policies is "query name minimizations" (RFC 7816). I thought I'd mention it since many haven't heard about it.

Right now, when DNS resolvers lookup a name like "www.example.com.", they send the entire name to the root server (like a.root-servers.net.). When it gets back the answer to the .com DNS server a.gtld-servers.net), it then resends the full "www.example.com" query to that server.

This is obviously unnecessary. The first query should be just .com. to the root server, then example.com. to the next server -- the minimal amount needed for each query, not the full query.

The reason this is important is that everyone is listening in on root name server queries. Universities and independent researchers do this to maintain the DNS system, and to track malware. Security companies do this also to track malware, bots, command-and-control channels, and so forth. The world's biggest spy agencies do this in order just to spy on people. Minimizing your queries prevents them from spying on you.

An example where this is important is that story of lookups from AlfaBank in Russia for "mail1.trump-emails.com". Whatever you think of Trump, this was an improper invasion of privacy, where DNS researchers misused their privileged access in order to pursue their anti-Trump political agenda. If AlfaBank had used query name minimization, none of this would have happened.

It's also critical for not exposing internal resources. Even when you do "split DNS", when the .com record expires, you resolver will still forward the internal DNS record to the outside world. All those Russian hackers can map out the internal names of your network simply by eavesdropping on root server queries.

Servers that support this are Knot resolver and Unbound 1.5.7+ and possibly others. It's a relatively new standard, so it make take a while for other DNS servers to support this.