Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Computer Security Technology Planning Study (1972) [pdf] (dtic.mil)
26 points by wglb on Dec 23, 2022 | hide | past | favorite | 8 comments


For more about what happened next, see Steve Lipner's "The Birth and Death of the Orange Book":

https://www.stevelipner.org/links/resources/The%2520Birth%25...


Sounds interesting, but the link is dead : (



Thanks!


What comes after the Orange Book is then the international Common Criteria standard [1][2] as mentioned toward the end of that article. The Common Criteria consists of Protection Profiles (PP) which specify a qualitative feature set (Security Functional Requirements, SFR) and a validation/assurance process (Security Assurance Requirements, SAR). Of note is the AVA_VAN [3] SAR which constitutes a vulnerability analysis. There are then Evaluation Assurance Levels (EAL) which go between 1-7 which are common groupings of SARs that are believed to correspond to a generally higher level of assurance [4].

Class C2 in the Orange Book is then basically transplanted into the Common Criteria as the Controlled Access Protection Profile (CAPP) evaluated at EAL4 [5] which must demonstrate "resistance to penetration attackers with an Enhanced-Basic attack potential. (AVA_VAN.3)". Class B3 and A1, which are designed for multiple levels of security (MLS, e.g. Having SECRET and TOP SECRET data on the same system) is largely transplanted as the Separation Kernel Protection Profile (SKPP) evaluated at EAL6 [6] which must demonstrate "resistance to penetration attackers with a high attack potential. (AVA_VAN.5)". I do not believe there is a transplanted protection profile corresponding to Class B1 or B2, but given the above I think we can safely assume that it would be a protection profile evaluated at EAL5 which must demonstrate "resistance to penetration attackers with a moderate attack potential. (AVA_VAN.4)".

Class C2 certified systems, such as Windows and Unix, and the organizations that produced them continued to only be able to certify at the corresponding level, EAL4 ("resistance to penetration attackers with a Enhanced-Basic attack potential"). Their repeated utter failure to certify any higher for so many decades is such that even the standard itself declares that "EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line.[7]" Higher levels are functionally impossible to achieve with systems that were insecure by design without a total rewrite.

However, at that time, there was increasing pressure to use commercial off-the-shelf (COTS) software for usage in high security systems. Those systems were only able to demonstrate low security properties and were unable to meet the minimum security requirements. So, in order to allow the large, politically active, commercial vendors to submit successful bids that do not immediately fail due to being unable to meet the mandatory security requirements, official government guidance was changed to allow any system certified to EAL4 to be used. This then turned out to be too onerous for security vendors such as firewall and antivirus vendors, so the standard was subsequently reduced to EAL2 which must only demonstrate "resistance to penetration attackers with a basic attack potential. (AVA_VAN.2)". To where we are now, where the only requirement is that the system be validated as PP-compliant, which means it conforms to a protection profile, of which all of them currently certified against are only designed to achieve EAL1+ (+ meaning it contains some SARs from higher EAL levels without comprehensively incorporating all of them).

To see how absolutely atrocious this is [8]: "EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. ... It is sufficient to simple state the required security functional requirements (SFRs) for the TOE, rather than deriving them from threats, organizational security policies (OSPs) and assumptions through security objectives. ... It is intended that an EAL1 evaluation can be successfully conducted without assistance from the developer of the TOE, and for minimal outlay." It is certified against AVA_VAN.1 which demonstrates "resistance to penetration attackers with a basic attack potential", but no independent vulnerability analysis is done, only a survey of vulnerabilities is done. If you look at the certifications being done, this amounts to doing a web search of: "Are there any unpatched vulnerabilities in product {x}?" and if the answer is no they get the rubber stamp.

So, that is where we stand now. Systems only need to demonstrate self-graded resistance to attackers with a basic attack potential. And that is why everything is horrendously insecure, it is certified to be horrendously insecure right there on the packaging.

[1] https://www.commoncriteriaportal.org/

[2] https://www.commoncriteriaportal.org/cc/

[3] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 153

[4] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 11

[5] https://en.wikipedia.org/wiki/Controlled_Access_Protection_P...

[6] https://www.niap-ccevs.org/profile/Info.cfm?PPID=65&id=65

[7] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 18

[8] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 14


Folks interested in this may like the page "B2 Security Evaluation" at https://multicians.org/b2.html.

It looks at the Multics OS secuirty experience, and has pointers to the document titling this thread, which we called the "Anderson Report", and Steve's paper, as well as related documents including the Ware Report, MITRE theory papers, and conference papers. It also describes what Multics did to get the B2 rating and what we learned.


https://www.semanticscholar.org/paper/Computer-Security-Tech...

csrc.nist.gov/publications/history/ande72.pdf


They're on to us... ERR_CONNECTION_RESET




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: