July 06, 2013

Don't forget the Auditing

Yet another unfinished thought on auditing and system design - I cleaned up a little, but again - publishing from draft:

When it comes to performing information security, it's easy to get lost in technical solutions and overtly technical discussions regarding what you need to lock down your business.  With the complexities of password policy, application and network design, encryption algorithms, VPNs and firewalls all spinning around in your head, there is something very easy to understand that is at the core of providing risk awareness.

Auditing, not just logging of security events, either - but I mean good old fashioned auditing of your books and business transactions.  Keeping an eye on what's going on in your business may help you to identify when there's someone with their hand in the cookie jar - and it won't make any difference they got in to your network when you catch them in the act of siphoning off your accounts.

Supervisory function: I can't imagine that a bank teller would be permitted to leave the premises at the end of his or her shift if their drawer was short of cash.  Managers count them up and monitor whether or not their transactions line up and everything checks out.  In so doing, anything out of the ordinary would be reviewed and questioned.  The bank manager performs the supervisory function and is aware of the business rules that are applied to ensure proper operation of the business.  Even with automated teller machines in banks, this supervisory function is not forgotten - review of transactions and matching them up to the cash in the machine during cash outs help the banks ensure that everything is performing at least to some modest business constraints.

Constraints and Limitations: In the same instance, tellers are not given access to the entire bank balance.  Those who rob banks will likely tell you that robbing a teller these days is hardly worth the risk since the take will be very low.  It's probably more rewarding to hold up a cash business like a fast food restaurant, where the controls are not as involved and there's more chance of obtaining large cash drawer balances.  Even ATMs, which are entrusted with large cash drawers (since they're not likely to turn over their cash to a gunman), still have a limit to their losses based on how much they're loaded with.  When we design computer systems that access things like bank balances and accounts, we need to be reminded that business rules that impart these constraints and limits on transactions still need to be in place.  Even more so, hair triggers on constraints should lock down transactions from a source (such as a web front-end) that shows signs of being erratic.

No comments: