-----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