Good afternoon, Hi Drexx, I'm not actually new with Common Criteria. I just don't deal with this standard on an everyday basis..=) Yup, I agree with you that a TOE is not necessarily a security-related product, but a system offering a certain level of security features. I meant "Quality Assurance" and it is not in the common criteria definition. I'm referring to "QA Processes" by which we obtain the "reasonable level of confidence/assurance" on the SFRs in the STs of the TOE under evaluation. The SARs should be incorporated on these "QA" processes (this is documented in the PP and ST). This is similar to how financial/IT auditors test the design and operating effectiveness of technical/business "controls" (security features of the TOE in infosec parlance) to gain reasonable assurance or a certain level of reliance that the controls are working effectively as designed over the period of reliance (normally one calendar year).
Common Criteria gives a reasonable amount of flexibility in the requirements specification, implementation, and evaluation process. Similar TOEs may be evaluate on a different set of criteria depending on the specified security requirements, what features the vendor has actually implemented on the product, and which of these features a certifying body (a laboratory) may evaluate to validate the vendor's marketing stuff..=) 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. You can ask any auditor from any auditing firm including anyone from the big four about what "professional skepticism" means to them. It's defined in the standards issued by the International Federation of Accountants (IFAC) which were the same standards adopted here in the Philippines. I still remember this when I took my oath as a Certified Public Accountant (CPA): "(a) Independence of mind--the state of mind that permits the provision of an opinion without being affected by influences that impair professional judgment, allowing an individual to act with integrity, and exercise objectivity and professional skepticism and (b) Independence in appearance--the avoidance of facts and circumstances that are so significant that a reasonable and informed third party, having knowledge of all relevant information, would reasonably conclude a firm's, or a member of the assurance team's, integrity, objectivity or professional skepticism had been unacceptably impaired." It's also included in the ISACA IS Auditing Standards if you have the Certified Information Systems Auditor (CISA) certification (incidentally, we both have this certification): "IS Auditing Standard - Irregularities and Illegal Acts - S9 - 04 The IS auditor should maintain an attitude of professional skepticism during the audit, recognising the possibility that material misstatements due to irregularities and illegal acts could exist, irrespective of his/her evaluation of the risk of irregularities and illegal acts." 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.". Anyway, it's nice to have these discussions and sharing valuable perspectives regarding various topics. Thanks, Drexx. -- Sincerely yours, Cris 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. > > > Hope this helps ! > > > > 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 > _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
