4 Things To Consider When Giving Access to Data

The security world seems to be an escalating race between stronger and stronger encryption methods versus faster and more sophisticated attack methods. But the plain fact is, the easiest way to lose data is for it to walk out the door (physically or electronically) in the pocket of someone who has access to the data in the first place. John Walker and Edward Snowden are just the visible tip of the iceberg…which leads to the critical question – how do you balance the need for suspicion about the very people you’ve handed the keys to the kingdom? Here are a few things to consider:

#1. Separate the function from the person. Who needs access to the customer master file: the programmers that support the customer application or the programs they write? The programmers should only need access to a sanitized, anonymized extract of the actual customer data in order to develop and test their programs. Access to the actual file should be limited to programs coming from a secured executable library that can only be updated through a change control process where all code added to the library is reviewed. Likewise – does the security administrator need access to the customer master file? Of course not, but the problem is, he can give himself access to it if he wants to.

#2. Use temporary exceptions to the above. Assume that the programmers do need to access the actual master file – perhaps to extract current data to the test files. One answer is to have them use a temporary Userid that does have access. The temporary Userid should have all actions logged and should always be revoked at the close of business.

#3. Always have a second set of eyes. Any request to escalate access privileges should always go through a change control process and require approval from one or more levels of management.

#4. Distribute the security administration function. Last but not least, the actual implementation – the part of the process where someone with top level authority can alter access privileges. What is to keep him from granting access to himself for anything he wants? Never have just a single person in that function. Use a security system that provides a multiple authorization or “voting” procedure so that any changes to either the system administrator access, or to the overall implementation of controls requires at least two different people to authorize. You should have at least one more potential voter than the number of votes required to authorize a change to allow for illness, absence or disaster.

As an American president once said – “Trust, but verify.”