hello, wow. salamat naman at may mga ganitong discussions. really helpful. medyo nakakahilo lang. :D
On Wed, Nov 5, 2008 at 4:47 PM, Drexx Laggui [personal] <[EMAIL PROTECTED]> wrote: > 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 > -- edel _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
