Risk: Look Both Ways

On my walk to work, I cross a lot of 1-way streets. I always look both ways. Sometimes, when a friend or colleague is walking with me, I get teased me about this. I always reply with this question: Have you ever driven down a 1-way street the wrong way? For some reason, I never get a reply and another subject surfaces.

When I crossed one of those streets the other day, I realized that some people look at audit/security/risk the same way. They only look one way because of the people or rules or controls or norms that govern the activity. They fail to think outside of the cubicle and look the other way–the path seldom traveled.

Recently, I was reviewing a system’s user list and how super user access is monitored. A daily script identifies all the super user IDs and compares them against an approved list of super user IDs and emails a report of any exceptions.

The control I was testing required new and terminated super user IDs to be promptly added or deleted from the approved super user list. The test steps required comparing new and terminated super users to this list to determine if the list is being kept up-to-date. That tested out just fine.

Then I looked the other way and reversed the test, which had not been done in the past: I checked whether every ID on the approved super user list actually had an ID in the system that had super user access. It was quick and easy as all I had to do was tweak the vlookup formula that I used for the other test, so I was able to add value with minimal effort.

The results were not surprising. I found 5 IDs on the list that did not have corresponding super user accounts in the system, which meant that someone could add a superuser account that matched one of those IDs without the proper approvals and the script would never catch it. I was told by the DBA that this problem had occurred before, but she had no luck in getting the issue fixed (she needed cooperation from others who add and delete logins, which DBAs were not allowed to do).

Then came the bonus. I discovered that the approved list was also used in another security script which also has a control associated with it, but no exceptions were ever noted when that control was tested either. Audit didn’t even know a script was involved with this control. Then I realized the super user list was never formally reviewed. Although IT knew about the script and trusted it, they didn’t realize that the script relied on a list that was never periodically reviewed , and neither did Audit (so how can this list be an “approved list”? Good question).

Previously, Audit “assured” management that the 2 controls were working well, when in fact they were sick and feverish. Until one alert auditor took 5 minutes to look the wrong way.

Advertisement