[Infrastructures] sarbanes-oxley

[Steve Traugott]

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 15, 2005 at 12:14:07PM -0800, Eric Sorenson wrote:
> On Tue, 15 Mar 2005, Steve Traugott wrote:
> > An accurate summary is hard to define because the legislation is new,
> > with implications more complex than the law itself, most of which are
> > not fully understood by anyone, because it's anyone's guess how auditors
> > and courts are going to interpret much of it.  Google for it -- there's
> > a copy of the act at http://www.law.uc.edu/CCL/SOact/toc.html, and lots
> > of pundit interpretations everywhere, many of which disagree with each
> > other.
>=20
> For this pundit's interpretation, from having done a crapload of SOX
> work (and a successful audit, I might add), read the posts here:
>         http://eric.explosive.net/policy/index.html

Those are good posts.

> The most important thing to keep in mind is this: the scope of SOX=20
> controls is within your power to define. Everything that is directly=20
> related to company financials is within scope, any IT functions which=20
> are directly and solely in support of financial functions are within=20
> scope, and the rest of your infrastructure is a gray area that is open=20
> to interpretation.  For example, we were able to argue that since=20
> there were adequate access controls in place to prevent non-finance=20
> people from accessing finance-related data, mandatory password change=20
> controls should not be applied to engineering staff. The relative=20
> strength or age of their passwords were immaterial to SOX scope=20
> because their user account had no access to the relevant data. =20

This is developing into a pretty standard approach -- firewall finance
and the executive suite from the rest of the company to some degree.
Where I've seen it go wrong is that it can create two IT groups, with
islands of infrastructure that don't talk well to each other; the HQ
island trends towards Windows and vendorware, doesn't have much native
IT skillset, is more vulnerable to FUD, and yet is still in a position
to dictate IT policy for the rest of the company (the CIO sits in the HQ
island, after all).  So the policies which get promulgated make even
less sense than usual.  I've already seen this effect cause departures
and great harm to morale in one otherwise promising pre-IPO company.

AFS might help here because it's a network filesystem that provides
ACLs, strong authentication, and other controls -- you can safely host
HQ and the rest of the company in the same cell, and can demonstrate
that they can't get at each other's data.  This means that any AFS
admin, and anyone else with physical or root access to the AFS servers,
ought to be SOX-aware and auditable, but I think you wind up with a much
healthier and more productive company overall.

> Be really, really cautious about vendors selling SOX-related products,=20
> consultants insisting that you implement sweeping changes across the=20
> enterprise, and people (myself included!) spreading FUD about what you=20
> as a sysadmin should or should not be doing for compliance.=20

Ditto.  ;-) =20

Steve
--=20
Stephen G. Traugott  (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org=20
http://www.stevegt.com -- http://Infrastructures.Org

--2oS5YaxWCcQjTEyO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCOoxn8rKIxO1Fc9MRAliaAJ9dd4h01xWtDQ/JKBjv5JiIHEzGEQCeOljF
AmSihEXTQSLRGK9Mhj6UvfA=
=KPdf
-----END PGP SIGNATURE-----

--2oS5YaxWCcQjTEyO--