On 09/18/2012 12:36 PM, Ed Flecko wrote:
I have State and Federal regulators that want me to PROVE (since their
only used to looking at Micro$oft servers) my OBSD 5.1 server is up to
date, and there are no outstanding patches that need to be applied.
*I* know that's the case, because I follow the "patch" branch, but how
do I show (i.e., something I could print for them would be best) them
my system is up to date and that all patches have been applied???
Thank you,
Ed
I believe it's a matter of process. Show them you have the check,
update and upgrade process documented, including building both userland
and kernel as two steps of ONE process, and then, the date of the kernel
should show the date updates were last applied. Now, if the kernel date
is newer than the most recent patch, you should be set.
"What if there's only a userland issue?" well, you still follow YOUR
PROCESS, building a new kernel and userland, and then you can follow the
same process to show that yes, your system is up to date. On modern hw,
that's easier and faster than documenting why a bug impacting tetris(6)
isn't an issue on your firewall.
There are other ways to do things, but as I understand it, the trick is
you have a process documented (and that implies, you follow it). i.e.,
weekly, check errataXX.html for updates...if there are any, kick off the
build cycle and then a reboot.
You want a process you (and someone else) can and do follow...maybe you
follow the mail lists, so you might get advanced warning before your
weekly check, but your /process/ is to check weekly, and you do that.
The idea is, if you get hit by a bus, your successor grabs the book and
knows how to maintain the system to the documented level of security.
i.e., if you check on Fridays and a fatal issue comes up on Tuesday, you
know your maximum window of vulnerability.
However, you have to talk to your auditor to make sure whatever you are
doing is appropriate for your regulatory environment...
