Logging Sins, Hierarchical Tuples and Effective Security Architecture

Logging Sins, Hierarchical Tuples and Effective Security Architecture

There are many sins in logging, none so amusing than this one I saw recently:

+++ ALERT : SEVERE : Invalid Market Order Submission ... Hence, releasing the Trader Order in Panic... +++ALERT : SEVERE+++

In the old days, we used to return a number which was then looked up in a decode table. This lead to obscure code and errors which were quite severe when the DBA messed up the decode table...

However, as an aid to debugging, self-describing code can be useful. So if you're tempted, try tuples - they're quite neat. They're a feature of functional languages, in particular Haskell. Here are some real examples:

TIB.SEND.TOALGO.AMENDTRADERORDER
TIB.SEND.TOALGO.ORDER.CANCEL
LBM.CALLBACK.INVOKE
LBM.CALLBACK.RETURN

Without commentary, you can deduce what's happening with this code and these messages. Tuples are cool. They can also be used to describe design patterns. I wrote a paper a while back which I presented at the IISyG on Security Architecture Patterns - I'll post the deck soon on the enhyper subversion server. I took an idea from the Antipatterns book on naming of "antipatterns" and crystallised the methodology to this tuple for describing a pattern:

{GENERAL, LESS GENERAL, SPECIFIC, MORE SPECIFIC}

Applied to the concept of security, this tuple looks like this:

Generic Security Concept.Application Context.Application Instance.Configuration

So I came up with patterns which looked like this:

DataTransfer.BBCP
SecrecyJurisdiction.Authentication.SSH.PasswordlessCertificate
Authentication.Applicaiton.JavaClient.OracleOID

Now the beauty of this scheme is that people are lead to logically to the comprehension of the solution by hierarchical decomposition. Add the ability to have arbitrary tuple lengths and encourage stereotypes and you now have well known patterns which you can back by implementations. Now here's the killer part - get security risk to certify/risk assess the implementation so you now have effective security in a risk compliant manner.

Unfortunately, this bright idea foundered for two reason - banks are here to make money, not develop software and security risk guys found it difficult to think like developers.