The year is 1983. David Lightman, a high school junior, is failing biology. Besides being somewhat of a computer prodigy, David is also a class clown, a characteristic that one day lands him in the principal’s office.
David knows that the grades are already on the school computer and that the principal and his secretary sometimes work on the computer from home, dialing in on the 300 baud modem line. David also knows where the secretary writes down the password. While he waits for the principal to see him, he finds the password “Pencil” and that night, he changes his grade in Biology from an F to a C. He avoids summer school, but he almost starts a nuclear war.
Did you recognize this as part of the plot from the 1983 movie WarGames, starring Mathew Broderick? Whether you did or not, there is an important lesson in computer security to be learned.
As you may have already figured out, this blog entry is about security, which ought to be one of the first topics explored as you consider a loan servicing system.
So, let’s flash forward.
A client calls with a security problem. The client is a college which uses the Nortridge Loan System to service in-house student loans. They also have a work study program in which they allow students to work in various jobs in campus administration. The problem in this case was that a student was allowed to work with the NLS loan management system, servicing the loans of classmates.
If loans suddenly disappeared from the books, principal balances were written off, or if payments were entered where no payments existed, these actions would have been quickly caught by accounting. This student was more subtle. She simply modified the interest rates of all of her friends’ loans to zero. Since these students all diligently paid their (interest-free) loans on time, it took the college nearly two years to realize that they had given a batch of loans interest-free that they had not intended to be interest-free. They figured out who did it, but they needed to prove it.
We looked at several of the loans upon which these modifications had been made. The modifications were all stamped with a date and time stamp (so we knew exactly when the modifications had been entered). The modifications were also stamped with the user ID of the NLS user who had made the modifications. Unfortunately, they did not see the name of the user whom they KNEW to be the culprit. One user had logged in with another user’s password. And now we are back to David Lightman.
David teaches us that no matter how much security is built into the system, no matter how much control is provided over what users can or cannot do, and no matter what is recorded to link everything back to the person who takes specific actions within a system, a major security breakdown can occur when one user has another user’s password.
Consider this cautionary tale as you plan and manage security in your environment. Have a plan to change passwords regularly, never “share” logins or passwords, and avoid writing down any login info where it can be found by others. It’s an extremely simple, basic business practice, but one that is too often disregarded.
