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
