Of Rogue Employees and Internal Control: Part II

Last Monday I talked about how shortcomings in the San Francisco municipal government’s system of internal control ultimately allowed one employee to “own” the citywide network, i.e. prevent anyone else from using it. The City’s officials are probably at this moment considering the event as an isolated occurrence of mischief by a bad employee… something that happened by chance and will never again occur. That logic misses the point.

Any employee could be a Terry Childs. Some of the most dangerous are the most trusted—network engineers, database administrators, software architects, configuration managers. And increased regulation coupled with high-deterrence sentencing guidelines has not stemmed the tide of fraud, waste, and abuse. There are two fundamental reasons why stepped-up compliance and enforcement efforts have met marginal success.

First, compliance is not really an effective control unless it is part of an enterprise risk management program. Executives really, really want to believe that by saying, “My organization is compliant with regulation”, their organizations will become compliant with regulation. But punching punchlists and signing signature lines does not provide assurances. The same criminals, agitators, and malcontents who are able to rationalize their behaviors and disassociate from potentially negative personal aftereffects were there before—and remain intact after—the punching and the signing. The media regularly reminds us of this.

Second, managers fall into the trap of labeling the offending employee as the problem, rather than the weak system of control that facilitated the behavior. This has a lot to do with how risk is often managed. A common methodology goes like this:

1. If something bad happens, label the event as a risk.


2. Perform mitigating activities of heroic proportion to correct it.


3. Blame the perpetrators.


4. Declare victory when the organization returns to equilibrium.


5. Deflect unwanted attention by neglecting to calculate the losses and mitigation costs of the exposure.

But an effective system of internal control doesn’t wait to discover a risk after the exposure, doesn’t point to the individual as the root cause of the breakdown, doesn’t ignore residual risk, and absolutely doesn’t rely on fate. It is disciplined and integrated, meaning that it has well-defined, key elements:

A truly enterprise risk management program. By enterprise, I mean a top-down program that considers every risk to the organization, as well as the appropriate mitigations.

1. A system of internal control that follows from the risks identified by the risk management program. There are no controls being executed because “we’ve always done it this way”, or “somebody said that it needed to be done”, or “I’m not sure why we do this.”


2. Just enough layers of control and enough control types to give the right level of protection. The control framework should be based on the total cost impact of a risk exposure. If it costs more to control a risk than the risk’s impact would cost, the control generally should not be implemented.


3. Tempered reliance on administrative controls. Administrative controls are indispensible for direction and accountability, but they are prone to becoming marginalized, for example when variations from policy become the norm, or when approval checkpoints degenerate into rubber-stamping.


4. Effective separation of incompatible duties. In the Childs case, a single user had the ability to perform several functions that, taken together, would ultimately be detrimental to the organization’s ability to function.


5. Emphasis on technical controls. Controls coded into software—role based security, audit logging, edits and validations, etc.—are less prone to error than controls that rely on human effort. People make mistakes, but computers can perform the same monotonous task time and time again without fail.

Imagine that the City of San Francisco had exercised a risk management program to foresee the possibility of a rogue IT employee hijacking the City’s information systems. Management would have deployed a control framework to address the risk. Controls would be applied efficiently, at the lowest cost possible and with the right level of protection relative to the cost and likelihood of an exposure. Requests for authority to engage in potentially damaging activities would have been scrutinized. In fact, many potentially damaging activities would not even be possible by a sole person. There may even have been a system of automatic triggers to disallow certain behaviors by computer users, and quite possibly a system of alerts that would tell management when a computer administrator escalated their privileges. All of this would be done at a long run cost savings because controlled processes are more efficient than uncontrolled processes.

Meanwhile, San Francisco officials continue to wage their campaign of making an example of Mr. Childs in the courts. The City must look to itself as the example.

►

Of Rogue Employees and Internal Control

Monday Mashup is back after taking a respite for the Labor Day holiday. Today I offer the tale of Terry Childs. His epic story of meteoric rise and catastrophic plummet (well, not really, but it draws readers) speaks volumes about the importance of IT general controls.

Mr. Childs was—until his recent relocation to the San Francisco County jail--a network engineer for the City of San Francisco. He apparently took his job a bit too seriously. Just as management was about to terminate Mr. Childs, he commandeered the city's Cisco network, effectively barring anyone and everyone from using city computing systems.

As the case sees daylight, an important lesson is being taught. We now know that management tolerated Mr. Childs' unacceptable behavior far longer than reasonably prudent because Mr. Childs was highly skilled and very effective in his role. His superiors knew that he had too much authority, that there was not a contingency resource following behind him, and that administrative access to the network was not being monitored. In fact, his department had a "give Terry whatever he needs to keep us afloat" mentality. So it's not surprising that he had all the right signatures on all the right approval documents.

Three important kinds of controls appear to have been absent in this case. Administrative controls were not being effectively executed. Roles having too much authority vested in them were not segregated. And technical controls like audit logging were not in place to detect problems early and prevent their escalation. The next Monday Mashup will discuss some of the problems that administrative controls have, and the reasons why organizations need effective segregation and technical controls.

►