Tuesday Jul 07, 2015

Customising Solaris Compliance Policies

When we introduced the compliance framework in Solaris 11.2 there was no easy way to customise (tailor) the policies to suit individual machine or site deployment needs. While it was certainly possible for users familiar with the XCCDF/OVAL policy language it wasn't easy to do in away that preserved your customisations while still allowing access to new and policy rules when the system was updated.

To address this a new subcommand for compliance(1M) has been added that allows creation of a tailoring.  The initial release of tailoring in Solaris 11.3 allows the enabling and disabling of individual checks, and the team is already working on enhancing it to support variables in a future release.

The default and simplest way of using 'compliance tailor' is use the interactive pick tool:

# compliance tailor -t mysite
*** compliance tailor: No existing tailoring 'mysite', initializing
tailoring:mysite> pick



The above shows the interactive mode where using 'x' or 'space' allows us to enable or disable an individual test.  Note also that since the Solaris 11.2 release all the tests have been renumbered and now have unique rule identifiers that are stable across releases of Solaris.  The same rule number always refers to the same test in all of the security benchmark policy files delivered with Solaris.

When exiting from the interactive pick mode just type 'commit' to write this out to a locally installed tailoring; that will create an XCCDF tailoring file under /var/share/compliance/tailorings.  Those tailoring files should not be copied from release to release.

There is also an 'export' action for the tailoring subcommand that allows you to save off your customisations for importing into a different system, this works similarly to zonecfg(1M) export.

$ compliance tailor -t mysite export | tee /tmp/mysite.out
set tailoring=mysite
# version=2015-06-29T14:16:34.000+00:00
set benchmark=solaris
set profile=Baseline
# OSC-16005: All local filesystems are ZFS
exclude OSC-16005
# OSC-15000: Find and list files with extended attributes
include OSC-15000
# OSC-35000: /etc/motd and /etc/issue contain appropriate policy text
include OSC-35000

The saved command file can then be used for input redirection to create the same tailoring on another system.

To run an assessment of the system using a tailoring we simply need to do this:

# compliance assess -t mysite
Assessment will be named 'mysite.2015-06-29,15:22'
Title   Package integrity is verified
Rule    OSC-54005
Result  PASS
...


 
  



        
    

Thursday Nov 27, 2014

CVE metadata in Solaris IPS packages for improved Compliance reporting

I'm pleased to announce that the Solaris 11 /support repository now contains metadata for tracking security vulnerability fixes by the assigned CVE number. This was a project that Pete Dennis and I have been working on for some time now.  While we worked together on the design of the metadata and how it should be presented I'm completely indebted to Pete for doing the automation of the package generation from the data in our bug databases - we don't want humans to generate this by hand because it is error prone.

What does this mean for you the Solaris system admin or a compliance auditor  ?

The intent of this is to make it much easier to determine if your system has all the known and required security vulnerability fixes.  This should stop you from attempting to derive this information based on other sources. This is critically important since sometimes in Solaris we choose to fix a bug in an upstream FOSS component by applying the code patch rather than consuming a whole new version - this is a risk/benefit trade off that we take on a case by case basis.  While all this data has been available for sometime in My Oracle Support documents it wasn't easily available in a scriptable form - since it was intended to be read by humans.

The implemenation of this is designed to be applied to any other Oracle, or 3rd party, products that are also delivered in IPS form. 

For Solaris we have added a new metadata package called:  pkg:/support/critical-patch-update/solaris-11-cpu. This new package lives above entire in the dependency hiearchy and contains only metadata that maps the CVE-IDs to the package version that contains the fix.  This allows us to retrospectively update the critical-patch-update metadata where an already shipping version contains the fix for a given CVE.

Each time we publish a new critical patch update a new version of the package is published to the /support repository along with all the new versions of the packages that contain the fixes.  The versioning for this package is @YYYY.MM.VV where VV is usually going to be '1' but this allows us to respin/republish a given critical patch update with in the same month, note the VV is not DD it is NOT the day in the month.

We can search this data using either the web interface on https://pkg.oracle.com/solaris/support or using the CLI.  So lets look at some examples of the CLI searching.  Say we want to find out which packages contain the fix for the bash(1) Shellshock vulnerability and we know that one of the CVE-IDs for that is CVE-2014-7187:

# pkg search :CVE-2014-7187:
INDEX         ACTION VALUE                                                PACKAGE
CVE-2014-7187 set    pkg://solaris/shell/bash@4.1.11,5.11-0.175.2.2.0.8.0 pkg:/support/critical-patch-update/solaris-11-cpu@2014.10-1
CVE-2014-7187 set    pkg://solaris/shell/bash@4.1.11,5.11-0.175.2.3.0.4.0 pkg:/support/critical-patch-update/solaris-11-cpu@2014.10-1

That output tells us which packages and versions contain a fix and which critical patch update it was provided in.

For another example lets find out the whole list of fixes in the October 2014 critical patch update:

pkg search -r info.cve:|grep 2014.10
info.cve   set    CVE-1999-0103 pkg:/support/critical-patch-update/solaris-11-cpu@2014.10-1
info.cve   set    CVE-2002-2443 pkg:/support/critical-patch-update/solaris-11-cpu@2014.10-1
info.cve   set    CVE-2003-0001 pkg:/support/critical-patch-update/solaris-11-cpu@2014.10-1
....

Note that the placement of colon (:) is very signficant in IPS and that the keyname is 'info.cve' and the values have CVE in upper case.

The way that metadata is setup allows for the cases where a given CVE-ID applies to multiple packages and also where a given package version contains fixes for multiple CVE-IDs.

If we simply want to know if the fix for a given CVE-ID is installed the using 'pkg search -l' with the CVE-ID is sufficent eg:

# pkg search -l CVE-2014-7187
INDEX      ACTION VALUE         PACKAGE
info.cve   set    CVE-2014-7187 pkg:/support/critical-patch-update/solaris-11-cpu@2014.10-1

If it wasn't installed then we would have gotten no output.

If you want to have a system track only the Critical Patch Updates and not every SRU available in the /support repository then when you do an update instead of doing 'pkg update' or 'pkg update entire@<latest>' do 'pkg update solaris-11-cpu@latest'.  Note that initially systems won't have the 'solaris-11-cpu' package installed since as I mentioned previously is is "above" the entire package.  When you update to the latest version of the Critical Patch Update package it will install any intermediated SRUs that were released between this version and the prior one you had installed.

For some further examples have a look at MOS Doc ID 1948847.  Currently only the Solaris 11.2 critical patch update metadata is present but we intend to very soon backpublish the data for prior Solaris 11 critical patch updates as well.

Hope this helps with your compliance auditing.  If you are an auditor no more arguments with the sys admin teams about whither a fix is installed. If you are a system admin more time for your "real job" since you can now easily give the auditor the data they need.

The compliance team is also working on updating the Solaris and PCI-DSS security benchmarks we deliver with the compliance(1M) framework to use this new CVE metadata in determining if the system is upto date, since from a compliance view point we really want to know that all known and available security fixes are installed not that you are running the absolutely latest and greatest version of Solaris.

I have also been working with the OVAL community (part of SCAP) to define a schema for the Solaris IPS system.  This is due to be released with a future version of the OVAL standard.  That will allow us to use this same framework of metadata to also deliver OVAL xml files that map the CVE-IDs to packages.  When that is available we may choose to deliver OVAL xml files as part of the critical-patch-update package as an additional method of querying the same metadata. 

-- Darren

Tuesday Apr 29, 2014

Solaris 11 Compliance Framework

During the Solaris 11 launch (November 2011) one of the questions I was asked from the audience was from a retail customer asking for documentation on how to configure Solaris to pass a PCI-DSS audit.  At that time we didn't have anything beyond saying that Solaris was secure by default and it was no longer necessary to run the Solaris Security Toolkit to get there.  Since then we have produced a PCI-DSS white paper with Coalfire (a PCI-DSS QSA) and we have invested a significant amount of work in building a new Compliance Framework and making compliance a "lifestyle" feature in Solaris core development.

We delievered OpenSCAP in Solaris 11.1 since SCAP is the foundation language of how we will provide compliance reporting. So I'm please to be able to finally talk about the first really signficant part of the Solaris compliance infrastruture which is part of Solaris 11.2.

Starting with Solaris 11.2 we have a new command compliance(1M) for running system assements against security/compliance benchmarks and for generating html reports from those.  For now this only works on a single host but the team hard at work adding multi-node support (using the Solaris RAD infrastructure) for a future release.

The much more signficant part of what the compliance team has been working on is "content".  A framework without any content is just a new "box of bits, lots of assembly required" and that doesn't meet the needs of busy Solaris administrators.  So starting with Solaris 11.2 we are delivering our interpretation of important security/compliance standards such as PCI-DSS.  We have also provided two Oracle authored policies: 'Solaris Baseline' and 'Solaris Recommended', a freshly installed system should be getting all passes on the Baseline benchmark.  The checks in the Recommended benchmark are those that are a little more controversial and/or take longer to run.

Lets dive in and generate an assesment and report from one of the Solaris 11.2 compliance benchmarks we provide:

# pkg install security/compliance 
# compliance assess
# compliance report

That will give us an html report that we can then view.  Since we didn't give any compliance benchmark name it defaults to 'Solaris Baseline', so now lets install and run the PCI-DSS benchmark. The 'security/compliance' package has a group dependency for 'security/compliance/benchmark/pci-dss' so it will be installed already but if you don't want it you can remove that benchmark and keep the others and the infrastructure.

# compliance assess -b pci-dss
Assessment will be named 'pci-dss.Solaris_PCI-DSS.2014-04-14,16:39'
# compliance report -a pci-dss.Solaris_PCI-DSS.2014-04-14,16:39

If we want the report to only show those tests that failed we can do that like this:

# compliance report -s fail -a pci-dss.Solaris_PCI-DSS.2014-04-14,16:39

We understand that many of your Solaris systems won't match up exactly to the benchmarks we have provided and as a result we have delivered the content in a way that you can customise it. Over time the ability to build custom benchmarks from the checks we provide will be come part of the compliance(1M) command (tailoring was added in Solaris 11.3 so the information below has been superceeded) but for now you can enable/disable checks by editing a copy of the XML files. Yes I know many of you don't like XML but this time it isn't too scary for just this part, crafting a whole check from scratch is hard though but that is the SCAP/XCCDF/OVAL language for you!.

So for now here is the harder than it should be way to customise one of the delivered benchmarks, using the PCI-DSS benchmark as an example:

# cd /usr/lib/compliance/benchmarks
# mkdir example
# cd example
# cp ../pci-dss/pci-dss-xccdf.xml example-xccdf.xml
# ln -s ../../tests
# ln -s example-xccdf.xml xccdf.xml

# vi example-xccdf.xml

In your editor you are looking for lines that look like this to enable or disable a given test:

<select idref="OSC-27505" selected="true" />

You probably also want to update these lines to indicate that it is your benchmark rather than the original we delivered.

<status date="2013-12-12">draft</status>
<title>Payment Card Industry Data Security Standard</title>
<description>solaris-PCI-DSS-v.1</description>

Once you have made the changes you want exit from your editor and run 'compliance list' and you should see your example benchmark listed, you can run run assesments and generate reports from that one just as above.  It is important you do this by making a copy of the xccdf.xml file otherwise the 'pkg verify' test is always going to fail and more importantly your changes would be lost on package update.

Note that we re-numbered these tests in the Solaris 11.2 SRU and 11.3 to provide a peristent unique identifier and namespace for each of the tests we deliver, it just didn't make the cut off for Solaris 11.2 release.

I would really value feedback on the framework itself and probably even more importantly the actual compliance checks that our Solaris Baseline, Solaris Recommended, and PCI-DSS security benchmarks include.

Updated August 6th 2015 to added information about Solaris 11.3 changes.

Monday Oct 21, 2013

Do your filesystems have un-owned files ?

As part of our work for integrated compliance reporting in Solaris we plan to provide a check for determining if the system has "un-owned files", ie those which are owned by a uid that does not exist in our configured nameservice.  Tests such as this already exist in the Solaris CIS Benchmark (9.24 Find Un-owned Files and Directories) and other security benchmarks.

The obvious method of doing this would be using find(1) with the -nouser flag.  However that requires we bring into memory the metadata for every single file and directory in every local file system we have mounted.  That is probaby not an acceptable thing to do on a production system that has a large amount of storage and it is potentially going to take a long time.

Just as I went to bed last night an idea for a much faster way of listing file systems that have un-owned files came to me. I've now implemented it and I'm happy to report it works very well and peforms many orders of magnatude better than using find(1) ever will.   ZFS (since pool version 15) has per user space accounting and quotas.  We can report very quickly and without actually reading any files at all how much space any given user id is using on a ZFS filesystem.  Using that information we can implement a check to very quickly list which filesystems contain un-owned files.

First a few caveats because the output data won't be exactly the same as what you get with find but it answers the same basic question.  This only works for ZFS and it will only tell you which filesystems have files owned by unknown users not the actual files.  If you really want to know what the files are (ie to give them an owner) you still have to run find(1).  However it has the huge advantage that it doesn't use find(1) so it won't be dragging the metadata for every single file and directory on the system into memory. It also has the advantage that it can check filesystems that are not mounted currently (which find(1) can't do).

It ran in about 4 seconds on a system with 300 ZFS datasets from 2 pools totalling about 3.2T of allocated space, and that includes the uid lookups and output.

#!/bin/sh

for fs in $(zfs list -H -o name -t filesystem -r rpool) ; do
        unknowns=""
        for uid in $(zfs userspace -Hipn -o name,used $fs | cut -f1); do
                if [ -z "$(getent passwd $uid)" ]; then
                        unknowns="$unknowns$uid "
                fi
        done
        if [ ! -z "$unknowns" ]; then
                mountpoint=$(zfs list -H -o mountpoint $fs)
                mounted=$(zfs list -H -o mounted $fs)
                echo "ZFS File system $fs mounted ($mounted) on $mountpoint \c"
                echo "has files owned by unknown user ids: $unknowns";
        fi
done
Sample output:

ZFS File system rpool/ROOT/solaris-30/var mounted (no) on /var has files owned by unknown user ids: 6435 33667 101
ZFS File system rpool/ROOT/solaris-32/var mounted (yes) on /var has files owned by unknown user ids: 6435 33667
ZFS File system builds/bob mounted (yes) on /builds/bob has files owned by unknown user ids: 101

Note that the above might not actually appear exactly like that in any future Solaris product or feature, it is provided just as an example of what you can do with ZFS user space accounting to answer questions like the above.

Thursday Jan 24, 2013

Compliance reporting with SCAP

In Solaris 11.1 we added the early stages of our (security) Compliance framework.  We have (like some other OS vendors) selected to use the SCAP (Security Content Automation Protocol) standard from NIST.  There are a number of different parts to SCAP but for Compliance reporting one of the important parts is the OVAL (Open Vulnerability Assesment Language) standard.  This is what allows us to write a checkable security policy and verify it against running systems.

The Solaris 11.1 repository includes the OpenSCAP tool that allows us to generate reports written in the OVAL language (as well as other things but I'm only focusing on OVAL for now).

OVAL is expressed in XML with a number of generic and OS/application specific schema.  Over time we expect to deliver various sample security policies with Solaris to help customers with Compliance reporting in various industries (eg, PCI-DSS, DISA-STIG, HIPAA).

The XML in the OVAL langauge is passed to the OpenSCAP tool for evaluation, it produces either a simple text report of which checks passed and which failed or an XML results file and an optional HTML rendered report.

Lets look at a simple example of an policy written in OVAL.  This contains just one check, that we have configured the FTP server on Solaris to display a banner.  We do this in Solaris 11 by updating /etc/proftpd.conf to add the "DisplayConnect /etc/issue" line - which is not there by default.   So in a default Solaris 11.1 system we should get a "fail" from this policy.

The OVAL for this check was generated by a tool called "Enhanced SCAP Editor (eSCAPe)" which is not included in Solaris.  It could well have been hand edited in your text editor of choice. In a later blog posting I'll attempt to explain more of the OVAL language and give some more examples, including some Solaris specific ones but for now here is the raw XML:

<?xml version="1.0" encoding="UTF-8"?>
<oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" 
xmlns:oval-def="http://oval.mitre.org/XMLSchema/oval-definitions-5" 
xmlns:independent-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-definitions-5 
   oval-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#independent 
   independent-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5 oval-common-schema.xsd">

  <generator>
    <oval:product_name>Enhanced SCAP Editor</oval:product_name>
    <oval:product_version>0.0.11</oval:product_version>
    <oval:schema_version>5.8</oval:schema_version>
    <oval:timestamp>2012-10-11T10:33:25</oval:timestamp>
  </generator>
  <!--generated.oval.base.identifier=com.oracle.solaris11-->
  <definitions>
    <definition id="oval:com.oracle.solaris11:def:840" version="1" class="compliance">
      <metadata>
        <title>Enable a Warning Banner for the FTP Service</title>
        <affected family="unix">
          <platform>Oracle Solaris 11</platform>
        </affected>
        <description>/etc/proftpd.conf contains "DisplayConnect /etc/issue"</description>
      </metadata>
      <criteria operator="AND" negate="false" comment="Single test">
        <criterion comment="/etc/proftpd.conf contains &quot;DisplayConnect /etc/issue&quot;" 
          test_ref="oval:com.oracle.solaris11:tst:8400" negate="false"/>
      </criteria>
    </definition>
  </definitions>
  <tests>
    <textfilecontent54_test 
        xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
        id="oval:com.oracle.solaris11:tst:8400" version="1" check="all" 
        comment="/etc/proftpd.conf contains &quot;DisplayConnect /etc/issue&quot;" 
        check_existence="all_exist">
      <object object_ref="oval:com.oracle.solaris11:obj:8400"/>
    </textfilecontent54_test>
  </tests>
  <objects>
    <textfilecontent54_object 
        xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
        id="oval:com.oracle.solaris11:obj:8400" version="1" 
        comment="/etc/proftpd.conf contains &quot;DisplayConnect /etc/issue&quot;">
      <path datatype="string" operation="equals">/etc</path>
      <filename datatype="string" operation="equals">proftpd.conf</filename>
      <pattern datatype="string" 
         operation="pattern match">^DisplayConnect\s/etc/issue\s$</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>
  </objects>
</oval_definitions>

We can evaluate this policy on a given host by using OpenSCAP like this:

$ oscap oval eval ftp-banner.xml 
Definition oval:com.oracle.solaris11:def:840: false
Evaluation done.

As you can see we got the expected failure of the test, but that output isn't very useful, lets instead generate some html output:

$ oscap oval eval --results results.xml --report report.html ftp-banner.xml
Definition oval:com.oracle.solaris11:def:840: false
Evaluation done.
OVAL Results are exported correctly.

Now we have a report.html file which looks like a bit like this:

OVAL Results Generator Information
Schema Version Product Name Product Version Date Time
5.8  cpe:/a:open-scap:oscap 
2013-01-24 14:18:55 
OVAL Definition Generator Information
Schema Version Product Name Product Version Date Time
5.8  Enhanced SCAP Editor  0.0.11  2012-10-11 10:33:25 

System Information
Host Name braveheart 
Operating System SunOS 
Operating System Version 11.1 
Architecture i86pc 
Interfaces
Interface Name net0 
IP Address 192.168.1.1 
MAC Address aa:bb:cc:dd:ee:ff 
OVAL System Characteristics Generator Information
Schema Version Product Name Product Version Date Time
5.8  cpe:/a:open-scap:oscap 
2013-01-24 14:18:55 
Oval Definition Results



 True  



 False  



 Error  



 Unknown  



 Not Applicable  



 Not Evaluated  
OVAL ID Result Class Reference ID Title
oval:com.oracle.solaris11:def:841 true compliance
Enable a Warning Banner for the SSH Service 
oval:com.oracle.solaris11:def:840 false compliance
Enable a Warning Banner for the FTP Service 

As you probably noticed write away the report doesn't match the OVAL I gave above because the report is actually from a very slightly larger OVAL file which checks the banner exists for both SSH and FTP.  I did this purely to cut down on the amount of raw XML above but also so the report would show both a success and failure case.


About

Darren Moffat-Oracle

Search

Categories
Archives
« August 2015
MonTueWedThuFriSatSun
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today