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.