05Nov2008 (UTC +8) Magandang araw po muli!
On 11/5/08, Christian Masancay <[EMAIL PROTECTED]> wrote: > Good afternoon, > > Hi Drexx, I'm not actually new with Common Criteria. I just don't deal > with this standard on an everyday basis..=) I went back to some of my previous e-mails and *I'm sorry* that I have only begun to realize that I've been too passionate about OWASP and Common Criteria :) I just believe that both these two are important to making the Internet a better place, yet so *misunderstood* that it's disregarded by many (ignorance is bliss?) --and I got triggered. Hindi naman kasi talaga madaling tanggapin ng marami ang CC, pero pasalamat naman ako na medyo sinuwerte ng kaunti nuong nasa Check Point Software Tech ako, as the engineer working on VPN-1/Firewall-1 para tanggapin ng Singapore government... kasama ko dati si Alex Ragen sa trabaho at siya ang project lead namin. Took us about a year to do it each time. Ngayon naman ay nag-umpisa (on academic level, at least) ako with fellow CC consultants in Modi'in (Israel) at San Luis Obispo (Ca, USA) to merge both OWASP and Common Criteria as practice, and then later publish STs for common web applications as an open-source document. We're doing this only on our free time only though. Closer to home, I've presented using Common Criteria to some government offices and their commissioners (pro bono pa nga eh, para lang may mangyari) but sadly, it's one of the controls that is first dropped just so they can "meet deadlines". It seems auditing source code (even if developed in-house), is not a recognized issue here. It's a nice-to-have daw, pero hindi daw importante. <sigh!> I guess that at the root of this, risk is a poorly understood abstract. [...] > About the statement ""Trust, but verify." Which as a side note, is the > paradigm that IT auditors subscribe to.", I'm not sure where you got > this statement, but this is not true. I have been with the > IT/Financial controls and assurance practice for quite awhile and > believe me, there has always been emphasis on being "independent in > mind and in appearance" and part of this is maintaining professional > skepticism in any type of assurance or attestation engagements.[...] I read this with interest, as well as everything you wrote in support of this. "Trust, but verify" comes from the realization that IT auditors are involved only after IT systems have been put in place already. IT auditors are not involved in the SDLC until after all things are all set and done. However, IT auditors *maybe* consulted (only) by the developers in the early stages of the SDLC, for the developers to ask what audit-related controls they need to be in the IT system. IT auditors ideally are only involved after the SDLC so as to maintain their professional and organization independence. Am I mistaken in this? The concept is that end-users "trust" the new IT system first, *before* IT auditors come in to "verify" that the required information security controls are in place. Thus, "trust, but verify." > There is no such thing as "Trust" in the auditing profession except in > the following context - "The auditor must maintain an attitude of > professional skepticism concurrently with a working level of Trust > during the course of the audit.". True that. The context of "trust" here however, is about the trustworthiness of information assets --"trust" being a measure of the comfort level, or assurance, that an IT system will do what it's supposed to do: no more, no less. > Anyway, it's nice to have these discussions and sharing valuable > perspectives regarding various topics. Thanks, Drexx. Pleasure is all mine, kind sir :) > On Wed, Nov 5, 2008 at 1:24 AM, Drexx Laggui [personal] <[EMAIL PROTECTED]> > wrote: > >> 04Nov2008 (UTC +8) >> >> Hiya Cris! >> >> I'm glad you got us going in this conversation, for it's a good >> opportunity to create more awareness about OWASP and Common Criteria >> (i.e. ISO/IEC 15408). I guess you and I believe that, like the >> business requirements being documented during an SDLC's Systems >> Analysis and Design phase, security requirements should also be >> formally recognized and addressed at that early stage. >> >> Let me help clarify some misconceptions that I think I see here, and >> help ease everybody's acceptance of both Common Criteria (also >> referred to as ISO/IEC 15408) and OWASP at the *same* time. Because if >> developers did their thing correct the first time, the world (e.g. >> Internet) would be a much less chaotic place to be in. >> >> >> On 11/4/08, Christian Masancay <[EMAIL PROTECTED]> wrote: >> [...] >>> Although I believe that the Common Criteria is overkill for this or >>> may even be irrelevant >> >> I don't fault you for thinking that, it's a common impression for >> anyone new at this. Did you know you can write a Security Target in >> the morning, that is designed to achieve only EAL1 (Evaluation and >> Assurance Level 1), and be done with the test project before the end >> of the day? I didn't know that either, but that was 10 years ago. >> >> EAL1 is basically just getting the hardware or software through some >> functional testing (example, user interfaces work as mentioned in the >> brochures), then comparing the developer's high-level description (of >> the hardware or software) to a prepared high-level checklist by an >> auditor. >> >> As you can see, EAL1 is pretty much *useless*. There is very little >> assurance to be gained in that exercise. EAL3 or EAL4, are the least >> levels that a hardware / software user should be concerned about to >> get that level of comfort required before trust can be given, but also >> without costing too much during the hardware / software development. >> >> EAL7 is the highest level, but as you say, maybe overkill for a >> typical web application. >> >> >> As for the relevance of Common Criteria and OWASP to a web >> application, there is plenty. What the OWASP Guide actually provides, >> as what you mention below, are SFRs (Security Functional Requirements) >> in Common Criteria parlance... or in simpler English, SFRs are >> information security features of a hardware or software product that >> enable it to protect *itself* from threats. >> >> For example, the strong authentication required for mission-critical >> web applications, or the controls used to protect against SQL >> injection, or the error-handling & logging features of the software, >> are all SFRs... which must be tested to verify for correctness in >> implementation and thus get the assurance and trustworthiness >> required. >> >> Yes, that's right, the underlying principle of the Common Criteria is: >> "Verify, then trust". (Not the other way around, like the popular >> saying that is attributed to Ronald Reagan: "Trust, but verify." Which >> as a side note, is the paradigm that IT auditors subscribe to.) >> >>> (At the bottom of my silly mind, the TOE is not >>> even a security product), >> >> Au contraire, but it is. The TOE (Target Of Evaluation) is the >> hardware or software itself. Or, for a more definitive example using >> the previous case, the TOE refers to the *set* of SFR's coded in the >> web application (that has the Joomla CMS in it). >> >> >> Just to clarify: The "IT security product" that the Common Criteria >> refers to in its thick and boring documentation is practically any >> hardware or software, whether commercial or a one-time custom web >> application. An "IT security product" is something that can provide >> information security features (or controls, in auditor linggo) either >> for its environment (like firewalls and intrusion detection systems), >> or for itself (like O/S'es, or database systems, or other kinds of >> applications). >> >>> you can surely try to audit your >>> implementation based on that standard..=) >> >> Yes, that will be ideal :) >> >>> Maybe having a defined PP, >>> SFRs, ST, plus a nice level of confidence/QA (SARs and EAL) would be >>> ok..just kidding, I think I know what you mean...=) >> >> It'll be more than ok, because it's required. A PP (Protection >> Profile) or an ST (Security Target) are both essential because well, >> no auditor can audit anything without having a documented basis for >> the audit undertaking. >> >> PPs and STs are the same in that both are central documents that >> describe the evaluation process, defines the security features (SFRs) >> of the application, the threats it is subject to, the security >> objectives that gives it reason for being, the environment which the >> application is used, the Security Assurance Requirements (SARs) to >> give the end-user the confidence that the evaluated application is >> exactly the same thing that was audited, and the targeted EAL >> (Evaluation Assurance Level). >> >> The only difference between a PP and an ST, is that a PP is usually >> written by a vendor or the developer, while an ST is written by an >> end-user who needs a solution for their sensitive information assets. >> (To put it differently, an ST can be put out in an RFP (Request For >> Proposals) but the document is organized like how the Common Criteria >> says it should be.) >> >> >> By the way, what do you mean by "QA"? I don't understand that term, >> nor does it exist in any definitions by Common Criteria, ISO/IEC 15408 >> and 18045. If you mean Quality Assurance, then it's another subject >> matter. Strictly speaking, EAL != QA. >> >>> Aside from the OWASP Development Guide as guidance, you can also >>> suggest the OWASP Testing Guide >>> http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents >>> to your customers for conducting tests/audits to validate their >>> remediation implementation on their web applications. >> Drexx Laggui -- CISA, CISSP, CFE Associate, ISO27001 LA, CCSI, CSA http://www.laggui.com ( Singapore / Manila / California ) Computer forensics; Penetration testing; QMS & ISMS developers; K-Transfer PGP fingerprint = 6E62 A089 E3EA 1B93 BFB4 8363 FFEC 3976 FF31 8A4E _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
