Fri Apr 8 06:51:39 PDT 2016

Control Architecture: Authentication: How are identities authenticated to support authorized access?


Options:

Authenticator:
- A Multiple simultaneous or synchronized independent acts (e.g., multi-party control)
- B All three of something they know or can do, are, and have
- C Two of of something they know or can do, are, and have
- D Physiological characteristics (something they are)
- D Possession of a dynamic authentication device (something they have - changing)
- D Query/Response (something they can do)
- E Possession of a key (something they have - static)
- F Password (something they know)
- Y No authentication, identified
- Z No authentication, anonymous

Location:
- A Within device
- B Physical at console
- C Local console switch
- D Local only switched connection
- E LAN
- F Authorized/controlled (or time sequence of) location(s)
- G Local radio link
- H Remote over closed infrastructure
- I Remote over open infrastructure

Time:
- B During pre-specified dates and times
- B At dynamically constrained dates and times
- C Any time

Connection:
- A Direct physical connection
- B Authenticated encrypted links
- C Encrypted links
- D 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
- 4 Change from defaults during installation prior to network connection


Decision:

The most suitable approach is sequences of different factors at different points in a process based on location, connection, time, and consequence. A rating is comprised of the sequence of:

{Authenticator [change] x Location x Time x Connection [change]}

Minumum ratings per situation are as follows:
Consequence Minimum Ratings
High B[1]--- AND -H-B[123] AND if feasible --B- AND if feasible -D--
Medium [ C[1]--C[1] OR F[1]D-C[1] OR F[1]FCB[12] ] AND if feasible --B- AND if feasible -D--
Low ZICD
Always [4]
Authentication process minimums

From any minimum rating, any element can be higher rated and still satisfy the need, but no element can be lower unless it dominates a different rating for the same risk level. The [change] field provides change strategy for the relevant element in the particular situation (i.e., authenticator change after the first element and connection change after the 3rd element)


Basis:

As background, authentication may be a sequenced series of events. For example, entry into a building may require an authentication process which is augmented by steps to enter an internal area, a contained facility, a designated portion of that facility, and finally to undertake a specific act therein. Thus multiple uses of different authentication mechanisms involving time, place, sequence of events, and multiple factors at each authentication step prior to actual access.

Authenticators:

- A Multiple simultaneous or synchronized independent acts (e.g., multi-party control):
As an example, teo partis at physically differne locations may authenticate simultaneously in order to enable a critical function such as a weapons launch. These may have to be sychronized over time so that they may act within a minute of a previous action authorizing the launch.

- B All three of something they know or can do, are, and 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.

- C Two of three of something they know or can do, are, and have:

- 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.

- 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.

- E Possession of a key (something they have - static):
Door keys or other similar mechanisms are commonly used for entry and access.

- 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.

- Y No authentication, identified:
This is used for tracking purposes only - such as the use of cookies for tracking behavioral patterns without necessarily tracking identity.

- Z No authentication, anonymous:
This is common for remote access to Web pages and other similar things.

Location:

- 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 Authorized/controlled (or time sequence of) location(s):
This includes absolute and relative location within a framework (e.g., room in building, room in ship, address, city, state, country, etc.) possibly under specific controls (e.g., a cleared facility) and where you are compared to where you were (travel time-based restrictions, only allowed access from one authorized place at a time, etc.).

- G Local radio link:
This includes infrared, bluetooth, and other similar limited radius devices.

- H Remote over closed infrastructure:
This includes a wide variety of technologies such as campus-wide networks, lease lines, remote telephonic connections, and so forth.

- I Remote over open infrastructure.:
This includes the Internet and all variations thereupon.

Time:

- B During pre-specified dates and times:
For example, at a bank, tellers should only be able to access financial systems during periods when the bank is open for business and the teller is scheduled to be behind the counter.

- B At dynamically constrained dates and times:
For example, an authorization may be granted for a period of time and from a specific location based in a special condition (e.g., repair personnel during an outage) or be limited based on travel time (e.g., you cannot access from London 1 hour after you accessed from New York) or similar restrictions.

- C Any time:
No time restrictions are used in cases where anytime access is desired.

Connection:

- A Direct physical connection:
This is a physically implementes trusted path. Note that physical devices may be altered or connectors placed between physical devices, and this direct connection implies an unanltered path from user input to systems, including such things as proper key mappings and labels on physical devices.

- B 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. This is a non-physical trusted path approach.

- C 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.

- D Links:
This is any connection without protective mechanisms.

Changes and updates:

Changes are generally made to password-based and token-based authentication mechanisms and keys for encryption systems.

For passwords:

    - 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:

    • (a) People tend to have problems remembering the new passwords and write them down, which exposes the passwords further.
    • (b) The only advantage to this is that it reduces the average exposure time by half of the password change rate. A 6 month password change time leaves an average of 3 months of exposure if a password is guessed or stolen. Since it only takes seconds to minutes to install a back door that makes the password no longer necessary, the advantages are not very great.
    • (c) This is sometimes used as an alternative to removing user accounts from users who are no longer authorized to access systems, but it is far better to systematically remove those accounts and audit those removals than to depend on automated password change routines to do the job.
    • (d) While many systems support the automation of these changes, some do not, so the management overhead may be substantial for enforcing this system.

    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.

    - 4 Change from defaults during installation prior to network connection This is ALWAYS mandatory. Otherwise, default settings will be exploited in very short order in almost all cases.

For tokens

    - 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 updatable 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.

    - 4 Change from defaults during installation prior to network connection This is ALWAYS mandatory. Otherwise, default settings will be exploited in very short order in almost all cases.

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.

    - 4 Change from defaults during installation prior to network connection This is ALWAYS mandatory. Otherwise, default settings will be exploited in very short order in almost all cases. Most cryptographic systems have an initialization process that forces generation of new keys, but not all do.

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.

    - 4 Change from defaults during installation prior to network connection This is ALWAYS mandatory. Otherwise, default settings will be exploited in very short order in almost all cases. While new key generation is part of this process, other default settings. such as fallback to an insecure communications method, unlimited protocol use after authentication, and similar sorts of configuration items should also be set to proper values.

Copyright(c) Fred Cohen, 1988-2015 - All Rights Reserved