File permission controls are one of the more common control types you see in policies. Ensuring critical system files or proprietary data files are appropriately secured from unauthroized modication or even viewing is a basic policy compliance or data loss preventation topic.
Issue: Recently, I worked with a Qualys PC subscriber who wanted to make sure that the file permissions on specific files met their policy, but they had an issue were there "could" be some optional permissions set inconsistently on some files for administrator access and they need a way to specify varations of acceptable permission sets for the same account name. You usually see this defined as "These permissions or stronger are acceptable" and I included this in the concept of Compliance Variance.
In this use case, the permissions were be slightly different for the same account from system to system as Admin had either Full Control or a level of modify access nd they needed to account for this in a single control.
Here is the exact request:
- Admins should have minimum Modify (A:B:D:E:F:G:H:I:J:M)
- SYSTEMS must have Full Control (A:B:C:D:E:F:G:H:I:J:K:L:M:N)
- If anybody else listed in the ACE then the policy fails.
- Its Ok for Admins to have full control (Admin: A:B:C:D:E:F:G:H:I:J:K:L:M:N)
For an example
- The following policy has to pass (because Full Control is okay for Admin)
- The following has to fail (because Admin does not have sufficient rights, this is neither Modify nor Full Access level privileges)
- The following should also fail (because the Users group should not have permissions to this file)
They requested I suggest regex or string list which could be applied in the cardinality?
Resolution: In this example, I used the ? regex special character.
The ? character makes the preceding character optional in a string, ie: foo? will match foo or fo, if you want to make a group of characters optional, use ()'s ie, foo(ds)? will match foo or foods
To match the the first two items above, we can put the option permissions that allow admin to have permissions from Modify rights to Full Privilege rights. can use the following as the expected value in the policy compliance report:
The third case will be addressed by using cardinality is set correctly.
So use Matches instead of Contains.
Policy Creation Procedure: So, we need to edit a control in the policy to meet these requirements. As always, treat policy creation as a two-step process.
First just put the control in the policy and run a compliance template report in PDF format to see how data is returned:
If the the Actual Value is what you need already or even close, copy and past the values into a wordpad window or regex editor and edit as needed.
The first use case is that Admin can have different values, either Full Control or Modify. In this report, we see this Admin Account has Full Control already, so when I copy and paste the values into RegexPal, I also add entries for the other conditions.
For the third use case, the customer reports permissions for the SYSTEMS entry will be Full Access consistently:
For the fourth use case, excluding other accounts such as the Users group, we can infer since neither of the regex expressions used so far matched the "Users: A:E:G:H" entry. We need to be sure to use the cardinality matches rather than "is contained in" so that we evaluation actual configuration values against our regex explicitly.
Second Step: So, now that we have tested our regex, we paste our entries into the policy control parameter and run the report to see if we pass/fail as expected.
Edit Tip: Be very careful about spaces. A benefit of running the report first and then editing the Expected Value text is that you can see the exact format of the text returned by the scanner. Notice there is no space after the account and group entries in the regex.
So, lets see the report output and if our regex passed. Below we see that we passed because both SYSTEM and Administrators have Full Access. Also, note the use of the "matches regular expression list" cardinality. This is an often overlooked area of control creation. Cardinality is fully described in online help.
Side Note: It is a good idea to test the same regex logic with multiple file permission controls to see if the control will fail on non matches. Since Qualys has decoupled reporting from scanning and scans for all controls, you can use this architectural advantage to use other file permission controls that have different returned values to test your regex for the control you are working on. For example, I noticed that on my test systems, CID's 3373 and 1682 had very different user permissions. I could use these other controls in a scratchpad policy just to test my regex above. This is often easier and safer than trying to get access to the target system to change file permission values for testing positive and negative control logic.