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.