[cabf_netsec] [EXTERNAL]- Definition of "Air Gapped"

Ben Wilson bwilson at mozilla.com
Tue Dec 6 17:09:27 UTC 2022


All,

We talked about this on the call today. (Just calling it back up here for
more discussion.)

Also, we need to address the concepts of "offline system" and "powered
off".
"Offline systems" and "powered off systems" need to be physically secured.
In other words, we cannot just require that Air-Gapped CA systems be
physically secured.

Thanks,

Ben

On Tue, Oct 18, 2022 at 1:43 AM Inigo Barreira <Inigo.Barreira at sectigo.com>
wrote:

> I support option C and clarify what Pedro is suggesting.
>
>
>
> *De:* Netsec <netsec-bounces at cabforum.org> *En nombre de *Pedro FUENTES
> via Netsec
> *Enviado el:* sábado, 15 de octubre de 2022 8:40
> *Para:* Ben Wilson <bwilson at mozilla.com>; CABF Network Security WG <
> netsec at cabforum.org>
> *Asunto:* Re: [cabf_netsec] [EXTERNAL]- Definition of "Air Gapped"
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hello Ben,
>
> In principle I would say that extending the concept of lack of
> connectivity to “Electrical Connections” would impose a big challenge,
> because even if the systems are normally powered off and electrical cables
> are disconnected, at the moment of powering up the systems (i.e. for a
> ceremony) we’d be breaching that requirement.
>
> BR/P
>
>
>
> On 15 Oct 2022, at 05:39, Ben Wilson via Netsec <netsec at cabforum.org>
> wrote:
>
>
>
> All,
>
>
>
> Both https://csrc.nist.gov/glossary/term/air_gap
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__csrc.nist.gov_glossary_term_air-5Fgap%26d%3DDwMFaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DLmvNtrygpWXbKZ3KY7uXI6Qz7YaICZdsR9VOMM9tOUo%26s%3D05O03TdRvsnIHsm0s4tXXiC6o8fWB9-q1mnU1gzxe0k%26e%3D&data=05%7C01%7Cinigo.barreira%40sectigo.com%7C596c142721e64348e8b608daae781d45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638014128352730649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=VBPO1vK7pipLk2hUCYUNFcAaHgRwiiozPS2E4MCavP0%3D&reserved=0>
> and https://www.rfc-editor.org/rfc/rfc4949
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.rfc-2Deditor.org_rfc_rfc4949%26d%3DDwMFaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DLmvNtrygpWXbKZ3KY7uXI6Qz7YaICZdsR9VOMM9tOUo%26s%3DAISpylDx7SDnLQ0TQ0PzCB8PL8aPhNArmjJzOoZyUsY%26e%3D&data=05%7C01%7Cinigo.barreira%40sectigo.com%7C596c142721e64348e8b608daae781d45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638014128352730649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=NQGIjuSUpeQ2%2BqDeotRQbvIbthSOKeiKJEEjyL5mpzk%3D&reserved=0>
> define "air gap" as "An interface between two systems at which (a) they are
> not connected physically and (b) any logical connection is not automated
> (i.e., data is transferred through the interface only manually, under human
> control)."
>
>
>
> But this definition seems antiquated and not entirely clear. For instance,
> it doesn't address wireless connections, only physical connections. Also, I
> believe that use of the word "interface" and other language in that
> definition have the potential to cause confusion.
>
>
>
> RFC 4949 does clarify the definition with a parenthetical and an example:
>
>
>
> (See: sneaker net. Compare: gateway.)
>
>
>
> Example: Computer A and computer B are on opposite sides of a room. To
> move data from A to B, a person carries a disk across the room. If A and B
> operate in different security domains, then moving data across the air gap
> may involve an upgrade or downgrade operation.
>
>
>
> One potential definition of "air-gapped" (Alternative A) could be
> "separation between two devices or networks because they lack an electrical
> or wireless connection, which prevents them from communicating except by
> some external, manual, human interaction (e.g. computer A and computer B
> are on opposite sides of a room, and to move data from A to B, a person
> must carry a transfer device across the room)."
>
>
>
> Alternative B could be:  "the absence of connections (electrical,
> wireless, or any other networking) that prevents a system from
> communicating with another system and requires human intervention and a
> transfer device for data to move between the two systems."
>
>
>
> Alternative C would be to define "Air Gap", as above in the CSRC/RFC
> definition, and add the words "or wirelessly", so that it would read "An
> interface between two systems at which (a) they are not connected
> physically *or wirelessly* and (b) any logical connection is not
> automated (i.e., data is transferred through the interface only manually,
> under human control)."
>
>
>
> Also, I'll raise it here, for completeness, but I'm thinking we do not
> want to enlarge the scope of "air-gapped" to allow cryptographic, tunneled
> connections. I'm inclined to keep our definition simple (and hence
> hopefully more secure), but if anyone has other suggestions, please feel
> free to chime in.
>
>
>
> Please provide Alternatives D to Z.
>
>
>
> Finally, while I'm thinking about it, in the NCSSRs, do we want to
> consider "powered off and locked in a safe" separately from "air gapped" -
> it seems there might be a different risk profile?
>
>
>
> Thanks in advance,
>
>
>
> Ben
>
>
>
>
>
>
>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_netsec&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=LmvNtrygpWXbKZ3KY7uXI6Qz7YaICZdsR9VOMM9tOUo&s=MIKlQspu8CuNGjk6ZI-0bwJ1_JcZZSl4qT4xxyH0c3A&e=
>
>
>
>
> *WISeKey SA*
>
>
> *Pedro Fuentes*CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00
> Mobile: + 41 (0) 791 274 790
>
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
>
>
> *Stay connected with WISeKey
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wisekey.com%2F&data=05%7C01%7Cinigo.barreira%40sectigo.com%7C596c142721e64348e8b608daae781d45%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638014128352886870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=qzAaArwhgnAenqj27kEnGc3Og4yuYUaYLw61Gi25o8M%3D&reserved=0>*
>
> *THIS IS A TRUSTED MAIL*: This message is digitally signed with a WISeKey
> identity. If you get a mail from WISeKey please check the signature to
> avoid security risks
>
>
>
> *CONFIDENTIALITY: *This email and any files transmitted with it can be
> confidential and it’s intended solely for the use of the individual or
> entity to which they are addressed. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. If you have
> received this email in error please notify the sender
>
>
>
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of
> this message and does not accept any liability for any errors or
> omissions herein as this message has been transmitted over a public
> network. Internet communications cannot be guaranteed to be secure or
> error-free as information may be intercepted, corrupted, or contain
> viruses. Attachments to this e-mail are checked for viruses; however, we do
> not accept any liability for any damage sustained by viruses and therefore
> you are kindly requested to check for viruses upon receipt.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20221206/f537d093/attachment.html>


More information about the Netsec mailing list