Re: CoBIT a Security Audit Framework?

[Jon Kibler <Jon.Kibler () aset com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J. Oquendo wrote:
<SNIP!>
> 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
tested for?

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.

THANKS!

Jon Kibler
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o: 843-849-8214
c: 843-224-2494
s: 843-564-4224
http://www.linkedin.com/in/jonrkibler

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

iEYEARECAAYFAkk0RqQACgkQUVxQRc85QlM4CwCeIoaTkQQaFlO/JAxcvZizxdem
cREAnR90lM/8LV2ww+O1Dr+WckoscUqu
=s0er
-----END PGP SIGNATURE-----




==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
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

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