The poor misunderstood security analyst: feared by the user community, reviled by networking staff and treated with disgust by systems administrators. Overworked by the "whack a mole" nature of incident response and overwhelmed by ever-increasing classes of malware and threats that never seem to stop. Is it any wonder that as a group, they are bitter, frustrated and generally stressed out?
It's a thankless job. No one is every happy to hear from the security team, because it usually means there's a problem: with an application, a device configuration or an infection on a user's desktop or device.
And even when the analysts manage to discover something in the early stage of the intrusion kill chain, they're often thwarted in their attempts at mitigation by bureaucracy or a general misunderstanding of what's at stake.
The result is a disengaged tribe of individuals who create a culture built on negativity and subversion.
So how do we stop treating our security teams as if they're an Island of Misfit Toys and start treating them like professionals? How do we encourage respectful conversations across teams that seem to always be at odds?
[How much control is too much? Join the discussion in "Information Security Strategy: Stop Punishing End Users."]
One place to start is incident response. An attack or a breach is inevitable, so it's better to have a plan ahead of time. Senior leadership should encourage productive conversations about risk before everyone is in the throes of responding to a breach. If you don't, your response is likely to be a chaotic mess.
The response plan should give the security team some leeway to do its job. If your house catches on fire, you don't stand next to the firefighter and tell him how to put it out. You get out of the way.
The team doesn't need a cast of thousands "helping" with the investigation; neither do they need micromanagement from senior management at every step. They'll feel frustrated and resentful if they have to beg for evidence in order to verify that they've successfully rooted out the source of the compromise.
The plan should also support the security team's processes for investigating and remediating the incident. They're trying to protect the business by following industry standards, complying with regulatory requirements and facilitating the filing a cyber-insurance claim.
The incident response plan should also outline the rules of engagement with well-thought-out documentation created by assigned team members. Communication processes during the incident should be standardized so that management doesn't feel disconnected during this sometimes-esoteric process.
By doing this well in advance of an attack, personal and professional boundaries are established and roles clearly defined. Make sure the response planning team includes a representative of each stakeholder from the enterprise. While not a guarantee of a smooth response, the plan sets the stage for a standard of behavior in what can be a very tense situation.
Another way to improve interactions between information security teams and operations is to shift the focus to a more strategic viewpoint by including security in the enterprise architecture. Ensure the organization's technical and service applications are well catalogued. Seek to understand the intersection of users and classes of data.
You might think "I've heard all of this before, but how do I make it happen?" Organizational change isn't easy--there must be buy-in at many levels. It also means that the security team must come out of hiding, start to understand the business and speak the language of management. Provide metrics and reports that executive teams can use to justify effort and expense. If you can't measure, you can't demonstrate value and the C-level is under pressure from boards and/or shareholders.
Security analysts must remind themselves that the ultimate goal of information security is to foster the business. It's easy to forget this when you're trying to stop the infosec train from derailing.
Many talented people are drawn to the information security field because they want to protect and serve the community. They can be important contributors to further the businesses goals, but only if they are treated with respect and included in the strategic implementation of a security architecture. Otherwise, they become disengaged and disenchanted by the never-ending, soul-sucking nature of constant incident response.Michele Chubirka, also known as Mrs. Y, is a recovering Unix engineer with a focus on network security. She likes long walks in hubsites, traveling to security conferences, and spending extended hours in the Bat Cave. She believes every problem can be solved with a "for" ... View Full Bio