what referencing a control/requirement means

[Marek Haicman]

Hello,
I have stumbled upon a case where I am not sure, if some rule should have a
reference or not. Can you help me with your view on this situation? I will
use the case as an example (RHEL8 content) :)

Reference: The operating system must uniquely identify peripherals before
establishing a connection.
<http://securityrules.info/about/xovos-tufes-rumeb-decex/SV-71029r1_rule>

Now we have five rules in two groups
* install USBGuard package
and
* enforce USBGuard service to be enabled
These two rules satisfy, in my opinion, the requirement (at least for the
USB peripherals) -> USBGuard is "drop by default", so anything acceptable
has to be allowed explicitly.

* allow Class 03 (HID) USB devices
* allow Class 08 (HUB) USB devices
* allow any combination of HID and HUB USB devices
These rules are not increasing the security of the system - they soften the
hardening. So they go against the requirement to some extent. But without
these, machines would not be usable for general audience, so as a
compromise, we do want to have them available to the users.

And now the question - should the reference be part of all the rules? Or
just the ones that really increases the security of the system?

What's your interpretation of the reference, if you are reading it in the
guide?

Thanks!
Marek

[Steve Grubb]

Hello,

On Tuesday, December 17, 2019 7:55:37 AM EST Marek Haicman wrote:
>  I have stumbled upon a case where I am not sure, if some rule should
> have a
>  reference or not. Can you help me with your view on this situation? I will
>  use the case as an example (RHEL8 content) :)
>  
>  Reference: The operating system must uniquely identify peripherals before
>  establishing a connection.
>  <http://securityrules.info/about/xovos-tufes-rumeb-decex/SV-71029r1_rule>
>  
>  Now we have five rules in two groups
>  * install USBGuard package
>  and
>  * enforce USBGuard service to be enabled
>  These two rules satisfy, in my opinion, the requirement (at least for the
>  USB peripherals) -> USBGuard is "drop by default", so anything acceptable
>  has to be allowed explicitly.
>  
>  * allow Class 03 (HID) USB devices
>  * allow Class 08 (HUB) USB devices
>  * allow any combination of HID and HUB USB devices
>  These rules are not increasing the security of the system - they soften the
>  hardening. So they go against the requirement to some extent. 
Not really. A hub is harmless. It doesn't do anything except multiplex other 
devices. It's the other devices that you should be worried about.

The crux of the requirement really boils down to:  know what is being 
connected. Do not allow unknown devices. So, you could say that keyboards and 
mice are known and approved. Everything else is not.

What /I/ am much more concerned with is if someone plugs in a flash drive, 
ethernet adapter, or wifi adapter. These can be used to exfiltrate or infiltrate 
data or bypass logging and monitoring. And that seems to also be what the 
author was also concerned about given the examples in the vulnerability 
discussion.


>  But without
>  these, machines would not be usable for general audience, so as a
>  compromise, we do want to have them available to the users.
>  
>  And now the question - should the reference be part of all the rules? Or
>  just the ones that really increases the security of the system? 
In my opinion, all of them as a group meet the requirement since they form 
the policy. But there is also firewire, bluetooth, external SCSI, RS-232, or 
printer connectors.  You can really go far down the rabbit hole.  :-)

-Steve

[Marek Haicman]

Hello Steve,

On Tue, Dec 17, 2019 at 4:09 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote:

>  Hello,
>
>  On Tuesday, December 17, 2019 7:55:37 AM EST Marek Haicman wrote:
>  > I have stumbled upon a case where I am not sure, if some rule should
>  have a
>  > reference or not. Can you help me with your view on this situation? I
>  will
>  > use the case as an example (RHEL8 content) :)
>  >
>  > Reference: The operating system must uniquely identify peripherals before
>  > establishing a connection.
>  > <http://securityrules.info/about/xovos-tufes-rumeb-decex/SV-71029r1_rule
>  >
>  >
>  > Now we have five rules in two groups
>  > * install USBGuard package
>  > and
>  > * enforce USBGuard service to be enabled
>  > These two rules satisfy, in my opinion, the requirement (at least for the
>  > USB peripherals) -> USBGuard is "drop by default", so anything
> acceptable
>  > has to be allowed explicitly.
>  >
>  > * allow Class 03 (HID) USB devices
>  > * allow Class 08 (HUB) USB devices
>  > * allow any combination of HID and HUB USB devices
>  > These rules are not increasing the security of the system - they soften
>  the
>  > hardening. So they go against the requirement to some extent.
>
>  Not really. A hub is harmless. It doesn't do anything except multiplex
>  other
>  devices. It's the other devices that you should be worried about.
>
>  Unless the hub eavesdrops :D 
The crux of the requirement really boils down to:  know what is being
>  connected. Do not allow unknown devices. So, you could say that
> keyboards
>  and
>  mice are known and approved. Everything else is not.
>  

What /I/ am much more concerned with is if someone plugs in a flash drive,
>  ethernet adapter, or wifi adapter. These can be used to exfiltrate
> or
>  infiltrate
>  data or bypass logging and monitoring. And that seems to also be what the
>  author was also concerned about given the examples in the vulnerability
>  discussion.
>
>
>  > But without
>  > these, machines would not be usable for general audience, so as a
>  > compromise, we do want to have them available to the users.
>  >
>  > And now the question - should the reference be part of all the rules? Or
>  > just the ones that really increases the security of the system?
>
>  In my opinion, all of them as a group meet the requirement since they form
>  the policy. But there is also firewire, bluetooth, external SCSI, RS-232,
>  or
>  printer connectors.  You can really go far down the rabbit hole.  :-)
>
>  And that's what I am asking - are they together forming a policy? Or are 
they
all related to the policy, but only the core rules are forming it?

What if user wants the machine to disallow any USB device - removal of the
rule (that is part of the policy) will make the machine hardening stricter,
and to follow requirement in even stricter sense.

It is an unusual situation, as usually more rules -> stricter config.

>  -Steve
>
>
>
>

[Steve Grubb]

On Tuesday, December 17, 2019 12:03:49 PM EST Marek Haicman wrote:
>  > > And now the question - should the reference be part of all
> the rules?
>  > > Or just the ones that really increases the security of the system?
>  > 
>  > In my opinion, all of them as a group meet the requirement since they
>  > form the policy. But there is also firewire, bluetooth, external SCSI,
>  > RS-232, or printer connectors.  You can really go far down the rabbit
>  > hole.  :-)
>  > 
>  > And that's what I am asking - are they together forming a policy? Or are
>  they all related to the policy, but only the core rules are forming it? 
They all are required to meet a guess at the deployment environment. Based on 
specific site knowledge, you could make a different interpretation. But that is 
beyond general guidance. For example, based on knowledge of your local 
network, you might decide that you have to allow ICMP redirects for network 
provider failover. There are always deployment unknowns. But what you can say 
is this policy is secure for specific assumptions about a deployment.

>  What if user wants the machine to disallow any USB device - removal
> of the
>  rule (that is part of the policy) will make the machine hardening stricter,
>  and to follow requirement in even stricter sense. 
Well, then they would probably just blacklist the device driver and not use 
usbguard.

>  It is an unusual situation, as usually more rules -> stricter
> config. 
But is that really a problem? People can always tailor content to fit their 
site policy. Maybe they want passwords that are 20 characters long? Maybe 
they always want to enter via a jump box and want a pam rule enforcing that. 
Maybe they want 2 factor authentication with an RSA token?

There is a point where you just stop and say, this meets the needs of a 
typical deployment based on a specific threat model and a guess at the 
deployment environment. This is why common criteria lists its addressed 
threats accompanied by assumptions. If the assumptions are wrong, the 
mitigations may not address all of the threats. In this case, we are assuming 
that a keyboard and mouse may be a USB device.

-Steve

[Shawn Wells]

On 12/17/19 12:33 PM, Steve Grubb wrote:
>  On Tuesday, December 17, 2019 12:03:49 PM EST Marek Haicman wrote:
> >>> And now the question - should the reference be part of all the rules?
> >>> Or just the ones that really increases the security of the system?
> >> In my opinion, all of them as a group meet the requirement since they
> >> form the policy. But there is also firewire, bluetooth, external SCSI,
> >> RS-232, or printer connectors.  You can really go far down the rabbit
> >> hole.:-)
> >>
> >> And that's what I am asking - are they together forming a policy? Or are
> > they all related to the policy, but only the core rules are forming it?
>  They all are required to meet a guess at the deployment environment. Based on
>  specific site knowledge, you could make a different interpretation. But that is
>  beyond general guidance. For example, based on knowledge of your local
>  network, you might decide that you have to allow ICMP redirects for network
>  provider failover. There are always deployment unknowns. But what you can say
>  is this policy is secure for specific assumptions about a deployment.
>
> > What if user wants the machine to disallow any USB device - removal of the
> > rule (that is part of the policy) will make the machine hardening stricter,
> > and to follow requirement in even stricter sense.
>  Well, then they would probably just blacklist the device driver and not use
>  usbguard.
>
> > It is an unusual situation, as usually more rules -> stricter config.
>  But is that really a problem? People can always tailor content to fit their
>  site policy. Maybe they want passwords that are 20 characters long? Maybe
>  they always want to enter via a jump box and want a pam rule enforcing that.
>  Maybe they want 2 factor authentication with an RSA token?
>
>  There is a point where you just stop and say, this meets the needs of a
>  typical deployment based on a specific threat model and a guess at the
>  deployment environment. This is why common criteria lists its addressed
>  threats accompanied by assumptions. If the assumptions are wrong, the
>  mitigations may not address all of the threats. In this case, we are assuming
>  that a keyboard and mouse may be a USB device. 

+1 to Steve's framing here.

The reference is from the American Department of Defense requirements. 
These are for military systems incorporated into combat systems, 
classified information processing, etc. Nothing general purpose about 
such deployments. The DoD SRG's also reflect an acceptance of security 
over usability which should also be acknowledged.

And when system operators want to adjust the profiles/baseline, their 
actions reflect deployment-specific acceptance of tradeoffs. Some might 
be to further harden ("block all USB!!") or rebalance towards usability. 
That's part of why SCAP Workbench is needed and helpful -- allows 
GUI-based tailoring in an easy to use GUI. Shows that tailoring has been 
thought of and specifically addressed in workflow/tooling options.