I've worked a lot in security environments where strategy is unclear. I've worked a little in places where strategy is very clear. I've NEVER worked in a place where the security strategy is clear.
"That sounds like a sweeping statement, Rob", I hear you thinking... Maybe. But someone, who has to remain nameless sadly, said to me (not the rest of the room unfortunately!) recently in a very large strategy meeting: "Why do we need a security strategy? Don't we just need to reduce the risk involved with following the corporate strategy?"
This was said more as a statement than a question. The person "asking" was senior within her organisation, so I should have expected it, but it was one of those moments when someone says something SO obvious with such clarity of thought that it floors you for a response. I nodded and muttered something obvious about risk management, and that I disagreed with what we were discussing in the meeting, but my mind was already elsewhere. I am not usually lost for words, less so an opinion, but this silenced me, both verbally and mentally for some time.
When I had just left University nearly 20 years ago, before phones were ubiquitously mobile in nature. I answered the landline telephone in my parents house and the caller recognising my voice said "Hi Rob, it's Simon" my friend from University, we had lived together for 2 of the 4 years of the course we were both on, so we knew each other well. We chatted for 10 minutes about meaningless things, before a reference to something in my home town made me realise I had never lived with him, but in face he was a Simon I hadn't spoken to since the previous summer, checking to see if I was back from University. A silly digression, but for a couple of minutes my mind went into freefall, trying to work out if I'd said anything that could have revealed me as a pseudo-friend, faux-talker or wrong-Simoner. Realising Simon was still cracking on as though time had never passed, I cracked on. Back in the strategy meeting, my mind was doing the same thing, but over a career spanning 15 years, inspecting strategy documents and management recommendations for evidence of my fraudulence.
I have spent many days, weeks and months of my career, my life, writing long strategy documents, they all talk about process maturity, risk management, control improvement, architectural patterns, blueprints, yada yada... and whilst it's less bullshit than the "we will identify synergies with the Internet of Things and Big Data" type rubbish that consultancies tend to churn out, it always seemed to me to be more mechanical than a strategy.
A strategy, after all, is an OVERALL aim, and a useful business strategy is one which differentiates your business. So whilst a departmental strategy might be to reduce risk, or improve processes, surely that is a) what every security department everywhere should be doing, and b) what the whole business should be doing? In the first instance, it's not a differentiator, in the second it's not a security strategy...
So there you have it. No such thing, I was making it up all along. I'd love to be told (why) I'm wrong.
Saturday, 1 August 2015
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.
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...
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...
Monday, 29 June 2015
Keeping My Own Agenda
6 years have passed since my last post appeared. I've been busy. I've stayed in touch with a few of you. I've had 3 children, many employers and a whole lot more experience in Security. Some of those employers haven't liked me to blog, some have specifically disallowed it. I work largely for myself now, so I'm dabbling again. I still have 3 children, so possibly less regularly than previously.
Last year I got asked to stand in at an event for a colleague after he let down the organiser at the last minute. The topic was IAM, which is at the periphery of Security (to me, please don't fill the comments with your opinion on this), more Operational and certainly not central to most CISOs I talk to (not in this country anyway).
I was late for the first talk as I had missed a flight. The talk was not loaded onto the PC at the front. I was nervous, the presenting PC was not set up with a remote, so I had to sit down. During a talk I moderated, one speaker overran and I didn't intervene as it would have been rude to do so in my opinion. I was nervous by this stage, and not enjoying myself. I was not doing Security, and I wanted out.
I was subsequently criticised for not preparing, which for someone as anal as me is quite a blow. It is also not true, unless you count 15 years of IT Security not being preparation for talking about IT Operations. OK, tongue out of cheek... I HAD prepared, but I was not talking about something I knew well, by request of the criticiser.
I recognise the criticism now for what it was, an idle comment by someone who had felt out of control, but it left me feeling out of control myself. Something which doesn't happen easily.
I am now mainly engaged in Security strategy and consultancy work for a (very) large communications company as subject matter expert on a very large programme. I love it, every day. When the programme started, I have to admit I was not an expert in the particular topic, again. I was the one eyed-man in the kingdom of the blind however, and I have fantastic support from competent people around me. We are making fabulous progress, and I am made to feel like a genius daily or weekly.
If someone is criticising you negatively, it is their problem, not yours. If someone is telling you how to improve, take it on board, but if you don't WANT to do it, don't. I have been told that I am not suitable for running a business, and yet I am running 3 to one extent or another (2 of which are profitable even!)
I was told that I couldn't write at the age of 27, and yet I contribute to magazines, write exam questions for Security qualifications, this blog of course, and even have a few entries in books. One day I will write my own, but when I feel like it.
So what's happened in 6 years? Have I grown up? Well, maybe a little.
Last year I got asked to stand in at an event for a colleague after he let down the organiser at the last minute. The topic was IAM, which is at the periphery of Security (to me, please don't fill the comments with your opinion on this), more Operational and certainly not central to most CISOs I talk to (not in this country anyway).
I was late for the first talk as I had missed a flight. The talk was not loaded onto the PC at the front. I was nervous, the presenting PC was not set up with a remote, so I had to sit down. During a talk I moderated, one speaker overran and I didn't intervene as it would have been rude to do so in my opinion. I was nervous by this stage, and not enjoying myself. I was not doing Security, and I wanted out.
I was subsequently criticised for not preparing, which for someone as anal as me is quite a blow. It is also not true, unless you count 15 years of IT Security not being preparation for talking about IT Operations. OK, tongue out of cheek... I HAD prepared, but I was not talking about something I knew well, by request of the criticiser.
I recognise the criticism now for what it was, an idle comment by someone who had felt out of control, but it left me feeling out of control myself. Something which doesn't happen easily.
I am now mainly engaged in Security strategy and consultancy work for a (very) large communications company as subject matter expert on a very large programme. I love it, every day. When the programme started, I have to admit I was not an expert in the particular topic, again. I was the one eyed-man in the kingdom of the blind however, and I have fantastic support from competent people around me. We are making fabulous progress, and I am made to feel like a genius daily or weekly.
I guess I have grown up then, not just by being a Dad to 3 insanely energetic boys, but by learning what is important to concentrate on. The most important message I can bring back from my time away is:
Don't listen to anyone except yourself, unless they are saying nice things about you, in which case, don't get big-headed.
OR
Other people have their agenda, keep your own.
If someone is criticising you negatively, it is their problem, not yours. If someone is telling you how to improve, take it on board, but if you don't WANT to do it, don't. I have been told that I am not suitable for running a business, and yet I am running 3 to one extent or another (2 of which are profitable even!)
I was told that I couldn't write at the age of 27, and yet I contribute to magazines, write exam questions for Security qualifications, this blog of course, and even have a few entries in books. One day I will write my own, but when I feel like it.
Subscribe to:
Posts (Atom)