Friday 17 July 2015

10 Bits of Logging and Monitoring for Architectural Success

I've been involved in a logging and monitoring project recently, and realised how close to their chests most vendors and other companies doing this type of work tend to keep their methodologies. And although a lot of people have done L&M projects, I wonder how much of the knowledge is retained, improved upon or disseminated?

With that in mind, I wanted to give a quick round-up of what I think makes a successful L&M architecture, completely generically, and without reference to tools:

1. Know your assets

If you don't have a CMDB, go and get one and postpone your project by a year. You will need AT LEAST your business critical assets listing, preferably with a quantifiable measure of their criticality assigned.

2. Map Business Risks to Technology Use Cases

You do not want to collect every log your infrastructure creates. If you know what risks your business faces, create use cases which reflect this - do they make sense? Can you collect logs that represent these use cases? This is not a quick process - I used specialists for many months to create this information.

3. Implement the Use Cases as rules

The Use Cases need to be implemented as rules, so you'd better be able to describe them in terms of collected and collated/correlated data...

4. Log for compliance as close to the source as you can

Don't waste bandwidth sending 100% of your logs over the network. Logs can be kept online in whizzy tech for a month, indexed and expensive, but when archived, you can keep them in your bog standard cheapo SAN storage.

5. Reactive monitoring only tells you what's already happened...

Obvious really, but for a really useful log monitoring solution, you should find something that can look for unknown signals in the noise, anomalies that might indicate attack, even if they are only minor.

6. ...but you still need it.

Once you've found a signal, create a rule for it, so you can see it happening!

7. Incident repose and Forensics teams need the same data as Compliance

Those log stores I mentioned, make sure you can get them back online, indexed and searchable pretty quickly when required. In an emergency, you don't want to wait a month whilst Johnny Forensics searches for an IP address or username....

8. Threat Data

Get some. There are a lot of technical feeds out there, but Threat Data and Threat Intel are not the same thing. Threat Intel needs people power and brains, not tools... as ever, the tools just help the processing of data sets.

9. Workflow/Case Management/Incident Management/Ticket Handling

Are all basically the same thing, just from different angles. SOC staff need to pass tickets, their management need a workflow to be followed. When an incident occurs, that ticket needs to have sensitive data added, which turns it into a case - this may involve reference to a different tool, the monitoring platform itself can often be used for this.

10. Automation

The nirvana... once everything runs, the tools and processes are a mass of moving parts. These inevitably suffer bottlenecks, usually waiting for humans to process data. Where this requires technological input/output, this can often be automated outside of the workflow technology itself.

I won't be there for a while, and some of this will need updating before I get there, but from what I've learnt so far, I hope this is useful to someone else out there embarking on an L&M project. You're welcome.

Thursday 2 July 2015

Kids 1 - InfoSec 0

My son broke one of his brother's toys this morning - they were growing crystals on paper (yeah, it's all science and engineering fun in this house) and Number 1 son knocked Number 2's crystals off. 2 is 4 years old and cried, hard. 1 is 5, and came running to me to explain what had happened, saying he was going to break his own crystals so 2 felt better. (Number 3 is 9 months and squealed with delight whilst vomiting on his chair.)

I spent a couple of minutes explaining to 2 that we could fix it by collecting up the crystals and starting again (yay, go science!) whilst 1 wailed and took himself upstairs for a self-administered beating of some sort (science may be lost on this prima donna).

When 1 came down, I explained carefully to him that breaking his own stuff wouldn't fix 2's. What does help is saying sorry and helping 2 to do something positive. My kids understood this. I fear that Information Security does not.

I hear criticism of other people every single day, someone isn't very good at xyz, they don't have the expertise, they are too junior. This year's InfoSec was closed to students not working in InfoSec because they are just too damn stupid to understand it (not really, made that last bit up). Dur.

I've resolved to be nice about someone, or to someone directly, every day. The more junior, or more misguided I've deemed them to be from initial judgement, the better. I hope I can make it last, against my cynical nature, perhaps my kids have taught me something after all...

MadKasting