No more hiding in the server room
PCI Compliance and Red Hat's backporting policy
For anyone not familiar with the problem; Red Hat use a practice called back porting for ensuring security fixes are applied to software, without also changing the functionality of the software.
And they describe how and why they do that at http://www.redhat.com/security/updates/backporting/?sc_cid=3093
This has many advantages when trying to provide a stable (as in unchanging) platform for developing on and makes it easy for a SysAdmin to manage security updates.
However, it causes a big head ache when it comes to meeting PCI Compliance and other security audits that rely solely on version numbers to check for vulnerabilites.
Today I got a PCI Compliance failure for one item: running OpenSSH v3.9.
The report listed all entries from the CVE List from the National Vulnerability Database related to openssh since this version was released.
It then asserted that therefore we are vulnerable to each of those issues.
It only took a few minutes to go check each CVE number against the Red Hat Errata to make sure a security fix was made, and then to check my logs to make sure each patch was applied in a timely manner.
Everything is fine and security fixes for all reported vulnerabilities had been applied.
Fine.
So how to move forward?
Do I download the source from OpenSSH.org and build my own rpm?
In the future I will likely need to do this for PHP, apache, BIND, etc... so I should probably set up my own repository so I can roll this out to all servers.
I would have to justify the time and associated cost of doing this for one customer, so are there other benefits I can roll in with this?
Or, do I try to reason with the security testers?
Or, what?
This problem wont go away. All software provided by Red Hat has "wrong" version numbers and I am not the only person running a Red Hat server required to meet PCI compliance.
So if this affects you, what is your story and how did you handle this?
As Linux SysAdmins, can we determine a best practice approach to working with these security testing companies.
And they describe how and why they do that at http://www.redhat.com/security/updates/backporting/?sc_cid=3093
This has many advantages when trying to provide a stable (as in unchanging) platform for developing on and makes it easy for a SysAdmin to manage security updates.
However, it causes a big head ache when it comes to meeting PCI Compliance and other security audits that rely solely on version numbers to check for vulnerabilites.
Today I got a PCI Compliance failure for one item: running OpenSSH v3.9.
The report listed all entries from the CVE List from the National Vulnerability Database related to openssh since this version was released.
It then asserted that therefore we are vulnerable to each of those issues.
It only took a few minutes to go check each CVE number against the Red Hat Errata to make sure a security fix was made, and then to check my logs to make sure each patch was applied in a timely manner.
Everything is fine and security fixes for all reported vulnerabilities had been applied.
Fine.
So how to move forward?
Do I download the source from OpenSSH.org and build my own rpm?
In the future I will likely need to do this for PHP, apache, BIND, etc... so I should probably set up my own repository so I can roll this out to all servers.
I would have to justify the time and associated cost of doing this for one customer, so are there other benefits I can roll in with this?
Or, do I try to reason with the security testers?
Or, what?
This problem wont go away. All software provided by Red Hat has "wrong" version numbers and I am not the only person running a Red Hat server required to meet PCI compliance.
So if this affects you, what is your story and how did you handle this?
As Linux SysAdmins, can we determine a best practice approach to working with these security testing companies.
Views: 278
Replies to This Discussion
-
Permalink Reply by Ryan Beta on -
I came across this same thing recently and it was a tempest in a teapot.
Our contracted security firm scanned our Red Hat EL 5.5 SFTP server and issued a site certification fail with a severity 9 because our server was running OpenSSH 4.3p2. They sent us a list of CVEs that describe the vulnerabilities in the unpatched version from 2006-2008.
I had to explain the back porting process to them and send them links to the CVEs on RH's website that stated the issues were not applicable or had been fixed. I am amazed that they have not encountered this before and seemed to be unaware of back porting.
Ultimately, I sent them a screenshot of the output of these commands and it was enough to get the severity lowered.
rpm -qa | grep openssh-server
rpm -q --changelog openssh | grep CVE
FYI, you can lookup CVEs here
http://www.redhat.com/security/data/cve/
-
Permalink Reply by Richard Holloway on -
Sounds like you handle it in the same way as me; by reasoning with the tester.
I did it by cross referencing the CVE number against the Red Hat Errata and then checked each update had been applied in /var/log/yum.log and sending the relevant entries in an email.
I must confess I didn't know about the changelog switch to rpm which clearly will speed up the amount of time to aggregate the information so thanks for posting this Ryan.
© 2012 Created by Elizabeth Ayer and Michael Francis.
Powered by
