- A Within device
- B Physical at console
- C Local console switch
- D Local only switched connection
- E LAN
- F Local radio link
- G Remote over closed infrastructure
- H Remote over open infrastructure
- C Links
- B Encrypted links
- A Authenticated encrypted links
Updates and changes:
- 0 Never update or change
- 1 Update or change when there is a specific reason to do so
- 2 Update or change at convenient system changeover times
- 3 Update or change at regular intervals
- Z No authentication, anonymous:
This is common for remote access to Web pages and other similar things.
- Y No authentication, identified:
- F Password (something they know):
Passwords are the most commonly used authentication approach and will likely remain so for the indefinite future because of their extreme ease of use by people and universal compatibility.
- D Query/Response (something they can do):
This is a process in which a set of passwords, or the equivalent thereof, are associated with queries and the user demonstrates their ability to do something in order to authenticate themselves. In more advanced cases they may be things like the ability to compose music of a genre on the spot, to computer a formulaic response in time, or answers to questions with pre-defined answers - such as mother's maiden name. It also encompasses typing characteristics and other similar indicators.
- E Possession of a key (something they have - static):
Door keys or other similar mechanisms are commonly used for entry and access.
- D Possession of another device (something they have - changing):
This includes time variant mechanisms, electronic query response systems, one-time passwords, and so forth.
- D Physiological characteristics (something they are):
This includes retinal prints, facial recognition, infrared facial recognition, fingerprints, hand geometry measurements, DNA samples, and so forth. It also includes things like color blindness, trained responses, and other similar mechanisms.
- C Something they know or can do AND something they have:
This is a combination of two other factors.
- C Something they know or can do AND something they are:
This is a combination of two other factors.
- B Something they know or can do AND something they are AND something they have:
This includes personal authentication by someone who knows the individual engaging in some level of communications as well as a variety of combinations of devices and other similar things.
- A Within device:
This includes forensic examination of a device and other mechanisms based on presence inside a physical system or facility.
- B Physical at console:
This is presence at the directly connected device intended to control the mechanism locally.
- C Local console switch:
This includes switching devices that allow connection to multiple devices and switching between them, but does not include LAN-based console devices.
- D Local only switched connection:
This includes local telephone lines on the same PBX, a local only switched network, or other similar devices.
- E LAN:
A local area network that extends only to the physical facility and may be connected through a gateway to other networks.
- F Local radio link:
This includes infrared, bluetooth, and other similar limited radius devices.
- G Remote over closed infrastructure:
This includes a wide variety of technologies such as campus-wide networks, lease lines, remote telephonic connections, and so forth.
- H Remote over open infrastructure.:
This includes the Internet and all variations thereupon.
- C Links:
This is any connection without protective mechanisms.
- B Encrypted links:
This is a connection that is encrypted but not authenticated, such as an SSL link or an SSL session without a password. It also includes carrier encrypted tunnels and other similar mechanisms.
- A Authenticated encrypted links:
This includes encrypted links that are also authenticates so that the remote machine, facility, or device is authenticated and the traffic encrypted.
Changes are generally made to password-based and token-based authentication mechanisms and keys for encryption systems.
- 0 Never update or change "Never say never" may apply here. In some cases changing passwords may not reduce exposures, but these cases are rare. For example, for a physically secured system without external user access and where only authorized users have physical access to the location with the computer, password changes may be of little or no value.
- 1 Update or change when there is a specific reason to do so Changing passwords whenever there is a specific reason to believe that there is an exposure is clearly a sensible idea. But if carried to extremes may be too expensive for the level of the exposure. This approach calls for knowing when an event has occurred and what systems may be affected by it. Examples of events causing obvious exposures include the movement of an employee from one job to another, a known computer break-in, or a change in key personnel. In each case, access in excess of that necessary for the users' job functions are caused by their ability to access accounts using known passwords. Figuring out which systems may be affected is somewhat complicated by interdependencies of systems and commonalities between systems. For example, if a file server password is exposed, it may affect all of the systems that use that file server. If the same user has access to multiple systems, they likely use the same or similar passwords on many of those systems and all of those systems are therefore exposed. There are many other similar examples.
- 2 Update or change at convenient system changeover times There is nothing inherently wrong with this practice, and indeed all new systems should have all user passwords initially set to non-default values. But this does not address the other exposure issues and is thus of limited value.
- 3 Update or change at regular intervals This is recommended by most security standards and thus widely accepted. There are, however, some problems with changing passwords at regular intervals. Some of the major problems include:
The basic reason to change a password is that the password in question may be known to an unauthorized user. The period of time between when an unauthorized user knows a password and when the password is changed represents a period of exposure to attack. The goal of password changes is to reduce this exposure. It is also important to consider that a fairly short exposure period can cause high consequences. In many cases, within seconds to minutes of an initial break-in, "back doors" are put in place to allow reentry to the system even if the passwords are changed. For this reason, simply changing passwords may not be an effective action when an exposure occurs.
- 0 Never update or change "Never say never" may also apply here. While normal operations of security tokens do not require changes, any such system should, at the architectural level, be updateable and replaceable or it risks being brittle.
- 1 Update or change when there is a specific reason to do so Changing tokens when there is a breach of a token provider, token server, or other similar risk aggregating mechanism is likely to be required at some point in the lifecycle of an enterprise. As such, this should be part of planning.
- 2 Update or change at convenient system changeover times There is nothing inherently wrong with this practice, but for most token systems at the enterprise level, it is quite expensive and not system-specific.
- 3 Update or change at regular intervals Most token systems have defined lifecycles for tokens (on the order of a few years or less), so tokens should be replaced periodically as part of this mechanism.
For encryption keys
- 0 Never update or change "Never say never" definitely applies here.
- 1 Update or change when there is a specific reason to do so Changing encryption keys under duress is a challenge and the useful enterprise encryption system should be designed so that multiple keys are always available and change-over from one set of keys to another should be able to be done quickly and efficiently.
- 2 Update or change at convenient system changeover times There is nothing inherently wrong with this practice, but encryption keys are normally changes quite often in any case. Public and private keys are normally generated for each system at inception and should reasonably be updated during major changes.
- 3 Update or change at regular intervals This is recommended for all encryption keys, largely owing to the ready availability of cyphertext and sometimes plaintext and cypertext pairs. In addition, session keys should be generated for each session.
For encryption and token systems
- 0 Never update or change "Never say never" may also apply here, but systems themselves tend to be hard and expensive to replace. As a result, great care should be taken in choosing them.
- 1 Update or change when there is a specific reason to do so Changing encryption or token systems are sometimes necessary, and when it is, the costs are high. These can be substantially reduced by choosing systems that are amenable to multiple methods or modes of operation. For example, an encryption system should allow for the use of a variety of different encryption algorithms, the change and addition of algorithms, and arbitrarily long and adaptable key sizes should be a built-in feature of the overall system. Otherwise, it is a problem waiting to happen.
- 2 Update or change at convenient system changeover times Generally, if a changeover must be made, this is the time to do it, but at the enterprise level, this is problematic because cryptographic infrastructure tends to span many systems. Major architectural changes are really the only time to consider this strategy.
- 3 Update or change at regular intervals This is not recommended for encryption or token systems. The cost is almost certainly very high and unnecessary.