Re: [logs] Signatures

From: Stephen P. Berry (spb@private)
Date: Fri Aug 20 2004 - 15:23:50 PDT


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Devdas Bhagat writes:

>Ok, how would you get a generic system to enunciate a risk analysis?

Without delving into messy implementation details, I can outline a grossly
simplified version of how I'm attempting to do this.

First, let's consider a simple example.  Let's say we're a financial
services company.  We have a frontend web server, foo, that accepts HTTPS
connections from our customers, pulls encrypted and signed blobs out of the
stream, and forwards these blobs to a `middleware' server, bar.  It (bar) in
turn decrypts the blob, verifies a digital signature on the resulting
plaintext, then connects to a backend database server (baz) to insert the
plaintext itself into a table.  We also have corporate web server, quux, which
has a dozen whitepapers describing our service (the reading of which can
induce a net information loss) and other advertising/marketing fluff.

These four machines (foo, bar, baz, and quux) have different values to
us[0].  They almost certainly have different liabilities associated
with them, and (assuming we don't have a perfectly flat network topology
with no filtering, firewalling, or ACLing) different exposures.  Assuming
we've got different flavours of OS and different applications running on
each of these machines, we've also got different threat levels based on
these variables as well.

So in our system we create four objects, one for each of the machines.
We then list all of the things they're allowed to do, and what the
system dependencies are (for the latter, think of something along the
lines of how nagios/netsaint handles machine dependencies).  We can
also add information about what the system does, the applications it
runs, and so on.  I.e.:

	foo
		HTTPS from {customer1, customer2, customer3, ...}
		HTTPS to bar [we'll assume we talk to our middleware
			via HTTPS]
		Runs apache 2.0.x under OpenBSD 3.x/x86

	bar
		HTTPS from bar
		SQL to baz
		Depends on foo
		Runs BEA WebLogic under Solaris 2.x/SPARC64
		Does decryption and signature validation of customer data

	baz
		SQL from baz
		Depends on bar
		Runs Oracle 9i under linux 2.6.x/AXP
		Stores customer data

	quux
		HTTP from !{foo, bar, baz, quux}
		Runs IIS 6.x under WindowsXP/x86

What does this simple model tell us?  It means that attacks against
foo are also effectively attacks against bar and baz as well---because
if foo gets taken down, we loose the services on bar and baz as well.
Further, we can automagically bump the severity of any event originating
from foo directed at bar:  if someone from some random host attempts to
log into bar, then that's bad;  but if we see foo attempting to log into
bar, then that tells us not only that there's a threat to bar, but that foo
has probably already been compromised[1].

Further, we can prioritise classes of exploit directed at these different
hosts.  If foo is DoSed, we're no longer doing business, whereas if quux
goes down, then we're just not advertising.  If someone gets shell
access to foo, we're losing our data path to the backend database, but
we're not concerned about data integrity, whereas if someone gets a shell
on bar, customer data might have been modified or bogus data inserted.  This
compromise on bar would expose whatever transactions were processed by
bar during the intrusion, but a similar compromise on baz potentially
exposes all of the customer data stored on it.  And so on.

We can also do trivial things like comparing the target application/OS
of some attack signature with the application/OS to which it is directed.
In other words, we worry more about IIS exploits directed at quux than
those directed at foo.

All of this allows us to prioritise alerts/warnings.  It also has the
potential to present more information to the guys in the NOC or whoever
it is that's the primary consumer of the output---who may not have a
intuitive grasp of the underlying network architecture.  I.e., "It appears
your front-end web server is portscanning your database.  This indicates
a compromise of foo with a high degree of confidence."  This is almost
certainly a Big Win in terms of triage---getting the initial alert
translated into a call to the pager of the responsible admin.


How do we actually assign values to all of the variables?  Well, that's
the threat assessment/risk analysis.  And it's not a trivial problem.  But
merely being able to assign such values and define the transitive relationships
between the different components of your network would, I would contend,
in and of itself be a Big Win.

Does this make more sense?  What is described above obviously isn't
an algorithm or anything like that---it's just the basis for a model that
allows you to say more things about the state of the
network/systems/applications/data within the analysis/monitoring system.





- -spb

- -----
0	And to the attackers, for that matter.  While it is worthwhile to
	realise that information security is not a zero sum game (although
	subsets are), that's not something we have to worry about here.
1	Possibly for some light definition of `compromise' which includes
	authorised lusers not following access policy (i.e., failing
	to connect via a specific proxy or some such).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)

iD8DBQFBJnnLG3kIaxeRZl8RAkXGAJ4jwPyuco5+Wo5uQj8Xke6Sk2XTawCgt2C+
x3Q5Ok/WgauQTktxY+zRtiE=
=Ko15
-----END PGP SIGNATURE-----
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis



This archive was generated by hypermail 2.1.3 : Fri Aug 20 2004 - 15:25:09 PDT