Question on ISACA

[chandra at list.org (Pravir Chandra)]

For SAMM, each level for each security practice has an 'Objective'
that I tried to write in a way that would allow it to double as a
'Control Statement' in an audit context. So, hopefully, SAMM is fairly
auditor friendly since you could use the deliverables produced by each
of the underlying Activities to demonstrate evidence for meeting the
Control Statement.

Also, Nick Coblentz produced a SAMM interview checklist that includes
a list of 'Assertions' that are being made by answering yes to the
questions on the SAMM assessment worksheets. Those might also be
useful from and audit perspective. For those that haven't seen it, the
link to Nick's interview template is:
http://nickcoblentz.blogspot.com/2009/06/samm-inteview-template-version-10.html

Does that address the goals of audit tie-ins or were folks looking for
something more explicit? There's always opportunities to add it to the
next SAMM version if its useful :)

p.


On 11/4/09, McGovern, James F. (eBusiness)
<James.McGovern at thehartford.com> wrote:
> Eoin, I think your take on SAMM is interesting. I think the difference
> is not to look for evidence but to measure against controls. Auditors
> use the notion of controls to figure out good vs bad and is less fluid /
> abstract that simply seeking evidence. I wonder if Pravir or others that
> thought about expanding SAMM to include audit language.
>
> ________________________________
>
> From: owasp-leaders-bounces at lists.owasp.org
> [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Eoin
> Sent: Wednesday, November 04, 2009 11:07 AM
> To: owasp-leaders at lists.owasp.org
> Cc: sc-l at securecoding.org
> Subject: Re: [Owasp-leaders] Question on ISACA
>
>
> Re understanding what secure codeing is:
>
> Taking a look at the OWASP development guides and Code review guide is a
> start: The intro sections cover what a secure SDLC whould look like etc.
> Looking at SAMM can indicate what is required also by examining the
> domains and mapping onto the SDLC
>
> Re auditing: (it's not just secure coding, its the whole kahuna)
>
> Evidence of developer training is a good start
>
> Evidence Secure coding guidelines are nice to see, event better if they
> have a review history (looked used!).
> A generic secure application development policy could be used which can
> be linked to technolofy specific guidelines
>
> Evidence of review and adherence to them.
>
> Evidence of negative testing, negative use cases anti patterns & threat
> modeling
>
> but there is more.......
>
>
>
>
>
>
>
>
>
> 2009/11/4 McGovern, James F. (eBusiness)
> <James.McGovern at thehartford.com>
>
>
>       John Morency of Gartner just finished giving a presentation to
> our IT executives and one of the observations is that IT auditors have
> zero clue as to how to audit a secure coding practice. IT audit right
> now is limited to simply looking at "control" documents and viewing
> things through the lens of "infrastructure". Is there something we as a
> community should be doing to make auditors smarter?
>
>       ************************************************************
>       This communication, including attachments, is for the exclusive
> use of addressee and may contain proprietary, confidential and/or
> privileged information.  If you are not the intended recipient, any use,
> copying, disclosure, dissemination or distribution is strictly
> prohibited.  If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this communication and
> destroy all copies.
>       ************************************************************
>
>       _______________________________________________
>       OWASP-Leaders mailing list
>       OWASP-Leaders at lists.owasp.org
>       https://lists.owasp.org/mailman/listinfo/owasp-leaders
>       
>       
>
>
>
>
> --
> Eoin Keary
>
> OWASP Code Review Guide Lead Author
> OWASP Ireland Chapter Lead
> OWASP Global Committee Member (Industry)
>
> http://asg.ie/
> https://twitter.com/EoinKeary
>
> ************************************************************
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential and/or privileged
> information.  If you are not the intended recipient, any use, copying,
> disclosure, dissemination or distribution is strictly prohibited.  If you
> are not the intended recipient, please notify the sender immediately by
> return e-mail, delete this communication and destroy all copies.
> ************************************************************


-- 
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~ ~~~ ~~ ~
Pravir Chandra                      chandra<at>list<dot>org
PGP:    CE60 0E10 9207 7290 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~~~~~ ~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~