Just completed my first (unofficial) week out there in the field, and I have to tell you it feels good to get back out there, roll up my sleeves and get into the mix of the challenges the real-world is facing.
Over the next several posts, and as I meet with people and work to solve problems, I'll anonymize and document some of the challenges I organizations facing and how they're (attemptively) solved.
Over the last few days I got to sit down with a few CISOs and hear several different medium-sized enterprise stories. One of them struck me, and I think it's worth sharing because it exemplifies what I've been talking about on this blog before.
When you're an organization that's grown over the years as various inter-dependent departments, it's difficult to really say what your IT strategy is, much less how IT Security has grown. Organization A is a "loose confederation" of siloed business units all brought together by the common need for corporate revenue. While they share infrastructure, overlap on resources, and fight for budget - they all largely do their own thing.
Organization A's challenges
The challenges were laid out like this:
- Widespread, [irrational] organizational fear of "chaotic actor
- No centralized software security program
- No control over 'deployment' of software, network
technologies, or corporate endpoints (servers, wor kstations, etc)
- No centralized log aggregation, leading to poor enterprise visibility
- Duplicate spending (often accidentally) by groups
who don't know of each other
- One central security organization, accountability
for 'corporate security' without direct oversight over business units
The big question we spent a bit of time on is what
Saying 'change management is job 1' and actually f
My recommendation around change management went li
- Perform a mapping exercise of the network topology
, mapping out ingress and egress points carefully
- Stand up a centralized logging SIEM, and get the r
ights to dump all logs to the central SIEM
- From that central point of intelligence, write rul
es and policies that detect changes made to networ k
- Carefully monitor for downtime, and link events to
rule changes (when ever possible)
- Perform analysis on unplanned downtime, versus change velocity - and attempt to identify
changes which conflicted, failed, or otherwise ca used unplanned downtime
- Calculate the minutes of downtime, and man-hours w
orked to return back to stable-state
- Analyze how much of the unplanned downtime could have bee
n avoided by a centralized change-review organizat ion, and propose to remediate this situation thus saving the compa ny X man-hours of work, and Y hours of unplanned d owntime
A lesson for everyone
Taking a step back and generalizing into something
Basically this is how I've worked it out to priori
It's really all about stabilizing the patient, fir
Once they've got the environment sane and stable,
The next step is analysis from data you can collec
Prioritization is all about knowing what's importa
Optimize is always the last step ... and whether y
I'd love to hear your thoughts on this, and maybe suggestions for this organization on moving forward? What would you do, or advise them to do? Let's hear your thoughts or ideas. You can always find me on Twitter, and I encourage you to engage on the #SecBiz hashtag - don't forget to leave your Twitter handle if you leave a comment below - I'd love to make sure I credit you properly...and we can talk it over.