Show this article to your CFO the next time he or she asks for a budget.

Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .

It’s time . . . no wait, it’s WAY PAST TIME . . . that community banks spend the money necessary to apply true segregation of duties to IT Governance.

When Ronald Reagan said “Trust, but Verify,” he wasn’t talking about the three teams that monitor technology risk in a bank.  Had he been talking about the Risk Monitoring Team, he would have realized that without proper separation of duties . . . . and permissions . . . . we have a terrible situation just waiting to show its face, in an internal breach.  If Ronald Reagan was an ISO, he would have said, “Trust, but Segregate.”

We place a LOT of trust in our technology team.  There is a lot they could do without our knowledge.  So, we trust them.  But we should also protect them.  Ask your lawyer:  those with authorization to make changes to a system may be accused of maliciousness should an insider breach take place.

You see, if the person in charge of watching the changers is also the changer, that person has no way of proving his or her integrity in an insider breach.  And given that the statistics still show insider breaches as accounting for more than half of all breaches–with some studies putting the number as high as 70%–there is a likelihood you may have to deal with a situation like this in the future.

Processes that should be segregated are many, but consider these seven:

1. Any Administrator Activities . . .
2. . . . like Adding New Users or Escalation of Permissions.
3.  Vulnerability Management (especially scanning to confirm proper patch Management)
4. Administrator Access to more than one system.
5. Opening a hole to the internet.
6. Installing a remote access process.
7. Acquiring and installing new software applications, utilities, etc.

Of course, the above “Seven List” is meant for smaller community-based banks.  This list is “squared” if you have FDICIA or SOX compliance objectives.  Just take the Federal Deposit Insurance Corporation Improvement Act of 1991 (FDICIA).  As a part of the financial statement audit, once a bank crosses 1 billion in assets, Management must issue an attestation on the effectiveness of their bank’s Internal Controls over Financial Reporting (ICFR).  And . . . . ask your CFO . . . one of the primary internal controls tested is: Separation of Duties.

Sarbanes Oxley (SOX, for publicly held companies) takes ICFR to an extreme.

So, a decision needs to be made that is probably above the typical ISO or IT Manager’s “pay grade” in a community bank: do we hire somebody or find an existing employee to fill a stand-alone information security position? Do we outsource to a vISO? Do we create a committee and put the ISO hat on somebody outside of IT? Or do we set up a myriad of complex controls, using our SIEM, that may mitigate risk but also that litigators (and media) may not understand?  Because it would be a third party outside of IT watching the SIEM, our MSSP can help us at least temporarily.  But again, the lawyers and the media are not going to understand why this truly separates duties (because it doesn’t.)

Now, what may be causing confusion, when it comes to Management’s tolerance of segregation in IT versus segregation in accounting, is that we go to Management saying something like: “we don’t have the time to get everything done.” That’s not a segregation issue; it’s a workload issue.  And we can address workload issues by outsourcing . . . bringing in vendors when the going gets tough.

But who will watch the vendors?  That’s the segregation issue.  It’s about the watcher not being the changer.  It’s that simple.

Take the well-publicized case of “Grouchy Grupe,” the rogue IT administrator who sabotaged his company’s network.  Forensics persons were able to track down and prove what he did, landing him in jail for more than a year.  Had, however, the forensics evidence not been gathered by a segregated security person with no ability to change the network, the forensics evidence would not be forensics evidence.  Grupe’s lawyers could have made a case to the jury that somebody else COULD have committed the crime.

Or take Ricky Joe Mitchell, who is paying $500,000 to his former employer.  He successfully sabotaged the company’s systems, but fortunately for the company, a person without the ability to change the network was monitoring the network.  Had Mitchell’s lawyers been able to point to a lack of segregation, and ask the jury to ponder whether somebody ELSE did the evil deed, Ricky Joe would be $500,000 richer.

When your CFO asks for a budget, ask your CFO if you can not only purchase the assets, but also key those purchases into the accounting system.  They’ll say no, because Management has already invested the resources necessary to prevent an accounts receivable clerk from handling deposits.

Your CFO totally buys into the extra staff necessary to keep Separation of Duties in his or her accounting department.  For example, the separation of duties concept prohibits the assignment of responsibility to one person for the acquisition of assets, their custody, and the related record keeping. Another example: one person can place an order to buy an asset, but a different person must record the transaction in the accounting records.  This is not done in accounting just to prevent malicious activity or fraud.  It is a best practice that prevents mistakes.

Your CFO knows that, without Separation of Duties, it is more likely that errors, duplication or omissions can occur. Without Separation of Duties, more than one person may make the same purchases, resulting in duplication, and waste.  Or, products may be received by mistake from a supplier that was not even ordered.

And what your CFO also knows:  the longer a business holds off on proper staffing in order to achieve a Separation of Duties in accounting, the more difficult it will be to change processes and procedures, not to mention getting buy-in from the accounting staff.

And that does not cover fraud.  The total loss that malicious activity could cause in undiscovered deposit fraud . . . undiscovered due to no Separation of Duties . . .  is MINUSCULE compared to the damages an insider breach could cause to reputation and treasure.

The guidance that your auditors may eventually get around to citing is located here.
And more specific to users, here. But the guidance that we’re referring to specifically here is best worded in the “Personnel Controls” section of the IT Operations Booklet, located here.

The language your CFO needs to see?

“Organizational structure should include dual controls and separation and rotation of duties where appropriate and feasible. Internal control procedures, dual control and rotation of duties facilitate cross-training, improve depth of personnel skill, and succession. In addition to serving as a quality control mechanism, separation of duties deters employee dishonesty, fraud, or intentional harm to equipment, systems, and data. Management should organize functional duties so no one person performs a process from beginning to end or checks the accuracy of his or her own work. . . Adequate separation of duties is a challenge in smaller institutions. In such circumstances, rotation of duties can be an effective mitigating control. Management should closely review and monitor individual performance and activities in these situations to provide effective supervision, facilitate training, and serve as a validation to control effectiveness.”

So, why can’t we talk Management into investing in Separation of Duties?

Is it because they don’t understand the risks?  Do they think accounting risks outweigh cybersecurity risks?

Or do they not realize the fox is watching the hen house?

Now, above we alluded to how your MSSP can help mitigate segregation issues.  The SIEM can put a watch on unsegregated administrators.  But we also want you to see the part of the above allusion that says, “your lawyers and the media is not going to understand . . . . or believe . . . what you’re doing here.”

So while we don’t recommend it as a “final solution,” as a temporary control, if you are going to have your network administrator do things like test vulnerability Management systems or watch for escalation of permissions, you should at least have a SIEM that a third-party watches, or a SIEM that the administrator cannot make changes to.

Else, what is to stop the watcher from shutting off the SIEM, creating an administrator account, executing a breach, deleting the account, and then turning the SIEM back on?

What is to stop that?

(I know . . . trust.)

Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”