Modeling Attacks in Prolog

I've been tinkering this week with the use of first-order logic as a way of modeling network attacks. It turns out not to be too difficult at all, if you know a language like Prolog. In my case, it's been over 20 years since I'd programmed in that language - and I hadn't done anything serious in it back then anyway - so I had to pull out the textbooks and start banging the axons and dendrites together. It turns out that two of my old Prolog books relate to LPA MicroProlog (which I used to run on CP/M!) and the third is the second edition of Clocksin & Mellish from 1984. I discovered that the language has changed a bit since then. I also found a copy of Borland Turbo Prolog, but since I don't have a 5 1/4" drive in a machine, I'm not even going to bother.

So I downloaded SWI-Prolog (http://www.swi-prolog.com) and installed it on both Linux and Windows systems. A few experiments and a couple of days of head-scratching later (most of it down to using a hyphen in a term in one place, and an underscore in another - doh!) I'm making some progress. Here's a simple example:

We define information assets as being managed by program/products which have vulnerabilities. An attacker can use an exploit against these vulnerabilities. Controls (patches, firewalls, IPS, etc.) remove or defend against the vulnerabilities and protect the programs. Now it becomes quite easy to state some facts and rules:

%% Facts
%% A more sophisticated approach would build these from CVE

%% Example: X11.org X font server has three vulns
%% has_vulnerability(Program, Vuln)
has_vulnerability(xfs,cve-2007-2103).
has_vulnerability(xfs,cve-2007-4568).
has_vulnerability(xfs,cve-2007-4990).

%% Postulate some exploits for these vulns
%% exploits(Vuln,Exploit)
exploits(cve-2007-2103, attack-tool-1).
exploits(cve-2007-4568, attack-tool-2).
exploits(cve-2007-4990, attack-tool-3).
exploits(cve-1000-0001, attack-tool-4).

%% Some controls, safeguards, (patches?)
%% removes_vulnerability(Control, Vuln)
removes_vulnerability(patch-xfs-1, cve-2007-2103).
removes_vulnerability(patch-xfs-2, cve-2007-4568).

%% Programs are protected by controls or patches
%% protects(Control, Program)
protects(patch-xfs-1, xfs).

%% Assets are managed by programs
%% manages(Program, Asset)
manages(xfs,fonts).

%% Some rules
%% An asset A is vulnerable to an exploit E if
%% the asset is managed by a product X which has vulnerability Y
%% and exploit E exploits vulnerability Y
%% and the program is protected by control C which remove vulnerability Y

vulnerable(Asset,Exploit) :-
manages(Program,Asset),
exploits(Vuln,Exploit),
has_vulnerability(Program,Vuln),
protects(Control, Program),
not(removes_vulnerability(Control, Vuln)).

Loading this into SWI-Prolog, one can now ask some questions, like:

22 ?- [approach4].
% approach4 compiled 0.00 sec, 0 bytes

Yes
23 ?- vulnerable(fonts,X).

X = attack-tool-2 ;

X = attack-tool-3 ;

No

This indicates that the fonts (a slightly silly asset, but I just happened to pick three vulnerabilities in xfs) are vulnerable to attack-tool-2 and attack-tool-3. Attack-tool-1 cannot exploit cve-2007-2103 because there's a (hypothetical) patch for it.

This approach needs to be extended quite a lot to be useful. The two obvious first extensions are a) an automatic loading of program/product vulnerabilities and exploits, perhaps from CVE and b) a model of the system under examination, perhaps as a graph relating assets, program/products and the controls which defend them. It would then be possible to have the system identify which controls are redundant or which patches need to be applied.

Another extension relates to the fact that some controls are themselves programs/products which may have their own vulnerabilities. An attack could therefore consist of a sequence of exploits which defeat or disable multiple levels of controls.

I guess now it's time to hit the books and coax SWI-Prolog into reading CVE from the XML, as well as representing the system as a graph.

What's Apparent to You . . .

. . . may not be apparent to me. Almost a throw-away line in a weekend newspaper article ( http://www.smh.com.au/news/national/sex-victims-saved-from-court-torment/2007/10/06/1191091420533.html ) states:

"And in a move against internet predators, the laws will create a legal assumption that a person who apparently sent and received an email did in fact do so. This is designed to stop pedophiles and perverts from escaping conviction on a technicality."

The question is, apparent to whom? The average user goes on what their email client displays in the From: field - but of course, this can easily be forged, as can the MAIL FROM: part of the SMTP exchange. I've explained all this before (see Tracing Emails), and even demonstrated it as part of an expert opinion in court.

The problem is that email headers can be forged, either by a sender or a receiver. Unless subjected to detailed examination and tracing, they should be regarded as being of very low evidentiary weight.

Big Babies

Perhaps not required reading, but certainly an interesting little volume for security practitioners: "Big Babies, or: Why can't we just grow up?", by Michael Bywater (Granta, 2006).

Bywater, now a Cambridge academic, first grabbed my attention through his acerbic "Bargepole" column in Punch magazine, back in the 90's. His latest epistle advances the notion that politicians, media and Big Business all conspire to keep us in a state of infantilism; we Want It Now, we want what celebrities have, we want to be like celebrities, hell, we want to be celebrities. Our culture, the Mummyverse, requires not much more of us than to be silent, consume and die, and is happy to invoke various bogeymen - mostly recently, the spectre of The Terrorist - in order to get us to Shut Up And Do What We Are Told.

Bywater touches on subjects of interest to infosec professionals: privacy, the "new religion" of risk assessment, transport security, advertising copy for software. He reaches a climax with a list of 50 ways Not To Be a Big Baby, many of which have long been among my own favourite rants (and to which I will probably return, in due course), such as:

"27. Cultivate commensality. The art of dining together is one of the great cornerstones of civilization.

"28. Never do business with a company offering 'solutions'. It is a pernicious weasel-word, not just because it is pompous and self-aggrandizing . . . but also because it is telling us that we have a problem. That, since we are grown-ups, is for us to decide.

"30. Demand - and display - good manners."

The book is an over-the-top polemic, of course, but that's its best feature. But as you chortle, it is hard not to realise Bywater is providing an insight into your own uneasy feelings about the changes in our culture. A hefty six-page bibliography confirms that this is not just a stream-of-consciousness rant but the product of some serious research and thinking.

Still, it's funny as hell, and enormously satisfying.

On Naked Emperors

A spat has blown up on the Linux Kernel Mailing List over the merging of SMACK and/or AppArmor into the kernel, vs SELinux's use of Pluggable Security Modules. The NSA's Stephen Smalley asked Linus Torvalds:

You argued against pluggable schedulers, right?
Why is security different?

which prompted this reply from Linus:

Schedulers can be objectively tested. There's
this thing called "performance", that can
generally be quantified on a load basis.

Yes, you can have crazy ideas in both schedulers
and security. Yes, you can simplify both for a
particular load. Yes, you can make mistakes in
both. But the *discussion* on security seems to
never get down to real numbers.

So the difference between them is simple: one
is "hard science". The other one is "people
wanking around with their opinions".

(For the whole exchange, see http://kerneltrap.org/Linux/Pluggable_Security).

Once again, information security proponents get blasted for being unable to objectively back up their cases. We have got to get away from basing so much of what we do on opinion; so often, when called on this, we end up looking like an emperor who just lost his clothes. And it's happening more and more often.

What's in a Name?

As a technology writer for more than 30 years now, blogging seems like a busman's holiday more than a trendy promotional activity. Still, many events over the last few weeks have pushed my buttons; "Gee, I should write that up somewhere", I've thought on several occasions.

The only stumbling block has been coming up with an incredibly witty, punny, title for a blog. In the end, falling back on the breadth of my early education, I decided simply to name the thing in Latin. Now there's class.

You figure it out.