I think one of the problems with some of the discussion on the call is that we 
don’t really have a concept of a security perimeter for CA systems in the 
current requirements.  This makes it hard to write requirements that don’t 
allow stupid things, like cables running to systems which, while not connected 
to the public internet, do not have the appropriate access controls.

My thinking right now is that perhaps the best approach is to actually require 
an identified security perimeter, and then an air gapped system is a system 
that is not physically connected to any networks or devices outside the 
security perimeter, nor can it be accessed from outside of the security 
perimeter.

-Tim

From: Public [mailto:[email protected]] On Behalf Of Neil Dunbar via 
Public
Sent: Friday, September 8, 2017 5:18 AM
To: CA/Browser Forum Public Discussion List <[email protected]>
Subject: [cabfpub] Definitions of Air Gapped and Offline Systems

In the NetSec group, we’re updating the definitions suitable to Root CA 
systems, so that the definitions are both practical and robust. We’d like to 
solicit opinions from the broader public list.

In particular, we’re looking at the definitions of “Offline” and “Air Gapped” 
systems, which apply to the HSMs and controlling computers which form the Root 
CA certificate systems.

The desired security property is this: the equipment should not facilitate the 
injection of malicious data into the controlled Root CA system. The attack 
surface for any component of a Root CA system should be very low, extremely 
difficult to penetrate and the good state of the system should be demonstrable 
(and thus auditable) throughout the operational lifespan of the equipment.

Here are the current working definitions:
Air Gapped:  Physically and logically connected,  at the most, only to a single 
utility network (without physical connectivity to the internet) and connected 
to no other network.  (requires physical presence or physical proximity).

Tobias Josefowitz suggested this alternative:

Air Gapped: Physically and logically disconnected from all other networks, 
interaction of any kind requires physical presence in proximity. If the system 
is built of several components, network technology may be used to connect them 
as long as network equipment and all systems connected are themselves otherwise 
Air Gapped.

and for Offline:

Offline State: A Certificate System or component that is not available via any 
external connection (e.g. powered down or unplugged)

The notion being that a Root CA system should ideally be in both Air Gapped and 
Offline when not in active use.

Now, there are all sorts of notions about components being in known good state, 
and being not amenable to contagion while in operation and so on, but for the 
moment we want to concentrate on how to show that your Root CA system upholds 
the principle of being Air Gapped (and perhaps normally Offline). It was 
pointed out, for instance, that even having a Wifi kernel module active in a 
component (not connected to an AP) could still be a vector for attack because 
of weaknesses in firmware, exploitable via beacon broadcasts. Clearly, then, 
merely saying “Oh yes, this laptop could do Wifi, but we just don’t" is not 
enough - it’s still in a potentially bridged state, and therefore not Air 
Gapped. You would need to ensure that the EFI/BIOS and kernel did not activate 
the Wifi adapter in the boot sequence.

So - can we get some improvements to the definitions which are:

a) robust, i.e., not amenable to someone using excessive lawyer parsing to say 
that an architecture technically obeys the rules, but which in reality violate 
the security property
b) practical, i.e., that can be built and operated within a reasonable 
commercial operation, and have the salient properties demonstrated to an 
auditor; and that auditor could faithfully represent that the system under test 
does indeed adhere to the requirements?

Thanks,

Neil
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to