[Owasp-iso17799] Project Update [Virus checkedAU]

Bruce.Morris at au.ey.com Bruce.Morris at au.ey.com
Mon Mar 1 01:27:39 EST 2004

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 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 handbook
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
>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 access
>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.  Should
>I be considering digital signatures on CTAs and when is this appropriate?
>What limitations are there with online registration of users that I should
>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 .

More information about the Owasp-iso17799 mailing list