Should the CEO be exempt from your company's security polices?
The culture of a company plays a large role in how to approach implementing business management systems such as Enterprise Risk Management, an Information Security Program, or a Disaster Recovery plan. One aspect that might seem insignificant is the extent to which the boss (CEO or President) exempts himself from complying with company policies created from these systems. However, if this happens routinely, it can serve as an impediment to achieving your company's security and continuity goals.
Many bosses and high-level executives do comply with all policies, to set the example. But others use their authority to override security measures they find inconvenient, sometimes even directing the IT manager to remove technical controls. This may result in the boss using simple, easily-guessable passwords, running with administrator privileges on his laptop, browsing the web with security filtering disabled, skipping check-out procedures for sensitive devices, not following physical security procedures while travelling, or skipping training.
Information Security is serious business. Even though this has been said for decades, it remains true: threats are growing more sophisticated. Something like software that will encrypt all your files in minutes, then provide a message demanding a payment of ransom for the decryption key, was unheard of just a few years ago.
In addition to the technical capabilities, criminals have been honing their ability to gather information about a business and exploit the human element. This is nothing new, but the level of sophistication has been growing. We now see amazingly authentic looking e-mails supposedly sent by the CEO or CFO to the accounts payable team asking to wire a large payment to a fictitious new supplier overseas.
Of course, we can deploy technical counters to the ability to spoof e-mails, and conduct awareness training for all users. However, when the boss himself flouts security rules and best practices, he makes himself more likely to fall for an attempt to expose his password, when his should be among the hardest to get. If this happens, instead of sending a spoof e-mail, the criminals will send an e-mail directly from the boss's actual e-mail account, greatly increasing the chance of successfully influencing an employee to send money or reveal the company's online banking password.
So the problem isn't just the increased risk of a malware infection or information disclosure from the boss's computer. It should go without saying that the information the boss has on his computer would be the among most damaging to be released. But his failing to heed the knowledge and practices supplied by security training and specified by policy can lead to others being ensnared, causing significant losses for the company.
Another technological control measure we can take is to require multi-level authentication; that is, something more than just a password, so that a criminal in a foreign country can't log in to the system just by getting the boss to reveal his password. But this is a perfect example of something that introduces some inconvenience, and which the boss may reject.
Apart from risks of breach using the boss as the vector, consider the value of setting an example for the users. Experience has shown us that when a worker from a support department (such as facilities management, human resources, or IT) tries to enforce policies or procedures, he may get resistance from the workers who generate the revenue. When a policy was developed by direction from top-level management, a worker is wrong to resist its implementation, even if the worker might far outrank the support guy in the company hierarchy. But, many IT system administrators don't have the organizational acumen to realize this, they may develop apathy to avoid the conflict, or they may simply not have the social skills to address the issue. If the boss has demonstrated that these policies don't matter, though, then an IT system administrator trying to enforce a security policy for other users will have far less leverage to achieve his goal of implementing the policy, which is actually the company's goal.
There are no easy solutions to this, but here are some ideas.
In general, those closest to the boss, professionally in the hierarchy and/or personally, should employ influential skills to make the case. To best implement this, they should raise the issue, and remind the boss why his cooperation is essential, when you first start planning and developing your Information Security Program, and throughout every step of implementation.
In addition, all other security professionals must be aware of this problem, because it may not be just the boss who ignores security policies. Other company executives may also consider their convenience to be more important than some company security polices. And you need to make sure your security professionals, as some are prone to do, don't think that because they are highly trained in general, they can use their own discretion to violate security policies.
After implementation of the Information Security Program, when you become aware of a policy the boss is not following, or when the boss requests a technical reconfiguration in violation of policy, a good way to address it is to have your Information Security professional do the following:
- Find out what function or capability the boss wants that is impacted by the security policy in question.
- Identify potential solutions that can address the problem. This can possibly be a simple workaround, or it might require some changes to the policy to balance the competing interests, or technical reconfiguration.
- Analyze these solutions in relation to the stated risk threshold, information from your risk analysis documentation, and configuration options.
- Present your results to the boss, explaining the risks of each feasible solution in light of the boss's requirement. Of course, use your social and professional skills to present this in a respectful, and non-condescending, manner.
- When the boss makes his decision, save this documentation. If the decision is suboptimal (as in, he decides to just continue doing it his way), then continue to analyze potential mitigating solutions to the new risks that were introduced.
Avoid the lazy solution of simply writing an exception to the policy for the boss. In some cases it's completely appropriate and may be the only solution. But, if you have too many of these exceptions, it will be seen by the boss and others as the norm, and he is more likely to take liberties where it is not allowed in the policy, undoing all the efforts you have made to address this problem.
As with security in any discipline, environment, or situations, vigilance is the key, and complacency is your enemy.