[Owasp-iso17799] Project Update [Virus checkedAU]
Bruce.Morris at au.ey.com
Bruce.Morris at au.ey.com
Mon Mar 1 16:52:27 EST 2004
This email is to be read subject to the disclaimer below.
Seemed a shame to let the opportunity pass...
In reference to the recipe analogy I thought that an extract from Baldricks
cooking BlackAdder Goes Forth was highly appropriate...
The setting is WW1 in the trenches and Baldrick has been supplying Captain
BlackAdder with his morning coffee...
>>For the past thirteen months, Baldrick's coffee has in fact been made from mud.
With dandruff as a cunning sugar >>substitute. Just don't ask what he's been
using for the milk.
Rather than take the professional approach, we can take the consulting tact and
dazzle the masses with something that looks and smells like coffee - but is
really leading edge in the herbal alternative realm - with advertsing and
training we will make the less knoweldgable believe it is coffee. Web
Application Herbal Security......
Shrubberies, get your shrubberies....(MontyPython)
OK, maybe I should invest some effort in delivering something instead of trying
to be comical.
Blackadder: 'I know from long experience all my men have the artistic talent of a
cluster of colour-blind hedgehogs in a bag.'
<rich67dev at hotm To: Bruce.Morris at au.ey.com
ail.com> cc: owasp-iso17799 at lists.sourceforge.net,
owasp-iso17799-admin at lists.sourceforge.net, samheinrich at hotmail.com
01/03/2004 Subject: RE: [Owasp-iso17799] Project Update [Virus checkedAU]
OK, I am happy...I feel happy....I feel happy. (monty python and the holy
grail ) Thought I should quote something since you did....sorry don't have
any good quotes from down under, and don't mean to offend with the English
references. (oppss, I know we have one more Brit at least, don't want to
offend you either - Oh well, why should I care since nobody really likes
Anyway, my whole gist was that we were arguing (not you and I) about
details that I thought an audit perspective might cut through. I think on
that point, we have some agreement. I also agree that we should be as
general as possible, without loosing any 'meat' in terms of security.
Afterall, the standard is an extreme generalization in and of itself in
terms of security. So, there will be interpretation. Lastly, I think we
should consider adding in the assessment peace as a sound practice -
if Stan thinks its groovy you can add this? Perhaps we should have some
of making distinct what is 'good security practices' and what is distinctly
ISO figuring for the eventuality of ISO registration being a reality and
template becomes in demand.
Food for thought, no need for response, except to quote more Python or
rich67dev at hotmail.com
>From: Bruce.Morris at au.ey.com
>To: "Rich Seiersen" <rich67dev at hotmail.com>
>CC: Bruce.Morris at au.ey.com, owasp-iso17799 at lists.sourceforge.net,
>owasp-iso17799-admin at lists.sourceforge.net, samheinrich at hotmail.com
>Subject: RE: [Owasp-iso17799] Project Update [Virus checkedAU]
>Date: Mon, 1 Mar 2004 17:27:39 +1100
>Comments in line....
>take them or leave them...
> "Rich Seiersen"
> <rich67dev at hotm To:
>Bruce.Morris at au.ey.com
> ail.com> cc:
>owasp-iso17799 at lists.sourceforge.net,
>owasp-iso17799-admin at lists.sourceforge.net, samheinrich at hotmail.com
> 01/03/2004 Subject: RE:
>[Owasp-iso17799] Project Update [Virus checkedAU]
> 04:41 PM
>Agreed with your final conclusions, nonetheless, if and when ISO
>registration becomes a reality, we shoudl not only hold true to excellence
>in terms of web app security, but sound in terms of those pursuing ISO
>registration. Would you not agree.
>To that end...I guess I will play the role of ISO town crier - as we have
>more than adequate security chops on board...;-)
> >>>an ugly passion, yet noble and who am I to point the figure at ugly?
>There is no requirement for a particular risk assessment - correct?
>10.1 does imply that 'business requirements' must be taken into
>consideration, but again, an auditor cannot force the HOW on me in terms
>how I came to my conclusions. As long as I say, the related data for this
>web app is valued at $10mill, we consider that to be pricey, thus we
>to imiplement these controls..... Is frankly adequate, it may not be GOOD,
>but if it meets the letter of the standard than we are OK. The auditor
>cannot say that we did not follow a certain methodology in terms of how we
>got our numbers etc. (well the auditor can try to say what we did is not
>- or that they think our assessement stinks, but they won't win if it is
>specifically stated within the standard). So, there would be no slap -
>correct? If, I say in my included docs that I will do a risk assessment,
>and the assessment will containt certain specific steps, and I don't
>proof that those steps occured - then the 'slap'.
> >>Correct - I think this is a major shortfall of 17799, however, I also
>prefer pink icing on the black and white cookie (ref: Seinfeld). I
>a bias of working with Govt in Australia where risk assessment is now
>expected. (We have AS/NZ4360 Risk Management which is a very good general
>risk assessment methodology if you are ever interested. A handbook comes
>with it HB231 which provides guidance for implementing the standard - it
>isn't the standard but offers suggestions for use - eg risk rating scales)
>Given that the concept here is to deliver an example for capturing the
>relevant information, I like the risk assessment as a generic tool (you
>pick your approach) to determine what is and isn't appropriate.
>If I don't do something that is specifically required by 17799, and don't
>provide a documented and acceptable reason for exclusion (which can occur
>and be valid) - then 'the slap'. So, to create a template that implies
>something that is not required via the standard must be made explicit.
>if we as a proffessional group state that a risk assessment is required,
>the assessement should follow certain steps, and we think that 10.1 is a
>fitting place to hang this assessement, then fine. But, we need to make
>clear that what we have just done is an interpretation coming from the
>of standard practices in terms of security. Again, this goes back to what
>was reffering to in terms of interpretation.
> >>>Can't disagree. Go the pink icing and call it an interpretation (it
>remains a neenish tart - in my language anyway, we followed the same
>but used different food colouring).
>Lastly, the iso standards are frameworks - correct? So, I will stick
>my push for a 'good' and 'valid' example. Good is a qualitative term,
>be forced on someone pursuing regristration, but is recommended for those
>pursuing real security in a reproducible manner.
> >>>Yep. But we aren't rewriting the standard. We are preparing a
>for guidance on a suitable application of the handbook to web application
>security management. For it to be useful, it needs to be more generalised
>than an example can be - a tool to be used and reused regardless of the
>stuff which makes it an example. Yes, I see that this is the area of
>challenge which all and sundry hit - can specify coding techniques
>specifically, because tools have few generalisations. However, with 17799
>we are referencing the policies and procedures around this so must be able
>to find some generalisation - even if they are stuff like - "get a code
>specific hardening guide".
>rich67dev at hotmail.com
> >From: Bruce.Morris at au.ey.com
> >To: "Rich Seiersen" <rich67dev at hotmail.com>
> >CC: owasp-iso17799 at lists.sourceforge.net,
> >owasp-iso17799-admin at lists.sourceforge.net, samheinrich at hotmail.com
> >Subject: RE: [Owasp-iso17799] Project Update [Virus checkedAU]
> >Date: Mon, 1 Mar 2004 15:25:30 +1100
> >My $AU0.02 - which is doing remarkably well against the US$ of late (so
> >there will probably be a significant slide following these remarks)...
> >I would suggest that A or THE valid example is not the goal so much as A
> >possibly The Valid Framework to build your own.
> >Whilst each decision is specific to a methodology, environment,
> >application, organisation, etc, etc, the underlying concern is to
> >what is appropriate to my webapp. This means building a framework to
> >the question - what is of concern to my webapp?
> >As an internal auditor (as oppose to quality auditor), you may use DES
> >because your QualProcs say so, but if you don't have a risk assessment
> >which justifies why, then I am going to slap you over the wrist,
> >if your requirements in the application have nothing to do with
> >How do I apply 17799 to web applications?
> >If the question is encryption, then the guidance I need is what do I
> >encryption for, where do I need to apply it, should I be targeting 3DES,
> >PKI or homebrew - does it matter?
> >If the question is access control, then the guidance I need is what
> >controls do I need, where should I put them, how do I maintain them,
> >it matter? What business requirements or decisions will likely
> >these bits?
> >With personnel security, what are my options for confidentiality
> >and t&c where the user is not someone I engage with except online.
> >I be considering digital signatures on CTAs and when is this
> >What limitations are there with online registration of users that I
> >be aware of?
> >I believe these questions drive through the process of design,
> >implement, maintain, etc and are not restricted within the confines of
> >ongoing operation.
> >As you have rightly stated anyone can build a set of ISO procs and abide
> >them for a total value of nought. This process should be to move beyond
> >that, and in the spirit of OWASP (as I have understood so far) move
> >delivering knowledge which promotes and instills better practice more
> >broadly and systemically .
Watch high-quality video with fast playback at MSN Video. Free!
NOTICE - This communication contains information which is confidential and
the copyright of Ernst & Young or a third party.
If you are not the intended recipient of this communication please delete
and destroy all copies and telephone Ernst & Young on 1800 655 717
immediately. If you are the intended recipient of this communication you
should not copy, disclose or distribute this communication without the
authority of Ernst & Young.
Any views expressed in this Communication are those of the individual
sender, except where the sender specifically states them to be the views of
Ernst & Young.
Except as required at law, Ernst & Young does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained nor
that the communication is free of errors, virus, interception or
Liability limited by the Accountants Scheme, approved under the
Professional Standards Act 1994 (NSW)
More information about the Owasp-iso17799