Tag Archives: Manager

Stop Having Sex for the First Time – part 1

As someone who’s been working on an OSINT project lately, I’ve had many surprises and hurdles because there’s poor organization to our execution and little to no information sharing between security functions in the same department. I recently got access to a very important piece of information/tool that resulted in a huge discovery…..this is Oct, we’ve been working on this since July…. Unfortunately, this problem is not unique to this project, OSINT or InfoSec.

THE EXAMPLE:

The US Army structured a communications battalion with companies, made up of platoons/teams/squads etc.  and basically the personnel all had the same functional training background. One company, 30-100 people, would be folks who operated/maintained satellites, another knew cabling and wiring, another radios, and another of those skilled in networking/network communications. Whenever the battalion would go out to train, they would take a few people from each company throw them together like a patch quilt so as to have someone capable of each required skill for the mission. They’d send these patch quilt teams out to different locations with some training objective (usually to successfully establish a communication link, keep it up, and practice for war).

The teams contained the best of the best, people of varying skill levels, and competent (minus the token derp). Nonetheless, despite these groups being highly trained w/ above average intelligence, their execution was clunky, fluidity was all but present and they flat out struggled every time to meet the objective. Why? A few basic reasons (this list is not exhaustive) – nobody knew each other, we communicated in different ways, we could not anticipate each others needs or actions, there was no rhythm no synchronization. It was like being a virgin having sex for the first time every time, with another virgin. Sure, we got the job done, but it was rarely every “awesome”.

So the heart of the problem – teams, functions and activities were silos, not circles. Instead of being an elegant woven silk tapestry full of vibrant colors, we were a hideous patch quilt.

THE INFOSEC PARALLEL

We have the same problem in “Information Security” teams. There’s the Network Security Team, The Security Operations Center, and if you’re luck there is/are Pen Test, Intel, Forensics, and Malware team(s). So with all this awesomeness under one roof how could we possibly fail?

  1. Leadership Roadblocks – Managers sit in rooms making drug deals over resources and designing processes in vacuums.
  2. Lack of Communication/Sharing – None of the worker bees comes together on a regular with information to share, the “intel” that everyone needs.  Instead, data gets passed around/tracked in one ticketing system from workflow to the next team’s workflow if we’re lucky (and documentation usually sucks).
  3. Pissing Contests – we’ve got the “you will use *MY* ticketing system” mentality
  4. Lack of Integration – Let’s not forget that we’ve got all the awesome teams, and we’ve spent money (millions) on awesome tools and not a dime to integrate them, so “intel” sits hidden or is nearly/impossible to gather.
  5. That’s MINE! – Network “Security” teams don’t let anyone have read access to network logs (and only send silly/useless globs of syslogs to a SIEM), only the Help Desk is allowed to have remote access to a host even when a user contacts a SOC suspecting compromise of their host.
  6. Black Holes – Forensic team takes a compromised drive/image that the SOC quarantined and runs away to their cave never to be seen again, the malware team pops their heads up like a prairie dog when you say malware, you feed them and they run away only to pop out of another hole and say here’s your IoC and scurry down the hole.

Instead of being a highly functioning ecosystem of intelligent wild animals (face it, real InfoSec folks we’re just wild :), we’re a damn zoo and none of the animals get to play together.

OK….hopefully you get the point by now – We ALL play a part in this.

SURPISE! – Not really

So is it any wonder when there’s an attack on your organization that everyone flounders to some degree and for the serious ones you simply have to call someone in? [In all honesty, sometimes that actually IS the best and most responsible thing to do]. Is it any surprise that after the attack, all you do is prepare for the next one and you never really figure out anything behind it?  You never really operate in a preventative or offensive fashion.  You just sit around waiting for the next bully to steal your lunch.

So I ask, do you really want to keep having s3x the first time every time? I mean – practice **IS** supposed to improve performance thus making the experience better and better. Sure you have processes, that’s great & flow charts are awesome, but it only gets you so far. The SOC does it’s own little training on “here’s how we RESPOND to ABC incident” the NetSec-Ops team is doing their own RESPONSE training as is every other team that plays some role in a RESPONSE effort. The funny thing – the Windows/Unix/Server/App teams have a part too, but they’re never part of the training and nobody is invited to participate in the other team’s training.  BTW: where is all the info from your “lessons learned” going and where’s your “intel” sharing so you can start PREVENTING instead of just RESPONDING?

Back to our example….

The Army realized the shortcomings of their structure and began restructuring their communications units. They reorganized so that the groups that would fight together would not only train together, but live and work together. Battalions had companies that consisted of platoons with personnel from all the skills needed to be successful. These soldiers worked together every day, even began to learn about each other’s jobs. Light bulbs started going off, greater understanding and better communication emerged. They began to bond, to learn each other’s likes/dislikes, communication nuances, they began to execute with precision and efficiency. They began looking more like that expensive beautiful tapestry and acting like life long lovers.

So how could a company do this?

Well there is no one cookie-cutter solution that will work for every company, but here’s one novel underlying theme – locate them together physically if possible, gather them virtually at minimum. Granted there needs to be separation of duties and permissions, but that doesn’t mean you must have silos. Let the worker bees ACROSS GROUPS work together to define processes and make suggestions up through management. If that’s not possible, have regular working groups (weekly preferably) where they all get together. Sometimes the meetings will be intense with lots of hot topics/issues, other times they’ll have coffee and just bonding, but get them together

Another idea, Wherever your largest team is, usually the SOC, have seats for a NetSec, Malware, Forensics, and Intel Team members to work. The teams can rotate out who works over there, but have someone over there for 2-4 weeks at a time, let them “live & fight together”. Let them share information, watch the people that are part of your processes begin to work more effectively.

In the end, the goal is to have your team execute like they’ve been giving it to each other their whole life, not fumbling through sex like virgins for the first time, every time you need to respond to an incident. Then comes the next step, pillow talk the morning after – or sharing coffee and a bagel if you prefer.

Stay tuned for Part 2 where I’ll be talking about how to maximize this architecture for an intel team.