InfoSec vs NetOps: Is Datacenter Detent Possible?

“Oh, the farmer and the cowman should be friends” – Rogers & Hammerstein, “Oklahoma!”

The modern office environment has its fair share of rivalries, competitions, and friction. In some companies, interdepartmental politics abound,  project teams put “frenemies” in direct contact with each other, or a heated exchange can impact an entire career. This affects IT Professionals as much as any other career area (some would say more).

There’s one IT rivalry I have seen consistently in almost every organization, and that’s between the team responsible for security (InfoSec) and the team in charge of network monitoring and operations (NetOps). In many companies, the dynamic is almost co-predatory, with each side attempting to completely obliterate the efficacy and credibility of the other.

The classic characterization is that

1) the Monitoring team wants/needs complete access to all systems in order to pull reliable and accurate metrics;

2) While the InfoSec team wants to lock everyone out of all systems in the name of keeping things “secure”

But it’s patently not true. At ThwackCamp 2015, security industry powerhouse Charisse Castagnoli (c1ph3r_qu33n here on Thwack) and I sat down for a frank talk about the pressures of our respective roles, and then brainstormed ways to get InfoSec and NetOps/Monitoring working together rather than in opposition.

One of the things we hit on was the good old lunch-and-learn. A lot of the friction between security and monitoring comes from a good old communication disconnect. Not knowing about the current pressures, priorities, and projects on the other side of the cube wall typically leads to frustration and loathing. The solution is to regularly sit down to hash it out, and find ways to augment, rather than short-circuit, each other’s efforts.

During our talk Charisse and I challenged viewers to set a table, along with a meeting request, and record notes of how the conversation went (You had a food fight? We want to see pics or it never happened!). Post those notes (and pictures) below, and we’ll select some of the best ones to receive 500 thwack points.

  • I'd like to give an example where security through obscurity - nowadays - helps secure the node/network.

    A non-obscure system:

    Port OUI default Cisco, SSH daemon running on default port 22. Operative user account is default admin.

    Attacker fingerprints and port scans the node, finds port 22 open, launches SSH tools and attempts to break-in (Okay, low tech approach)

    An obscured system:

    Port OUI changed, SSH daemon running on custom port. Operative user account has been deleted and replaced.

    Details of this type of obscurity carried out on this particular node is documented on an obscured system emoticons_happy.png

  • I appreciate the reply.

    I'm not sure what Charisse (c1ph3r_qu33n) would say about security by obscurity being a "first and foremost" aspect. I actually think that this technique has been proven false time and again since in the days of port scanning, massive breaches, etc nothing is truly obscure just because it's not discussed or published.

    That said, I agree that NetOps and SecOps often seem to be working under a different set of values and requirements. That often comes from the top down as much as it does from internal philosophy.

    The way past it - I truly believe - is to build a habit of inclusion. Yes, the InfoSec folks will make our live miserable locking things down. But if we can create a shared sense of purpose (Hey, I'll give you all this juicy monitoring data...) then they will be more willing to both help us get things tightened up, and understand when we ask for exceptions and variances because the tools require it.

  • Agreed. Lazy habits (monitoring "needs" root/admin on everything; security "needs" everything locked down) exacerbate the issue.

    Combined with thinking in absolutes like always/never, must/can't, etc it's easy to see how bad blood builds up.

    Like Charisse (c1ph3r_qu33n‌) and I discussed was that WE (ie: the members of those teams) are the only ones who are going to fix this.

    Thanks for the comment!

  • I think that one of the contributing factors to the battle between the two is that it's not uncommon for the monitoring folks to just want "everything" opened up to them versus taking the time to identify and open up only the specific bits of access necessary.

    At the end of the day there should be a significant amount of overlap between the InfoSec and NetOps data sets and tools should be consolidated whenever possible for both efficiency consistency gains.

  • We really don't have this problem too much where I am now.  I have definitely seen it in the past.  In most places, NetOps and InfoSec have no choice but to work together.  InfoSec is usually handling the firewalls and IDSs/IPSs, but the NetOps teams are handling the routers.  The routers require ACLs and routes to be implemented, so the InfoSec team needs the NetOps team's support as well.  I see more problems with Network teams interacting with Server/Information Systems teams.  There seems to be a lot of butting heads there.  Most of the time is does come down to communication, or lack there of.

Thwack - Symbolize TM, R, and C