Authentication of Access Credentials

The authentication of access identity is the key to all information security. Without identification of an individual’s access to DoD files and without assurance that there is an appropriate authorization for accessing records, it is not possible to protect DoD in the age of cyber warfare.

The problem with identity authentication (see draft of DoDI 8520) is its complexity. The following issues need further resolution:

1. There are eight “Sensitivity Levels” for establishing Authentication Credentials Certificates. There are seven “Entity Environments” into which an Authentication Credential Certificates must fit in. The combinatorial numbers of public and government organizations that can offer acceptable credentials is very large.

2. The number of organizations that offer Authentication Credential Certificates, which are accepted by DoD, is over fifty. Each of these offers two or more levels of Authentication Credentials.   Therefore, a DoD Component or Agency must be ready to grant access to well over 20,000 applications from access entries that are authenticated and certified by a combination of well over 5,000 possible authentication sources.  Without a central authority to certify authentication it is not possible to track whether all authentications are valid.

3. In each case a Component or Agency must screen incoming requests whether the origination person has conformed to elaborate certification rules that are enumerated in several non-DoD publications (which are not completely consistent in detail). Incoming requests must be further judged whether the circumstance under which access privileges are requested applies (e.g. situational awareness) to a particular log-on session.
  
4. Delegating access authentication to Partner Networks leaves open a gap as to processes for their certification. Who certifies whether the partner network conforms to the DoD defined “sensitivity levels” and the DoD specified “entity environments” remains unknown.

5. How to execute the proposed policy provisions represents an administrative burden, especially for access is from smart-phones (which will represent the majority of accesses in the future) and in case of off-site locations. Getting generic authorizations from a component Designated Approval Authority (DAA) is time consuming. Particularly onerous would be the process of revocation of such privileges in the case of termination of an employee or when the location or equipment configuration changes.

6. The policy singles out non-Microsoft operating systems for added DAA approval of identify credentials. To single out non-windows operating systems for an added DAA action is unworkable, particularly as virtual computing (through Hypervisors) takes over many of the functions of the Microsoft operating system.

7. Identity Authentication Under Non-standard Conditions or During Contingency Operations must be obtained in real-time (or a matter of few hours). The Instructions are vague as to what it takes to issue new or replace lost or stolen identity credentials. The statement that “Temporary procedures should incorporate best security practices” is unacceptable because under conditions of cyber warfare this is exactly the condition under which an attacker would be scanning DoD systems.

8. The provision that information system administrators and network administrators will establish, publish, and execute procedures for identity authentication to systems under non-standard conditions creates a by-pass to these Instructions and cannot be endorsed as a consistent DoD policy.

9. Offering biometrics as only one of the options in authentication is inconclusive. Biometric identification should be a part of a DoD policy. Biometrics must be specified for any implementation. Offering biometrics only as an option, at the discretion of an information systems owner, weakens the execution of Policy.

10. These Instructions do not mention access to social computing that uses NIPRNET. Since social media also use access identification codes, it is not clear under what category will such authentication codes be classified and stored.

11. Waiving compliance of policy on Authentication Credentials is contrary to DoD’s current emphasis to protect its cyber operations. Obtaining authentication credentials from authorized sources is rapid and inexpensive. This policy should therefore mandate full compliance and not offer waivers.

12. The DoD identity authentication policy does not address interoperability of credentials with organizations, such as the FBI, CIA, DHS or FEMA. For instance, FBI has just awarded a contract to BAE Systems (a British company with HQ in the UK) to provide certification and accreditation services to ensure the confidentiality and privacy of FBI computer. How BAE will make information security risk assessments technically interchangeable with DoD remains to be seen.

SUMMARY

NOW: There are eight different keys produced by over fifty locksmiths to fit into seven different doors that sometimes change the location of the lock. The locksmiths do not always make identical keys. Once the keys are issued nobody keeps track as to who has what kind of key has been issued. When a key is lost, it takes a while to invalidate it and burglars will seek out such keys. Once a high quality key is issued, it can be used to get through all of the low quality doors, even if some of these doors lead into forbidden rooms.

FUTURE: It would be much easier to issue only one (or maybe two) keys to everyone. All intelligence would be in the door. The door will not open unless a person is instantly authorized to enter.  It is now feasible to  make doors intelligent.

The proposed DoD policy for identity authorization reflects an approach to managing access that reflects an inability to impose consistent application architecture across DoD applications. A much simpler approach can place the authority for accepting or rejecting access privileges on the application itself rather than on the grant of generic access privileges to designated individuals. Such an approach would greatly simplify access authorizations, but require the placement of access permission into the application server or into the hypervisor.