|
|
|
|
Setting The Stage For Authentication
|
 |
|
May 28, 2001
By Brooke Paul
|
Types Of Authentication
Three types of authentication are available. Make your choice based on cost, ease of use and functionality. The functionality needed is determined by the sensitivity and criticality of the data or systems that are being protected and should be clearly spelled out in your authentication policy. Because there is always a cost associated with an authentication method, the method chosen should be based on the business value of the information resource being accessed. The costs associated with an authentication method include the technology, the impact to usability and productivity and management of the authentication system. The three types of authentication are:
- Simple Or Single Factor: "something you know" (an identifier and password). Single-factor authentication is probably the most common method and is supported by all network operating systems. It is relatively simple to implement and low in cost. Single-factor authentication is relatively weak, but you can improve its security through good security policies and procedures. These improvements can come in the form of single-use passwords or passwords with specific requirements that enhance their strength (more on passwords later).
- Strong Or Two Factor: "something you have" (a token, access card or certificate) and "something you know" (a PIN or password). The best-known implementation of this type of authentication is your ATM banking card and PIN. The ATM card is the something you have and the PIN is the something you know. Common systems in this category include both time-based tokens and challenge-response authentication.
Two-factor authentication provides significantly more security than single factor. However, like single-factor systems, two-factor authentication requires proper procedures to be implemented. In addition to managing creation/revocation of ID and passwords (or PINs), you have to manage the distribution of the tokens, access cards and/or certificates.
- Biometric: "something you are" (a fingerprint, iris scan, handprint or voiceprint). A biometric method can be combined with other authentication mechanisms if necessary. For example, you could use a handprint combined with a PIN for access to a system or facility. Biometric authentication often requires extra hardware and software wherever you expect someone to authenticate, and can be expensive and difficult to implement and manage. For these reasons, it is the least common form of authentication in use.
Developing The Policy
The development of your authentication policy requires input from business and IT representatives. As part of your information-security-management program you should have a list of participants from both business and IT who can provide input into any policy or procedure being developed. This is also a key to ensuring acceptance and compliance by your user community.
- List and categorize the resources that need to be accessed. Whether these resources are data or systems, you'll need to categorize them by their business sensitivity and criticality. This should provide you with a set of resources, each categorized according to its relative value to your business. The categorization should look very similar to any data-value classifications you have defined in other policies. You may also be able to use data from previous risk-assessment activities during this phase.
- Define the requirements for access to a given category of resources. You'll need to take into account both the value of the resource, as well as the method of access (such as LAN, Internet or dial-up). For common internal resources, such as e-mail or file and print systems, you might require that the single-factor authentication included with your operating system is sufficient, as long as the access is via the internal LAN. Access to the same resources by an administrative account, or via a less secure method such as the Internet, may lead you to require stronger authentication using a token, certificate or challenge-response system. Some resources may be so critical that you'll want to prohibit access from any external network. As always, the implementation of a control or requirement, such as authentication, should be based upon business risk.
- Set requirements for passwords and IDs. Your authentication policy should clearly state requirements for the following:
ID format: What is the proper format for a user ID? Having a universal ID format makes management of IDs and passwords much easier.
Complexity: Will you require non-alphabetic characters in passwords?
Length: What are the minimum and maximum password lengths?
Aging: How often must passwords be changed?
Reuse: How frequently may a password be reused?
Administrative Access: Will you have any special requirements for superuser passwords?
Defaults: Will you allow default vendor passwords and accounts, or will you require them to be changed or the accounts deleted?
Guest And Shared Accounts: Will you allow these types of accounts? If so, are there any special administration, password or authentication requirements?
Storage: What are the requirements for storage of passwords? For example, will they need to be encrypted or hashed when stored in a file, directory, or database?
Transmission: What are the requirements for transmission of passwords? Will you allow clear-text transmission of passwords during authentication or is encryption required?
Replication: What are the requirements for replication of password databases? How often must it occur and are there any special requirements for transmission?
- Create and implement processes for the management of authentication systems. The ongoing operation of your authentication systems is critical. If IDs, passwords, tokens and certificates are not managed well, their value will decrease rapidly over time, and security will be compromised. Your management process should include procedures for the timely creation/revocation of IDs, certificates and tokens. You also need to define a process for resetting passwords and tokens in the event they are forgotten or lost.
If possible, the creation and revocation of IDs should be based upon a central database or directory of legitimate users. For employee and contractor access, your HR or payroll department should be able to provide this information. In addition, security can be increased if you automate the process of ID creation and revocation based upon a central, authoritative database. This way, when someone joins or leaves the company, his or her ID will be created or removed automatically when his or her status is updated in the payroll or HR system.
- Communicate policies and procedures. The creation of policies and procedures has no value unless the community regulated by them is made aware. Compliance cannot be expected if people are not conscious of the requirements. Accordingly, you should include any policies in a plan for security training and awareness. This should be part of new employee orientation, as well as ongoing through internal company communications.
Brooke Paul is an information technology and security consultant. Send your comments on this article to him at bpaul@nwc.com.
|
 |
 |
|
|
|
 |
|