Identification, Authentication, and Access
The effective auditor should look at not only all physical routes into the system (hardware), but also the logical routes into the system—that is, from which networks can the system be accessed and how? Is there a VPN allowing access into the local area network from outside the physical building? Is access allowed from Web sites to any part of the system? Can staff members dial in directly to internal systems using their home phones?
For each logical access point, the auditor should check that there is an effective means of identifying and authenticating the user groups allowed access from that point.
Depending upon the level of security required of the system, this may involve simply using logins and passwords, issuing passwords with a very limited lifespan, issuing encrypted keys to users over Secure Socket Layer (SSL) stored on their PCs, or using SET with encrypted keys residing on a smart card read in by a smart card reader. SSL and SET have the added advantage of encrypting the whole message so that the contents of messages cannot easily be read by "spies."
Where it is not convenient to change passwords often (for example, in e-business applications or personal banking applications) but the data is very sensitive, passwords may be combined with other means of effectively authenticating the user—for example, an SSL/SET key held on the user's PC or IP address authentication.
Retail banks often provide customers of their personal banking services with a membership number (a fairly long number usually) and a pin number (issued in the same way as the pin number of a credit card, subject to tight security and sent via mail to the customer). In addition, they still require the customer to type in a surname or other identifying information to access the system. Customers are often not allowed to change their passwords online, but instead they have to phone a support number to have the password changed.
Other banks sometimes issue SET smart cards to customers along with smart readers.
These extra means of authentication can be employed to ensure "nonrepudiation," to make it difficult for either party in a transaction to pretend that it did not happen or to pretend that it was not one of the parties involved, that an imposter was using its login.
Even where such lavish security is not necessary, login/password control is something that should be carefully planned and monitored, and the auditor should look for evidence of this.
It is important to look at how well user sessions/accounts/logins are managed. Are user sessions logged out after inactivity of a set period of time? This can help ensure that someone cannot pretend to be the authorized user by using that person's PC while he is away from his desk.
Are old user accounts deleted on a regular basis? Is there tight control over who can create new user accounts and which data or functions are made accessible to them? It is all too easy to accidentally give users access to more than you plan to.
Are passwords changed regularly? Does the system force the user to choose a password that has not been used? Do passwords have to be difficult to guess? Left to their own devices, users will select easily guessed passwords (their surnames, the names of their spouse or pet) and will give their passwords to other users either intentionally or unintentionally. Hackers can exploit such vulnerabilities with terrifying ease.
One IT consultancy that I worked for was confident that all of its employees were so well informed about using passwords—ensuring they were not easily guessed, that passwords were not left lying around on post-its, that they were changed regularly, and so on—that it employed a hacker and asked him to try to break into the most sensitive systems. It took the hacker 24 hours to break 90% of the passwords used on the most sensitive systems within this IT-literate company! Needless to say, the consultancy kept that very quiet!
That same hacker let me into a little secret: He told me that the biggest mistake companies make is allowing users to change operating system passwords over the Web. NT-based systems are renowned for this, especially when companies want to take advantage of using the pass-through technology that enables the user to log in once and gain access to applications and data using the single login. Although allowing users to change their database or application passwords is usually not disastrous (because even if a hacker guesses the password correctly, all he can do is access or destroy a limited amount of data or an application), allowing access to change the operating system password can be disastrous. This is because hackers can manipulate holes in the operating system and Web server to gain complete control of the system—and, in some cases, of other systems accessible from the system.
When carrying out a security audit, it is important to note that security is a "hygiene" factor: When it exists and is effective, it is hardly noticeable. However, when it is not there, it can mean the end of a business overnight. Also, it is a never-ending task: Policies, procedures, and technologies should be constantly updated and reviewed in the light of new security threats—recent events in the United States have made this all too evident.
Here I have looked at the business aspects that should be examined in a security audit of an IT system. In the next article, I will examine the more technical issues involved—those pertaining to browser settings, Web server installation, firewalls, and so on.