Yeah, really helpful and educational. As a linux hobbyist with an interest in security I was wondering if it's possible to tag along on your engagements? Do you have informal gatherings we noobs can attend?
http://wehavedayjobs.blogspot.com --- On Wed, 11/5/08, Edel SM <[EMAIL PROTECTED]> wrote: > From: Edel SM <[EMAIL PROTECTED]> > Subject: Re: [plug] Common Criteria and OWASP > To: "Philippine Linux Users' Group (PLUG) Technical Discussion List" > <[email protected]> > Date: Wednesday, November 5, 2008, 11:55 AM > 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 _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
