Back to Basics? The Role of the Business Information Security Officer

Recently I’ve been giving a lot of thought to the role of information security practitioners in an organisation. The role of the CISO, CSO and IT security are fairly well embedded in many industries by now, and Carnegie Mellon’s ‘Governance of Enterprise Security’ 2010 CyLab report notes an increase in the number of CSOs [1]. This isn’t a surprise given the environment we find ourselves in, but what are they there to do, what are the differences, and how do we measure their value?

It’s an intentionally broad question as I don’t want to focus on the detailed view based on company market, size, location, etc (although I acknowledge these are critical factors to consider). Rather I ask about the principles of information security. We will all probably agree that the CISO job spec will address topics such as security strategy, policy, awareness, incident response and in some cases business continuity. What seems harder to get consensus on is the level of responsibility assigned to this role.

Bill Brenner at CSO Online [2] ran a series of podcasts recently which discussed this topic in some detail. He interviewed CISOs and asked questions around reporting lines, the difference between CISO and CSO, and what should a CSO be worried about.

The key points that stood out for me were:

1. Many organisations don’t have both a CISO and CSO;

2. However, a CSO often has a focus on physical security only,

3. While a CISO is often a promoted IT security administrator.

I find these results a little worrying. A CISO should be responsible for information security, both physical and electronic. Reporting lines need to reflect this, so they can have a line into the CRO or the CIO, proving the latter is also not still solely focused on IT (which is often still the case). Physical security is an element of information security, although it is broader as information is not the only asset the CSO should be worried about protecting. I can believe the last point about the evolution of an IT security manager into the role of CISO – the security function originated from IT (typically network and server admins), and organisation’s realised the need for security to gain a higher presence with senior management and the executive, and so promoted those that knew the most about the technical aspect into the CISO role.

So in terms of responsibilities, I don’t think there should be too much ambiguity. The often grey areas in terms of requirements for a CISO and/or CISO depend on the DNA of the company (i.e. its structure, delegation of responsibilities and classification of critical assets). Regardless, they are there to drive strategies, implement and monitor programs that manage the risk of (information) security in the context of the business.

Measuring value is harder to quantify. To start with, I believe any role that carries the title of ‘officer’ comes with a high level of responsibility and accountability. However this is difficult to implement for the security officer who often sits at the centre of an organisation, while the actual risk is borne in the divisions – areas not directly under this person’s command. Also, a large part of a CISO’s ability to succeed will depend on the responsiveness and cooperation of the business. Working in audit I appreciate that it can be very difficult to identify and manage risk if the business does not have a culture of open and honest communication. It can be a double-edged sword, as the business may want to see the value the CISO provides (despite their exec-level mandate) before warming up to them.

These days organisations can be very complex in structure, and often evolve to match or make market conditions, take on new lines of business, etc. So it would be a little unfair to expect the CISO to solely keep tabs on the changing security risk landscape and to measure their success in isolation. Rather I believe an equally important factor to gauge is the amount of interaction with other security, risk and assurance provider practitioners in the business. The collaborative approach will have a greater chance of success as coverage across all business processes and technologies will be more effective, not to mention leveraging of different skill sets and more resources. I’m not sure if the performance of a CISO always includes this measure, but it should.

On another note, organisations are not immune to the risk of inadequate security functions, as with any other specialist function. Many employees, including senior management, may not fully understand the role and responsibility of security officers. Thus they will find it difficult to measure the success of these staff. For example if no security incidents occur over the course of a year, was it because the security function was effective in thwarting any attacks or events, or were they not good enough to detect any incidents that did take place? I don’t see a simple answer to this. Often it is those who shout loudest in an organisation that come across as being in control, so if this is the CISO, then it would be difficult for another non-InfoSec person to challenge their effectiveness, while if it is the CIO or CRO that shouts loudest, then it will be very difficult for the CISO to gain respect with and access to the execs.

For me the most important elements of a security function are accountability, responsibility and ownership. It is a role that requires someone to be practical yet, in my opinion, also sceptical (almost paranoid) as someone in the organisation needs to play the role of asking ‘what if’? or ‘what could go wrong?’. And they need to be at a sufficient level in the organisation to discuss and challenge senior staff.

If I were to draft a CISO job spec I would certainly include the details at the start of this blog, but would also include the following:

Responsible for managing the security of the information assets

Accountable for strategies and initiatives that improve insight into security protection and monitoring

Responsible for implementing a culture of ownership relating to company information, and driving related ethical and moral standards in accordance with corporate governance best practices

• Actively involved in driving collaborative assurance and risk management processes with stakeholders such as internal audit and operational risk

Responsible for implementing a dynamic control environment, leveraging off continuous monitoring processes (I would certainly recommend looking into the SANS Top 20 Controls [3])

I believe that by using the correct language the role and expectations can be clearer, leading to a greater chance of success for the CISO, which is of course what we all want.

In terms of personal characteristics, I would include the following:

• Must be knowledgeable of the business and practical in aligning security business strategy and operations (this may be a challenge if pure IT-folk fulfil the CISO positions)

• Must have the ability to exercise professional scepticism when identifying and assessing risk

• Must have the ability to quantify information security risk in terms of the business

 

I guess the next question is: What should the CISO’s team look like and how far should they reach into the organisation…?

References

1 http://www.cylab.cmu.edu/outreach/governance.html

2 http://www.csoonline.com

3 http://www.sans.org/critical-security-controls

 

Information Class-ed-ification

A poll of information security practitioners might suggest that Information Classification is a task that we all talk about, but that is operationally not feasible in highly complex environments. Based on the apparent practical difficulties in implementing such a policy, it is not uncommon for organisations to try work around this, leaving the draft document to gather dust.

Some of the challenges include:

• Getting people in the business (that understand the information and understand the risks to the information) together to classify information.

• Forcing the myriad of business information into categories such as Classified, Public, Internal, or other.

• Identifying and tagging information based on classification.

• Monitoring a control environment that spans systems, physical locations and nearly every nook and cranny of a business.

I tend to disagree with this approach. The classification of information (i.e. one of the organisation’s key assets) is a fundamental step in determining the risks related to information, and determines the types and levels of control that need to be implemented to adequately protect the information. Everything else hinges off understanding this principle, from implementing layered security, pulling this together into a logical architecture, to preparing for future threats in our changing landscape. If an organisation has a clear understanding of what information they have, who uses it, where it is stored and processed, and what its value is, then the control environment fits properly over and around the people, processes and systems that manage the information. New threats are then exactly that – threats that present different attack vectors that can be easier identified and lend themselves to a (more) quantifiable assessment of risk.

Without a proper information classification process, the following risks become apparent:

• Unsustainable controls: There could be a mismatch between the strength of the controls and the value of the information. Stronger controls require more resources and cost more, so this could mean security budgets are misdirected, or highly sensitive information is not adequately protected.

o In the above scenario what could also happen is too much information is pushed into the ‘highly sensitive’ category which requires these stronger controls. Over time these will become unsustainable and could deteriorate. For example if all databases were in this classification, then all system, application and database administrators may require the top level of access (we know they don’t, but they are sometimes very good at justifying they do!). This results in no segregation between types of information which is pointless. You may as well have few controls that allow the same level of access (which still present a high level of risk of course).

• Silos of controls: Regulation is hitting businesses from all angles. Due to time pressures (or pressures from different parts of the business – legal, clients, COOs) a bottom up approach to plugging the gaps might be forced. This could result in a silo’ed approach to implementing controls. The net result could be layering controls over the same type of information, no single view of what is happening (making monitoring difficult), and in general simply resource wastage.

I would take this problem a step further. In many cases it is difficult to define and implement a security policy without a clear indication of what the business is trying to achieve in the relevant area. Social media is a good example – how you best manage the associated risks will largely depend on the business drivers and strategic objectives relating to social media and networking. So to provide context to an Information Classification policy, there should be an overarching information management strategy. The organisation needs to 1st define the what, why, who, how, when, where’s of information as well as other principles (avoiding duplication, making information accessible to the right people at the right time, etc), before they can determine how best to secure this information. How many organisations have such a policy or strategy document?

As a starting point – rather than trying to classify information based on sensitivity (as per a typical information classification policy), rather identify the information first based on such categories below:

• Transactional

• Employee

• Client Information

• Business strategy

• Marketing

• Financial (reports)

• Risk issues and controls (e.g. audit reports, incidents)

Then devise a set of controls that can be mapped to these types of information. If the correct controls are designed and implemented then the most sensitive information will naturally have stronger controls in place. This top down approach can help with regulatory requirements. I.e. one can define requirements for PCI, POPI, NDA etc, etc and then apply these requirements to the ‘client information’ set (or whatever the case may be).

My last point on this is that I believe the top-down approach lends itself to the collaborative risk management and assurance approach as there is always a ‘big picture’ to start with, and the goals and objectives of each team (InfoSec, Operational Risk, Audit, Privacy, etc) become clearer. Reporting on this overall process will be easier and more tangible, increasing your chances of board-room understanding and buy-in.