[WEB SECURITY] About Sarbanes-Oxley

Albert caruabertu at gmail.com
Wed Jul 5 04:28:11 EDT 2006


SOX and similar laws back and forth,

minimum standards for web app security are hampered by a lack of standard
solutions and engineering norms, making it nearly impossible to define a
generic minimum security standard;

various guides do exist, each of which heroically attempts to address the
ordering of webappsec chaos:

the OWASP guide is about as good as you can get

WASC. ISECOM's OSSTMM etc… all work towards the common goal

the German BSI e-government security handbook helps:

it understandably heavily uses the BSI "baseline security manual" concepts;
the NIST guide helps:

and integrates nicely with the extensive documentation of NIST on security;

the UK e-gov manual helps:

OASIS standards help:

the Australian Government security handbook has some sections on some
webappsec standards: http://www.dsd.gov.au/library/infosec/acsi33.html

but... they all give what looks like a "one size fits all" solution and thus
must be infinitely variable depending on the risk level, business need and
implementation detail.

The web application situation in my eyes can be compared to the pioneering
era of horseless carriage manufacture - every car was hand-made by a
different engineer using different ideas, tools and traditions and
thus every car was different, used different parts –

A car therefore broke down often, was unsafe to drive, was extremely
expensive to run and maintain, etc...

Every engineering team claimed that theirs was the best solution.

e.g. Who remembers the impossible to overturn, world leader in fuel
efficiency: http://www.citroenet.org.uk/panhard-et-levassor/panhard-05.html

Compare that level of cost (vs. average salary), variety and (lack of)
reliability with the safe, cheap, fuel efficient, wind-canal-styled,
air-bagged and seat-belted, air-filtered and air-conditioned, automatic
braking-system and automatic traction control equipped, standardized *and
almost identical* cars today.

Identity theft, lack of user-acceptable  easy-to-use systems for
registration, authentication and authorization over interlinked distributed
complex service clusters etc... are all well publicized in newsgroups such
as this.

what appears obvious is thus a need for something designed with quality, and
thus security and reliability, in mind:
-          a different standardized client and server interface for
e-services, e-commerce and e-government
-          a set of methods to be able to test for the security of the
resulting product

and to spice it a bit it should

= >      have interfaces to currently used terminals/clients of any kind
via: "public internet", cell phones, TV sets, VOIP and possibly

= >      function reliably in spite of failure of/attack on one or more


--- begin forwarded message ---


First, you need to understand if you need to comply with SOX at all.

If you're not a publicly traded US firm or have significant US

interests, it simply does not apply to you.

SOX is very simple: the directors of the firm must state at least

once per year "our financial records are true and accurate" and have

adequate -financial- controls in place to prevent another Enron. This

is usually process driven; it shouldn't be possible for one person to

place the entire company in jeopardy through deliberate fraud or


SOX compliance surrounding financial systems is only true when a

comprehensive Information Security program is in place -around-

financial and other core business systems (ie if you're a company

like Amazon, your GL and your logistics software must be protected.

If you're like an ISP then the GL and the systems which allow you to

enrol and service customers to prevent significant churn must be

protected). As every company is different, there is no One True Way

or one set of machines to protect.

Most folks end up adopting COBIT as it's reasonably comprehensive. Be

prepared to spend some serious $$$$$$ for your average firm

investigating and implementing the risk based controls. It's not just

picking up the control framework and pointing at it when the auditors

come through.

WebAppSec standards are few and far between. I put in mappings to

relevant COBIT sections in the Guide 2.0 as I was going through

exactly the same thing last year, so probably the OWASP Guide 2.0 is

your best bet if your web apps are directly relevant to the bottom

line of your firm. If your web apps are brochureware, it's unlikely

you need to remediate them for SOX "compliance".



On 04/07/2006, at 12:43 AM, sender at ms25.url.com.tw wrote:

> Dear folks,


> What kind of standards for web application security could help me

> to comply with Sarbanes-Oxley?


> Thanks a lot.


> --

> http://mymailer.url.com.tw

> 台灣最物超所值的大眾化虛擬郵件主機



> ----------------------------------------------------------------------

> ------

> The Web Security Mailing List:

> http://www.webappsec.org/lists/websecurity/


> The Web Security Mailing List Archives:

> http://www.webappsec.org/lists/websecurity/archive/

> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060705/78197c7c/attachment.html>

More information about the websecurity mailing list