"Internet security is a colossal problem which threatens not only businesses but also critical national infrastructures which are dependent on e-government."
—Paddy Ashdown, member of Parliament, United Kingdom
Your manager has told you that, in light of recent events in the United States, it is your job to ensure that your system's security is up to scratch. Where do you start? Get in a security consultant? Do it yourself? Get a member of your staff to do it? Before you can decide, it will be useful to know what is involved in carrying out a security audit of your systems so that you can decide which option is best to take—for example, whether you have the skills required in house (and, if not, whether the security consultant you hire does!). This article looks at the business aspects of a security audit. The second article in this series looks at the technical aspects.
Requirements
The first thing a security audit needs to take into account is what your system requirements are:
Are the systems required to be available 24 x 7? Many e-business systems are required to have 99.99%–plus availability because they are used by users all over the world.
What are the access requirements? Is access to systems/data restricted within the company to senior management? Are customers/business partners/competitors allowed access to any part of the system (especially for e-business systems)?
How many users use the system on average and at peak times?
How much data is stored?
Are there legal requirements to store data for a certain period of time?
Are there legal requirements to protect data from intruders?
How sensitive is the data stored? How badly would it affect business if competitors or other intruders had access to that data or destroyed the data?
How sensitive is the system itself? How badly would it affect business for an unauthorized user to gain access to different parts of the system?
Physical Security
In examining physical security, the auditor should be concerned with where the system is physically located and which physical locations it can be accessed from.
For most systems, it is sensible to store the data server and Web server hardware in an air-conditioned room that has no windows and that is not easily accessed (preferably with access controlled by some kind of security card reader or keycode entry system). For more critical systems, it may also be important to vet the holders of such security cards or change the keycode used to enter the server room regularly.
Depending upon the level of security required, it may be necessary to check that security guards are employed to guard against intruders (and that they—and the company they work for—are trustworthy and reliable and have been subjected to a police check).
For systems with high availability requirements and high levels of business criticality, it is crucial to ensure that the whole system is duplicated off site in case of disaster, so that the whole system can be switched to the other site in case of an unfortunate incident such as a fire, an earthquake (a much bigger worry for me when I worked in Wellington, New Zealand, than it is now I am in London!), a bomb, or even a plane crashing into the building (sad though it is that we do have to consider such eventualities).
It is important to ensure that this "failover site" is just as secure as the main site (not easy when such a site is managed by a third party that manages a great number of "failover sites" for a number of companies!). It is also important to check that this duplicate system really could cope in case of disaster. For example, a client of mine spent a lot of money duplicating his Web site, Web server software and hardware, and database server (using replication) at his failover site. However, the Web server at the failover site used the same Internet service provider as the main Web server. When one was not available due to a problem with his ISP, neither was the other!
Check that the whole architecture is duplicated—including the web server hardware and software, the database server software (and hardware, if separate from the Web server hardware), the data (via replication or managed backups and restores at regular intervals), the network, the routers, the hubs, any firewalls, and so on.
Procedures, Roles, and Responsibilities
This is an area that is all too often totally overlooked in security audits. Auditors often focus on the physical and technical aspects of security and forget to ensure that proper procedures are in place, have been written down, and are being followed. Yet it can be the key piece in the jigsaw puzzle that, if missing, creates the biggest threat to security.
It is important to ensure that policies are in place to ensure that auditing and tracing is used effectively. Some systems will be required to log more than others (for legal or operational reasons), but the minimum auditing that should be carried out should log which login attempts have failed and which IP address they come from.
Are procedures in place to ensure that audit logs of system activity are regularly reviewed for signs of malicious intent (such as repeated failed logins)? Who carries out these procedures, and how often? Are they effective?
Is there a policy that ensures that passwords are not easily guessed? For example, is it mandatory that passwords be eight characters long and consist of a mixture of numbers and letters? Does the system force users to change passwords regularly?
The most effective virus-scanning software in the world is not going to be able to cope with a virus that is so new that no "antidote" has yet been written. Are procedures in place for what should be done if a virus outbreak is discovered? Should all mail servers be taken down in such an eventuality? Perhaps all Web servers, too? Many of the most lethal recent viruses use VBScript to write themselves onto Web pages as well as into emails, so this may be a consideration.
In such an eventuality, who should be informed of the outbreak? Who is responsible for making decisions about how serious the outbreak is?
It is also important for the auditor to check that these procedures are not simply written down in a document and forgotten about, but that they are well known to those who need to follow them and that they are carried out effectively when required.
Amazon.com went to great lengths to create procedures aimed at protecting credit card information of its customers because the site recognized how disastrous it would be to the Amazon business if such information was stolen. Also, the company wanted to put its customers' minds at rest about handing over credit card information across the Web. Originally, the procedures developed ensured that the credit card information was held on the Web server for the minimum amount of time possible and was immediately transferred to disk and then copied onto a standalone internal PC with a direct modem link to the credit card processing company (but no link to the Internet). Only the last four digits of the credit card number remained stored on the Web server, useless to any hacker—or even to any Amazon employee with access to the Web server. This simple system gives Amazon a competitive advantage because customers feel safe trading with Amazon. Now their systems are more sophisticated but are just as secure.
Amazon also employs policies to ensure that it employs only the best people and that everyone is very clear about their responsibilities. Employing good people who have clearly defined roles with clear divisions of responsibility can play a major part in the effectiveness of security within an organization.
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.