[Owasp-iso17799] Project Update [Virus checkedAU]

Rich Seiersen rich67dev at hotmail.com
Mon Mar 1 01:47:20 EST 2004

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 
American's anyway).

Anyway, my whole gist was that we were arguing (not you and I) about certain 
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 - perhaps 
if Stan thinks its groovy you can add this?  Perhaps we should have some way 
of making distinct what is 'good security practices' and what is distinctly 
ISO figuring for the eventuality of ISO registration being a reality and the 
template becomes in demand.

Food for thought, no need for response, except to quote more Python or 


Richard Seiersen
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.
> >>>definitely.
>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 of
>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 reflect
>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.  So,
>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 it
>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 recipe
>but used different food colouring).
>Lastly, the iso standards are frameworks - correct?   So, I will stick with
>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".
>Best Regards,
>Richard Seiersen
>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
> >confidentiality.
> >
> >How do I apply 17799 to web applications?
> >If the question is encryption, then the guidance I need is what do I need
> >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, does
> >it matter?  What business requirements or decisions will likely influence
> >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 appropriate?
> >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 .
> >
> >Cheers
> >
> >

Watch high-quality video with fast playback at MSN Video. Free! 

More information about the Owasp-iso17799 mailing list