Who is to Blame? Defining Roles within IT Security
I was having a beer with a friend of mine recently – he’s a security analyst at a company that has experienced a data breach – and he was telling me about the ‘witch hunt’ going on in his company to find someone to hold responsible for the breach. That got me thinking about the whole concept of authority vs. responsibility in IT security. First, let me state that, in my opinion, the criminals that carry out the attacks are the ones that are ultimately responsible – the organizations being attacked are the victims. Unfortunately, as with many enlightened societies, we tend to assume that criminal activities are inevitable and that individuals and companies should take ‘reasonable precautions’ to prevent such crimes. However, that begs the question of what’s considered reasonable? On February 5 this year, FTC commissioner Maureen Ohlhausen said the FTC expects companies ‘to take reasonable precautions’ against data breaches but won’t provide a safe harbor that would indemnify them altogether from enforcement actions. Like the gas can manufacturer that was successfully sued because they didn’t include a large print warning not to pour gas from their cans directly onto a burning fire, we tend to hold the most accessible person or company with the deepest pockets responsible when something illegal (or just plain stupid) occurs.
So how does this impact IT Security professionals? One of the biggest gaps I’ve found while performing security program assessments for customers is the almost universal lack of clearly defined responsibilities and authority for IT security. The CSO/CISO is given a budget like everyone else and is typically expected to first apply that budget to meeting compliance requirements defined by various government and industry regulations, with the leftovers being used for the usual suspects of security tools. What they typically lack is the authority to drive any real improvements in IT infrastructures that are typically fragmented and undocumented, business users that can do pretty much anything they want to in the name of ‘supporting the business’ and privileged groups within the company that are supposedly savvy enough to take care of their own security. And yet when a penetration or data breach does occur the first group everyone points to is the IT Security team.
What’s a security professional to do? Trying to change the culture of an entire organization to be more security friendly is typically akin to tilting at windmills – it’s a great way to suck up time until retirement but it’s probably not going to be very fruitful. Here’s what to do:
- Work with upper management, the IT team and business teams to more clearly define roles, responsibilities and authority
- Identify potential use cases, including the different ways penetrations and breaches could occur, what the attack vectors are, what assets would/could be impacted, what the response process would look like, etc.
- Identify all of the associated assets (e.g. systems, applications, personnel, etc.) and who’s has responsibility and authority for each.
- Security team would then work with each asset owner to define and document who can or should do what in the event of an attack.
While this may be a somewhat complex and dynamic process in most larger environments, it has the advantage of getting Security, IT and management talking and generates awareness of the need to have clearly defined responsibilities and authority.
Structured risk program can also help raise awareness. By identifying, documenting
and quantifying the potential impact of the organization’s current security strengths and limitations the security team can provide management with a clear monetary understanding of what a breach could cost, and let management make the decision of whether or not they’re comfortable with it. The security team should be prepared with a list of potential projects that could be used to lower the level of risk, along with their associated cost and level of risk reduction. Management can then take ownership for deciding how much risk they’re comfortable with and how much they’re willing to spend on risk reduction.
Both of these activities can help a security team increase awareness of exactly how roles, responsibilities, authority and spending will potentially impact the probability of a penetration or breach occurring, and while being able to say ‘I told you so’ after a breach may not necessarily improve your career prospects, the resulting improvements in security can go a long way minimizing the chance of a breach occurring in the first place.