Event management kit can take a hammering these days: Use it well and it'll save your ass Who'd have thought it? Diagnostic event streams and log files are fashionable at last. But, despite many advances, they're still as big a pain in the backside as they were 30 years ago – both as a tool for observing and reporting security issues thanks to their sheer volume and, increasingly, the numbers of data types we're …
Just to find the day after the project which those file are for has been finally re-starter after a six month delay... or the user has returned from maternity leave. And these are just two examples.
It's always harder to act on something that "doesn't happen" without knowing the real context, compared to something that happens against set policies.
Every time an auditor asks us how we monitor for after-hours activity I ask why that is important. I point out that the Target (department store) malware turned itself on at 9 AM and off at 5 PM so its activity could hide in the noise of the daily operations. I point out that people simply walk away from their computers at the end of the day rather than shutting them down as policy says because they're lazy and their managers don't care so we'll always have after-hours activity.
I point out that monitoring for failed logins is far less valuable than monitoring for successful logins because, well, a failed login has no access to data. I mention that what the audit department needs to get HR to inform IT Security of people's vacation and out-of-the-office hours during the workday so we can monitor for use of their accounts while they're not physically present.
The auditor will stare blankly at me and say that their procedure says we have to be checking for after-hours activity. I reply that people never logoff and leave the applications running so we have a lot. They are happy that we're monitoring and the item gets its check mark. Audit Passed.
That's also the issue of creating a "clean" baseline by training on an actual network which is not already "clean" enough. Sure, some events are easier to spot than others (i.e the account logging in at 2am - but you could also limit log on hours...), but it's exactly to spot the difficult ones you'd need AI.
So once gain we are back to the need to train "wetware" so what is possibly wrong stands out - and hoping company policies don't get in the way, i.e. HR refusing data because they're "sensitive" - or an outdated badge system which is OK because the only important thing is HR checking worked hours, and they can do using batches that read data hours later.
These tools could be helpful, but once again they're not a magic weapon when there's a pre-existing mess no one really want to tackle.
I recognise your issue with the auditors. They are now commonly thwarted in coming up with useful issues because their scope and skills become narrowly silo driven. Thus in your example a business process issue must be fixed in IT even though its logically daft or impossible.
I used to get on much better when auditors knew how the business was supposed to work rather than, now commonly de-skilled, auditors simply going through a narrowly scoped checklist of tests in a spread sheet.
Point 1: "...Target (department store) malware turned itself on at 9 AM and off at 5 PM..." Yeah, so the more dangerous stuff is stealthy--but I wouldn't assume that the stupid stuff can't do damage as well.
Point 2: "...monitoring for failed logins is far less valuable than monitoring for successful logins..." I prefer to know the ratio between the two. And, while the really ancient stuff may be less relevant today, especially with the ability to automatically lock out accounts (which I was shocked to find not everybody does), modems and batch files were once used in the days before MS Windows to dial into phone systems and simply step through PIN's by an increment of one. And yes, what you wanted to do is figure if any of those guesses worked. So, if it ever skipped a number, that was the one you needed to check for breach.
Back in those old days, we actually read each and every log event. That would be crazy today. For defense in depth, it's wise to get your statistics to reveal those hidden patterns for all the possibilities--both stupid and stealthy--being fully aware that a stupid attack may be used as cover a stealthy one.
Have you considered a long series of unsuccessful attempts turning into one successful login ? Also do not assume criminal hackers work 9am to 5pm your local time.
Since you don't know what you can expect to, don't make any assumption. You know, assumption is mother of all screw-ups.
As luck would have it, I hired Mark and Bob Mothersbaugh to do some extensive Powershell scripting for our company, and did a fantastic job. The code structure was a little avant garde and not to everyone's taste, but it definitely worked for us. It really whipped us into shape and made us realize we weren't men.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
