Re: CoBIT a Security Audit Framework?

["J. Oquendo" <sil () infiltrated net>]

On Mon, 01 Dec 2008, Jon Kibler wrote:

> Okay, then please explain to me how an organization would use CoBIT as
> the framework for doing a penetration test. Also, for a penetration
> test, how is CoBIT better/more complete/etc than OSSTMM?

I believe I expanded on this on my follow up, apologies for not doing
so then.

> CoBIT, IMHO is a *POLICY* audit -- and I believe that your list of CoBIT
>  framework security modules verifies that -- so, how is a POLICY based
> framework supposed to be used to pen test or otherwise VERIFY the actual
> FUNCTIONING of an organization's security?

It's meant to give you a guideline. Let's take OSSTMM out of the
equation right now. If I told you that our forward facing web
server needed to meet compliance based off of the principals
in CoBIT's framework, you would do what? Look at what CoBIT is
concerned with, then tailor your testing to adhere to this.

> How is CoBIT going to tell me whether an intruder will be detected by
> the organization or that they even have the processes in place to detect
> intrusion (and I do not mean "we have an IDS, so therefore we can detect
> intrusions" -- don't make me laugh here!)? Where does CoBIT specify how
> to test for such capabilities or even that such capabilities should be
> tested for?

How is OSSTMM going to tell you similarly whether an intruder will
be detected. OSSTMM is based off of end user experience summed up
into a best practice. Again, apples and oranges. While CoBIT will
point out the need for certain technologies, you're taking the
wrong approach. So base your testing off of experience, not a
framework.

I hire you and tell you I need to adhere to X_Principle, if you can't
ensure I meet X_Principle, then I really don't care to do business
with you, that's reality and the bottom line. However, if you showed
me that your testing methodology can meet or beat me, I would be
the idiot not to listen don't you think?

Apologies for chopping down what I want to answer, but some of this
is trivial at best to me.

> I do not understand how you can say that CoBIT can verify (test) any
> aspect of security beyond security policy. Especially, how it can be
> used as the framework for a pen test? Please explain.

I'm sorry, where in my original or any subsequent response did I state
CoBIT can verify? 


Let me repost my follow up perhaps you didn't get it:


----- Forwarded message from "J. Oquendo" <sil () infiltrated net> -----

Date: Mon, 1 Dec 2008 13:52:13 -0600
From: "J. Oquendo" <sil () infiltrated net>
To: Jon Kibler <Jon.Kibler () aset com>
Cc: pen-test () securityfocus com
Subject: Re: CoBIT a Security Audit Framework?

On Mon, 01 Dec 2008, Jon Kibler wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> <rant>
>
> And what REALLY gets me is that organizations expect you to be able to
> do a PEN TEST using CoBIT! When I explain that something like OSSTMM is
> a more correct framework for a PEN TEST (or even NIST 800-115 or
> 800-53A), they don't want to hear it -- its gotta be CoBIT! They have so
> many misunderstandings as to what CoBIT is and is not useful for, it is
> incredible -- and they are not interested in learning anything different.
>
> Who / what is driving this "CoBIT is the only acceptable IT Security
> audit framework" mentality and what can we do to change it?
>
> </rant>


I should have been a little more clear on my initial post so
apologies for the second email on this. You're comparing
apples and oranges here. ISECOM's OSSTMM framework is great
for the penetration tester and for the testing methodologies
used, especially for the verification purposes however it is
solely a pentesting framework. Your client is probably under-
clued with the differences and wants to maintain CoBIT
compliance, keeping in tune with the checks and balances of
CoBIT's framework.

If you have the modules' information, they correlate them
for your client on how you will match them up so they can
understand the difference in your testing and how it maps
into the CoBIT framework. In either case of whatever a
company is choosing, there will be overlap, there will be
one over the other, but the bottom line for those asking
for it is likely a need to maintain compliance with the
CoBIT framework. It is a lot more than meets the eye and
is well structured on the information security scale to
both macro and micro manage many portions of security
frameworks.

Irrespective of the testing methodologies used, there is
one end result and its this result that is likely what
your client is worried about. Cobit maps most of the
given frameworks and models and exceeds a lot of them,
when you understand it a little better, you'll likely
see the disconnect in someone asking for a pentest to
help make sure the company is CoBIT compliant:

Search ISACA for the term mapping it will give you a
clearer picture of the mappings and overlap with the
following:

ITIL, CMM, ISO 17799, PMBOK, PRINCE2, NIST SP800-53, TOGAF



=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP

"Each player must accept the cards life deals him
or her: but once they are in hand, he or she alone
must decide how to play the cards in order to win
the game." Voltaire

227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E


------------------------------------------------------------------------
This list is sponsored by: Cenzic

Security Trends Report from Cenzic
Stay Ahead of the Hacker Curve!
Get the latest Q2 2008 Trends Report now

www.cenzic.com/landing/trends-report
------------------------------------------------------------------------