Licensed as:
GNU General Public License 2.0
My interpertation of SOX Compliance as it relates to Linux in the business environment is as follows:
All users, hardware, software, transactions and processes must be identified and accounted for.
Sally creates a cron job on a backend SQL server
... [More]
, that purges a temporary table nightly.
Sally's cron job is linked to Sally.
The server running the cron job is identified.
The cron jobs and SQL procedure that purge the data are documentated with the business needs. Who requested it and why.
The data that is purged is backed up prior to purging and locatable offline if needed.
Server 'x' has services / programs that run automatically when booted. Each of these services is documentated with its business needs and audited.
Server 'y' has ports open that accept incoming connections, these services are documented with their business needs and audited.
User accounts, group accounts and password policies are audited to be sure only those authorized access, have access and passwords are expired and changed periodicaly.
Installed software applications are audited and documentated with business requirments.
Software patches are documentated and audited.
Server 'z' has 600 Red Hat RPM's installed. RPM's are updated regulary by administrators this must be documentated and audited.
Do all servers have the same versions of Sendmail?
These IT thorns can create turmoil or provide opportunity of IT professionals to finally get the time and resources they need to make life easier.
With SOX Section 404, IT can slow down and really look at their environment and create policies and practices that may at first seem stupid , difficult and time consuming. But
in the long run these changes will make administration of Linux environments much easier and cleaner.
Because of the SOX compliance push at my company I was able to create a central database that holds all users, groups, cron jobs, rpms, services and applications running on all linux servers. Each morning a collector runs which checks each server and update the database. I can tell you which servers have which version of libc++, which users have cron jobs and who needs to change their password. The collection process takes about 15 minutes. I also have nagios monitoring everything every minute, and cacti with RRDTool building historical trend databases each minute. I can tell you how many users, what processes and the system load on a server 7 months ago at exactly 3:42am.
Imagine having to check thousands of servers and compile this sort of information.
Currently I have the following ruby scripts:
CronAudit (audits /etc/crontab and /var/spool/cron)
UserAudit (audits /etc/passwd, /etc/shadow and /etc/group)
RPMAudit (audits all system rpm's)
RCAudit (includes /etc/init.d/ rc scripts and xinetd managed processes)
MySQL Database Structure
The above scripts run from one central server and require:
Net::SSH
http://rubyforge.org/projects/net-ssh/
Ruby/DBI
http://rubyforge.org/projects/ruby-dbi/ [Less]