The Trials, Travail and Tribulations of Being a CISO: Part 2
In part 1 of this series I said that being a Chief Information Security Officer (CISO) is one of the least enjoyable jobs anyone could have. One of the main reasons is that information security policies and procedures generally are invasive and disruptive to people who are “just trying to get their jobs done.” But does a successful information security practice need to be invasive and disruptive to get the job done? I suspect that most information security professionals would say “yes” or “mostly yes.” According to prevailing opinion within information security, information security policies need to reflect the wishes and intent of executive-level management. Standards are in effect policies made more specific and tangible, most often with respect to prescribed technology settings and configurations. And at least in theory, effective CISOs are also the first line of enforcement for information security policies and standards. According to this line of reasoning, CISOs thus must not only create requirements, but they must also become policemen who determine whether or not their requirements are being met and put pressure on individuals and organizations that are non-compliant. It is a small wonder, then, that CISOs and their staff rapidly become so unpopular within their organizations.
Another view of the way that so many CISOs and information security practices in general have functioned for decades is that they push requirements out to employees and others such as contractors. But there is another approach to the problem–the “pull” approach. Proponents of this approach deliberately do not use any kind of a stick (most CISOs really do not have one, anyway, after all) and wait for people to come to them to help solve security problems that they face. So, for example, application programmers within a business unit might request a meeting with the CISO to discuss what to do after vulnerabilities in a Web application that was developed in-house were exploited, resulting in a major data security breach. According to the pull approach, the programmers as well as the business unit manager will now be highly motivated to not only reach out to the CISO and the CISO’s organization, but also to do what is necessary to prevent this kind of incident from occurring again in the future. Prior to the incident, however, people within the same business unit may have viewed information security standards as a royal pain in the, well, you know what. This latter approach is being used increasingly by some of the more progressive CISOs.
Admittedly, the pull approach is fraught with a few rather basic but very serious limitations, the most serious of which is that the CISO who puts this model in practice soon becomes a “fringe player.” Whereas an information security practice’s policies and standards should in theory permeate all aspects of an organization’s operations, the CISO instead reverts into a mode in which the information security function does not take the initiative in influencing how things work until called up to do so. There is no way that the CISO will become a major player in the organization. Yet at the same, too many CISOs become bona fide players, but they end of playing too negative of a role–that of a business inhibitor. Perhaps if the CISO backed off a bit, some people would be more likely to approach the CISO to obtain advice and answers they need, and in the process bolster the stock of the CISO within the organization, causing still others to also approach the CISO with their problems.
I’m not saying that the pull model is correct, but rather that it is worth considering. We have pushed and pushed for years, and in so doing, we have alienated many people and gotten the well-deserved reputation of being the security prevention department. Perhaps indeed it is time to shift our thinking and try another approach.