100kb of Unusual Code Protecting Nuclear, ATC and United Nations Systems

An anonymous reader writes: For an ex-academic security company still in the seeding round, startup Abatis has a small but interesting roster of clients, including Lockheed Martin, the Swiss military, the United Nations and customers in the civil nuclear and air traffic control sectors. The company's product, a kernel driver compatible with Windows, Linux and Unix, occupies just 100kb with no dependencies, and reportedly achieves a 100% effectiveness rate against intruders by preventing unauthorized I/O activity. The CEO of Abatis claims, "We can stop zero day malware — the known unknowns and the unknown unknowns." The software requires no use of signature files, white-listing, heuristics or sandboxing, with a separate report from Lockheed Martin confirming very significant potential for energy savings — up to £125,000 per year in a data center with 10,000 servers.

Comments

AppArmor

[ThePhilips]

From description, it sounds like the AppArmor.

Re:AppArmor

[smpoole7]

> it sounds like AppArmor

Or SE Linux, as others have noted.

It is possible to achieve high levels of security through integrity checking and behavior(al) control. It just costs a bit in performance and memory. And if you write something in very tight C, it's not going to be large.

I may have mentioned this here before; if so, I apologize. But a million years ago, back when MS DOS 5 came out, a friend and I developed something called the ARF Utilities. (To my endless amusement, you can still find it in a Google.) Our approach was integrity and behavior blocking.

One reason why DOS was so vulnerable at the time was because Microsoft kept rebuilding and reusing the same code. The entry point to the DOS kernel (the old INT21h interface) didn't change from DOS 5 through 6.22. Our integrity blocker did a simple search to find that in memory, then *patched* DOS to send all calls through the behavior blocker, which was resident in memory. We also hooked and examined a bunch of other stuff inside the kernel (including the INT 21h interface and the SHARE hooks -- the latter was a terrible security vulnerability and only the appearance of Windows 95, and the rapid demise of DOS, kept it from being exploiting widely and wildly.) The blocker was written in assembler and could fit in about 2K of memory, as I recall.

It also checked itself, and the integrity of an executed program's file, at startup, and each time a program was terminated. By "check," I mean it literally scanned its own code in memory, compared random CRCs taken of different blocks to generated values stored earlier and would instantly warn if DOS, the terminating program or itself had been tampered with. (You don't just do one "checksum" of a fixed length; you do different blocks, chosen at random, generated on the fly at system startup.)

We couldn't find a virus that could get around it. The worst we ever experienced was a hang that required a hard reboot. But the system wasn't altered. And yet, the Official Anti-Virus Community (which, at the time, was BIG business) rejected our approach, called us interlopers and marginalized us. Everyone back then wanted scanners, scanners, scanners. All of the tests were on scanners.

In sum: I have no idea if this particular company's code is snake oil or the Real Deal(tm). But don't just dismiss them. If you think outside the box, it is possible to find better ways to do something.

Just my opinion and worth every penny of what you paid for it. :)

Re:AppArmor

[KiloByte]

Sorry to break it to you, but the only reason no virus got around that is that no one bothered working around a blocker no one uses. In DOS, all it takes to duplicate OS calls is to copy their code, as every process has full access to the hardware and can do everything on its own. And then, any process can write to every location in memory, defeating any anti-virus or precaution imaginable. You would have to reimplement Bochs and interpret every opcode in software, effectively emulating a more secure platform. You can't securely run untrusted code without a MMU of some kind.

Re:AppArmor

[smpoole7]

> the only reason no virus got around that is that no one bothered working around a blocker no one uses

At the time, we actually had thousands of users of the ARF Antivirus, and we received more than one report that there were indeed efforts to hack it. :)

What you say is true *technically.* And you should change your username to "Deja Vu," because I (and my friends with similar approaches, like Zvi Netiv with Invircible) had to repeat this over and over. I finally got tired of it, and given that out of those thousands of downloads only ONE person ever bother to register/pay, it wasn't worth it. Fuggedaboutit, just use your virus scanner and we'll still be friends.

Never forget this: it's theoretically possible to do many things. But it is not always PRACTICAL. In the instant case, using your example, a virus that tried to emulate actual DOS calls, essentially duplicating the code internally, would be very large. Remember, this was back in the day of dial up modems and bulletin boards. And a virus that emulated processor opcodes would be even larger.

(And *cough* ... we also kept encrypted copies of critical system areas, and compared what we'd stored with what we found -- both on disk AND in memory -- from time to time. That made it much more difficult for the "stealth OS" hack that you describe.) (Heh.)

But I'm not going to waste time rehashing this argument. What I WILL warn against is what I saw your attitude produce, too many times to count: "since we can't guarantee 100% that a system can't be hacked, why bother?" I'm not saying that's what you believe, but I ran across that attitude too many times to count.

I can also do it with a single cable.

[Lumpy]

We used to use unidirectional ethernet cables. Basically the TX wires clipped out on the receiving end to the less secure network. You do need ethernet cards you can set to accept a link without having a full handshake going.

But it allowed us to set up the SCADA network to take the data stream we needed to get to the collection and reporting pc and UDP broadcast it. then the PC that can only receive set up to listen for and receive it, works great and is 100% hacker proof as hackers have yet to write code that can cause copper to grow back in a CAT-5e cable.

Now if we could keep the N00b SCADA programmers from bringing in their crap-tastic home laptops for programming changes and becoming the largest infection vector.

Adaptive, requiring 'training' & 'stability'?

[TheRealHocusLocus]

I'd really like to know on what principles this 'security driver' is based on

TFS I'm going for homeopathy.

If the marketing technobabble is correct the code is 100k but naught is said about data store, memory and persistent. Or whether the system satisfies these claims 'out of the box' or there is some training/learning period. Of course the pitch also does not indicate how often the Key Operator is called to investigate and override false alarms, and what the investigate/resolution process takes. Some ACs with experience might be useful...

You could have a 'train/run' switch that you flip to 'train' on first install during a period in which you do not reasonably expect intrusions, putting it through paces and trigger your software to check for updates, things like that, where it passively builds a profile of normal activity. Then flip it to 'run'. Then if it is a machine that does just a few things all day, the software has a pretty good idea of what to expect.

The payoff would come from how well you could parametrize the basic inputs --- stack state, communications endpoints and addresses, using directory hierarchy on disk --- and introduce a clever degree of fuzziness that also implements a sense of 'near' and 'far' on both class of operation and value.

Then maintain a pointer in some so-called 'phase space' and burn data into a sparse array to create a virtual landscape with erosion. In 'run' mode it is almost always hitting (or near) areas that have been populated. If the pointer strays from from the populated region we have an alarm.

For example, a process that has never accessed data outside its installed folders suddenly does so. Network addresses compared by closeness in the neighborhood.