Managing Compliance Policies


#1

I’m interested to hear how people are managing compliance policies. Are you applying them at a provider/cluster level, or individual VMs? How are you distinguishing between OS versions?

I started looking at the ShellShock policy that @jonnyfiveiq did and it’s limited to RHEL 6.5. How do folks generalize that? Rather than a “Linux Security Check” profile, do you do individual “Red Hat 6 Security Check”, “Red Hat 7 Security Check”, “Ubuntu 14 Security” profiles?

Can we use the scope on the policy to be more specific and have a single “Linux Security Check” profile that includes “RHEL 6 Shell-Shock Vulnerability”, “RHEL 7 Shell-Shock Vulnerability” and “Ubuntu 14 Shell-Shock Vulnerability” Policies?

Interested in hearing how folks are doing things.

Thanks!
Matt


#2

Bumping and if anyone in the community can help @hyclak it would be greatly appreciated.


#3

#4

I recently had the same issue when creating a single policy for DROWN to identify vulnerable openssl packages. I ended up creating one single policy for RHEL5/6/7. Have a look at http://cloudformsblog.redhat.com/2016/03/01/drown-openssl-vulnerability/

I basically use ‘OR’ statements for each openssl version and check the release number against a list of vulnerable packages. The regex could be improved (I basically list all releases individually) but it does the job.

I found it tricky to get my head around the Condition Editor at first. The simulation tool helps but you will notice that it stops checking OR statements as soon as it finds a match, colouring all remaining statements as green when they should be red and/or black as never evaluated. Anyway I hope this helps in getting you started.


#5

Jerome,

I did see your blog post. I wasn’t able to directly import your policy into CF 3.2, but I’ll see if I can re-create it. It definitely helps me look at some of the options available. The regex is a bit of a pain - even in the example John did on shellshock, once an update was released the regex would have to be updated to include the new not-vulnerable packages. It sounds like you went in the reverse direction which might be a better option. Either way, it would be great if there was an RPM comparator function where a version and release could be specified with the typical <, >, == comparators.

Where are you applying these types of policies? At the VM Level? Cluster? Provider? I’m curious what challenges you may have faced with managing that.

Thanks!
Matt