Tuesday, July 10, 2012

Reader Comment – 07-09-12 – TWIC for Cyber

Yesterday @bryansowen (the Twitter handle for Bryan Owen, an ICS commenter) left an interesting comment on my earlier post about vetting security contractors, noting that:

“Identity and personal surety is an area that government could really help the private sector.”

He also noted that the use of the Transportation Workers Identification Credential could be used in the cybersecurity world, “if costs could be brought down”. A number of other folks, notably some vocal and influential members of Congress, have noted the same thing for other areas of infrastructure protection (CFATS for example).

TWIC Expansion

As I have noted before, the current TWIC program is limited by law to just transportation workers needing access to facilities covered under the Maritime Transportation Security Act (MTSA). While it is clearly true that what Congress authorizes Congress can expand, there would be a number of legal hurdles that would have to be overcome in any legislation that expands the use of TWIC beyond the transportation security arena. First and foremost would be the necessity of moving it out of TSA into an agency with a broader security mandate; NPPD for instance.

Secondly, there would have to be a major expansion of the number and location of facilities where the TWIC application could be submitted and the TWIC could be picked-up and activated. This would also have the benefit of reducing the current Congressional push to reduce the security of the TWIC by allowing the TWIC to be mailed to applicants.

TWIC and Cybersecurity

The TWIC is a biometrically enabled identification document, with the authorized holder’s fingerprints encoded on the card. With a TWIC Reader (not yet officially in use) enabled access-control system the holder’s identity and access status can be verified within seconds of the card being offered to a TWIC Reader. Thus a TWIC could be used for allowing physical access to computer hardware. The Army has already announced that they are using TWIC’s for virtual access to their computer networks. So we have both modes of access covered.

That doesn’t mean that everyone with access to a critical infrastructure computer system would be required to have a TWIC. First off, many of those systems would not be connected to assets worthy of homeland security level protection. Even covered systems might not require TWIC for all access; it would depend on the level of access/control. A person with ‘Read Only’ access might not need a TWIC (depending on system configuration) while someone who has privileges that allow changes to processes probably would.

TWIC and Vendor Support

A TWIC type identification credential might be useful in solving the problem of allowing vendor remote access to control systems for maintenance and troubleshooting activities. Having the vendor provide a list of approved support personnel and then biometrically verifying that identity would establish a level of access control currently not available. The only shortcoming with this idea is that currently only US citizens and legal residents can obtain a TWIC. This would be of little use to a vendor whose support center resides outside of the US.

TWIC Alternatives

Any number of vendors would be capable of setting up a biometrically verified access control system. The difference between those systems and the TWIC has little to do with the actual identity document. The significant difference is that before someone is given a TWIC they are vetted against the FBI Terrorist Screening Database. That is not an option available to any vendor outside of the government.

The Way Forward

We are a long-way from being able to use the existing TWIC system for cybersecurity protection of critical infrastructure control systems. But, this is something that is certainly worthy of consideration in the development of any cybersecurity legislation that would have any hope of protecting high-risk control systems in critical infrastructure.

No comments:

/* Use this with templates/template-twocol.html */