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

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

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.