[WEB SECURITY] About Sarbanes-Oxley
Albert
caruabertu at gmail.com
Wed Jul 5 04:28:11 EDT 2006
Yep,
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:
http://www.bsi.bund.de/english/themes/egov/6_en.htm
it understandably heavily uses the BSI "baseline security manual" concepts;
the NIST guide helps:
http://csrc.nist.gov/pcig/STIGs/application-services-stig-v1r1.pdf
and integrates nicely with the extensive documentation of NIST on security;
the UK e-gov manual helps:
http://www.govtalk.gov.uk/documents/security_v4.pdf
OASIS standards help:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
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
also PSTN/ISDN/POTS
= > function reliably in spite of failure of/attack on one or more
components.
+++++++++++++++++++++++++
--- begin forwarded message ---
Generally,
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
mistakes.
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".
thanks,
Andrew
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