mailing list archives
Re: CoBIT a Security Audit Framework?
From: Jon Kibler <Jon.Kibler () aset com>
Date: Mon, 01 Dec 2008 15:18:44 -0500
-----BEGIN PGP SIGNED MESSAGE-----
J. Oquendo wrote:
PS: I'm an ISACA member so perhaps that could be seen as
somewhat of "biased" approach however, for those who know
me, know I could literally care less about certs, or who
is saying what, I call it how I see it. I've seen CoBIT,
OCTAVE and others in play and I've also seen how many
fall short, if there is a reason a company wants to be
compliant with the CoBIT framework, there is legitimacy
behind it not to mention the framework is built with a
business oriented focus first.
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?
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?
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
How is CoBIT going to tell me if an organization has correctly
implemented IPSec? I have seen so many organizations that have said "We
have IPSec and the auditors have verified that." only to be able to
sniff all network traffic in clear text. Why, because someone simply
checked a box on an audit sheet that says "IPSec enabled" without
verifying it was PROPERLY enabled. ("We enabled IPSec using all the
defaults -- no authentication, no encryption. We now have IPSec, so we
must have good network security!")
Now lets take DR, one of the areas CoBIT is heavy on. How does CoBIT
verify that a DR plan has been properly and adequately tested? I have
seen organizations that get a 'perfect DR' on a Big-8 IT audit, only to
fall flat on their faces when they go to try to actually execute their
DR plan under emergency conditions. Why? Because the audit/auditors did
not know how to properly verify that the DR plan was adequate and that
it had been properly tested.
The other big issue I have with so many of the people doing CoBIT (and
similar) audits, is that they haven't even 0.001% of a clue where to
know where to look for buried skeletons. Here is a perfect example: I
had a client about 5 years ago that had just been through a Big-8 CoBIT
audit. The only thing they were faulted on was using telnet to manage
their PBX. The auditor didn't even ask about how credit card information
was used by the organization -- it was stored in clear text, along with
all the identifying information (name, address, tel#, SSN, etc.) for
clients, and stored three times that way: in a flat file (one file per
client), in a DB2 database, and on backup tapes (including unencrypted
offsite tapes). The auditor had also given them a pass on not having
modems that provided access behind the firewall (auditor found no
modems); however, I immediately spotted a "modem" that the auditor
probably did not even know to look for -- on their big (room sized)
multifunction printer/scanner/high speed copier, which was running W2K
completely unpatched with PCAnywhere answering the phone number it was
connected to, and PCAnywhere had no login or password required (full
network access on an unpatched W2K box!). I know the framework is not to
blame here, but the perception is "all is well because CoBIT says so" is
what REALLY bothers me here!
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.
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Filtered by: TRUSTEM.COM's Email Filtering Service
No Spam. No Viruses. Just Good Clean Email.
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