[Discuss] Logging question for SOX compliance

scottmarydavidsam at gmail.com scottmarydavidsam at gmail.com
Thu Sep 22 06:49:17 EDT 2011


For the most part, we are where you describe (formalized process including
TRAC ticketing, Subversion code control, QA testing) except that being a
small company with relatively few changes, we don't have a seperate release
engineering group, alternate developers perfom that task. In any event, the
problem I'm trying to solve is that the auditors require evidence showing
who copied what to the production server. Evidence being defined as system
generated logs or reports.

Changing the process down the road might be an option but for now I'm simply
looking to capture info about file transfer activity.

On Wed, Sep 21, 2011 at 3:17 PM, Dan Ritter <dsr at tao.merseine.nu> wrote:

>  On Wed, Sep 21, 2011 at 02:24:00PM -0400, scottmarydavidsam at gmail.comwrote:
> > I've got a Open SUSE Linux v10.0 server which we use as a web front end
> to
> > an inhouse billing application. Code changes to the application are
> > implemented over an SSH connection.
> >
> > I'm looking for a way to monitor and log who copied which files up to the
> > server. Since we're not running an FTP service, there's no FTP log.
> >
> > Any thoughts or suggestions?
>
> Yes: don't do that.
>
> Require a source code versioning system in development; branch that
> for releases; have a formal build process feeding into QA and perhaps a
> beta for acceptance, and have your release engineers be the only group
> allowed to push to production.  Automate everything possible.
> Move to a system like puppet or chef or tuttle or ... where
> deployment is formalized, automated and reversible.
>
> Oh, and document each version's changes.
>
>
>
> -dsr-
>
> --
> http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.
> You can't fight for freedom by taking away rights.
>



More information about the Discuss mailing list