Other Work

  1. Security Flaw Taxonomies
    1. Protection Analysis (PA) Taxonomy (1978)
    2. The Research in Secured Operating Systems (RISOS) security taxonomy (1976)
    3. Spafford’s taxonomy (1992)
    4. Bishop’s taxonomy (1995)
    5. Du and Mathur’s taxonomy (1997)
    6. Brian Marick Survey (1990) and Chillarege's Orthogonal Defect Classification
    7. Jiwnani and Zelkowitz's taxonomy
    8. Landwehr’s taxonomy (1994)
    9. Aslam’s taxonomy (1995)
  2. Earlier Work on Principles
    1. Orange Book
    2. Saltzer and Schroeder
    3. NSA Principles Of Secure Design
    4. GASSP
    5. Common Criteria
    6. Neumann et. al. (2003)

Security Flaw Taxonomies

Protection Analysis (PA) Taxonomy (1978)

Bisbey, R. and D. Hollingsworth, “Protection Analysis Project
Final Report,” Information Sciences Institute, University of Southern
California, Marina Del Rey, CA, 1978.

The Research in Secured Operating Systems (RISOS) security taxonomy (1976)

R. P. Abbott et al, “Security Analysis and Enhancements of
Computer Operating Systems,” Report NBSIR 76-1041, Institute for
Computer Science and Technology, Natl. Bur. of Stnds, 1976.

Spafford’s taxonomy (1992)

Eugene H. Spafford, “Common System Vulnerabilities,”
Proceedings of the Workshop on Future Directions in Computer
Misuse and Anomaly Detection pp. 34-37, 1992.


Bishop’s taxonomy (1995)

M. Bishop, “A Taxonomy of UNIX System and Network
Vulnerabilities,” Technical Report CSE-95-10, Purdue University,
May 1995.

Du and Mathur’s taxonomy (1997)

Wenliang Du and Aditya P. Mathur, “Categorization of Software
Errors that led to Security Breaches,” In Proceeding of the 21st
National Information Systems Security Conference (NISSC’98),
Crystal City, VA, 1998.

Brian Marick Survey (1990) and Chillarege's Orthogonal Defect Classification

Brian Marick, “A survey of software fault surveys,” Technical
Report UIUCDCS-R-90-1651, University of Illinois at Urbana-
Champaign, December 1990.

Jiwnani and Zelkowitz's taxonomy

Development Issues
  1. Validation Errors (for input and output)
  2. Domain Errors (exposure of internal data across domain boundaries)
  3. Serialization or aliasing errors (race conditions, TOCTTOU, and access to internal objects by other threads or domains)
  4. Errors due to Inadequate Identification or Authentication
  5. Boundary and Condition Errors (e.g. buffer overflow, range errors)
  6. Trojan Horse (explicitly provides useful service but secretly performs malicious actions)
  7. Covert Channel (use of alegitimate program mechanism to transfer information in an unintended or unforeseen manner across a domain boundary)
  8. Exploitable Logic Errors (anything else)

Location
  1. System Initialization (incorrect establishment or configuration of intended protection domains)
  2. Memory Management
  3. Process Management or Scheduling
  4. Device Management (hijacking and range vulnerabilities)
  5. File Management (any file system vulnerabilities)
  6. Identification or Authentication

Impact
  1. Unauthorized Access
  2. Inappropriately obtaining root privilege or privilege in violation of secuity policy.
  3. Denial of Service (delay or prevention of access by legitimate users)
  4. Integrity Failure (revelation of internal system information)
  5. Crash, Hang, or Exit
  6. Causation of failure
  7. Causation of invalid State that is not permitted
  8. File Manipulations (by an unauthorized user or program)
  9. Errors due to clock changes


Landwehr’s taxonomy (1994)

C. E. Landwehr, A. R. Bull, J. P. McDermott, and W. S. Choi,
“A taxonomy of computer program security flaws,” ACM Computing
Surveys, Vol. 26 (3), pp. 211-254, 1994.

Intentional
Malicious (Trojan Horse, Trapdoor, Logic Bomb)
Non-malicious (covert channel, other)
Inadvertent
Validation Error                     (?)
Domain Error                    (?)
Serialization (including TOCTTOU errors)      
Authentication inadequate                (?)
Boundary condition violation (including buffer overflow)
Other exploitable logic error            (?)
Items marked with (?) are not descriptive. They describe the manifestation of errors, not  genesis of errors.
It is for this reason that there are research work on detecting TOCTTOU and buffer overflow errors, but not on other errors.


Aslam’s taxonomy (1995)

T. Aslam, “A taxonomy of Security Faults in the Unix
Operating System,” M.S. Thesis, Purdue University, 1995.

1. Operational fault (configuration error)
1a. Object installed with incorrect permissions       
1b. Utility installed in the wrong place
1c. Utility installed with incorrect setup parameters
2. Environment fault
3. Coding fault
3a. Condition validation error
3a1. Failure to handle exceptions
3a2. Input validation error
3a3. Origin validation error
3a4. Access rights validation error
3a5. Boundary condition error
3b. Synchronization error
3b1. Improper or inadequate serialization error
3b2. Race condition error


Earlier Work on Principles

There has been a tremendous amount of work done in the area of defining secure design principles. Some of the more notable milestones in this work are summarized here. This summary is by no means comprehensive.

      1. Orange Book

The most frequently-referenced source with regard to secure design principles is undoubtedly the “Orange Book”. [ref. NCSC. Department of Defense Trusted Computer System Evaluation Criteria (TCSEC). National Computer Security Center, December 1985. DOD-5200.28-STD, Orange Book.] The Orange Book delineated a set of fundamental concepts, practices and design principles for the design of secure software.

The Orange Book led to other work, but continues to this day to be a referenced standard.

      1. Saltzer and Schroeder

Another often-referenced early source is Saltzer and Schroeder. [J.H. Saltzer and M.D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278-1308, September 1975.] This work stemmed from work on the famous “Multics” system. [verify] See http://www.multicians.org).

Summarized: Saltzer-Schroeder Practices

The Saltzer-Schroeder practices can be summarized as follows:

  • Simplicity

  • Secure defaults

  • Complete mediation

  • Open design

  • Separation of privilege

  • Least privilege

  • Least common mechanism

  • Usability

  • Balance risk with security

  • Indelible traceability



      1. NSA Principles Of Secure Design

Another widely references source for secure design principles is the NSA Principles Of Secure System Design. [ref. P. Boudra, Jr. Report on rules of system composition: Principles of secure system design. Technical report, National Security Agency, Information Systems Security Organization, Office of Infosec Systems Engineering, I9 Technical Report 1-93, Library No. S-240, 330, March 1993. For Official Use Only.]


Summarized: NSA Principles Of Secure Design Summarized

The principles can be summarized as follows:

  • The security engineering of a system must not be done independently from the total engineering of the system.

  • A system without requirements cannot fail; it merely presents surprises.

  • The system is for the users and not the system designers.

  • A systems seldom fully satisfies all of its requirements.

  • Many failures of a system to meet its overall requirements are often obvious. However, failures to meet security requirements are often not obvious.

  • In an operational system, it is the users' mission and information that is at risk, not the developers' or evaluators' information. The accreditor accepts those risks when deciding to use a system operationally.

  • It is only in the context of a system and a security policy that the "security characteristics" of a component can be defined and evaluated.

  • Every component in a system must operate in an environment that is a subset of its specified environment; [in particular,] every component in a system must operate in a security environment that is a subset of its specified security environment. (A component should not be asked to respond to events for which it was not designed -- and evaluated.)

  • Security is a system problem.

  • Keep it simple to make it secure.

  • There is no security in uncertainty.

  • A system should be evaluatable and evaluated.

  • Architectural analysis should not be treated lightly.

  • A system is only as strong as its weakest link; the fortress walls of security should all be high enough. (Note that weak links are often not obvious.)

  • A component should protect itself from other components by adhering to the principle of mutual suspicion.

  • A system should be manageable and managed.

  • A system should be able to come up in a recognizably secure state.

  • A system should recognize error conditions.

  • Pay special attention to information flow.

  • Secure systems should protect the confidentiality of user data.

  • Secure systems should protect the integrity of user data.

  • Secure systems should protect the reliability of user processes.



      1. GASSP

The International Information Security Foundation (I2SF) has attempted to develop a comprehensive set of secure design principles and developed the Generally Accepted Systems Security Principles (GASSP). [ref. W. Ozier. GASSP: Generally Accepted Systems Security Principles. Technical report, International Information Security Foundation, June 1997. (http://web.mit.edu/security/www/gassp1.html).] This work is currently incomplete.


Summarized: GASSP Principles Summarized

These principles define the following categories:

Pervasive Principles

  • Accountability

  • Awareness

  • Ethics

  • Multidisciplinary

  • Proportionality

  • Integration

  • Timeliness

  • Assessment

  • Equity

Broad Functional Principles

  • Information Security

  • Education and Awareness

  • Accountability

  • Information Management

  • Environmental Management

  • Personnel Qualifications

  • System Integrity

  • Information Systems Life Cycle

  • Access Control

  • Operational Continuity and Contingency Planning

  • Information Risk Management

  • BNetwork and Infrastructure Security

  • Legal, Regulatory, and Contractual Requirements of Info Security

  • Ethical Practices



      1. Common Criteria

The International Standards Organization developed the Common Criteria for Information Technology Security Evaluation, currently in version 2.1.

[Ref. ISO 15408. ISO/NIST/CCIB, 19 September 2000.

(http://csrc.nist.gov/cc)

([http://www.commoncriteria.org)

]

Summarized: Common Criteria

Common Criteria defines these technical (“functional”) evaluation categories:

  1. Class FAU: Security audit

    • Security audit automatic response (FAU_ARP)

    • Security audit data generation (FAU_GEN)

    • Security audit analysis (FAU_SAA)

    • Security audit review (FAU_SAR)

    • Security audit event selection (FAU_SEL)

    • Security audit event storage (FAU_STG)

  2. Class FCO: Communication

    • Non-repudiation of origin (FCO_NRO)

    • Non-repudiation of receipt (FCO_NRR)

  3. Class FCS: Cryptographic support

    • Cryptographic key management (FCS_CKM)

    • Cryptographic operation (FCS_COP)

  1. Class FDP: User data protection

    • Access control policy (FDP_ACC)

    • Access control functions (FDP_ACF)

    • Data authentication (FDP_DAU)

    • Export to outside TSF control (FDP_ETC)

    • Information flow control policy (FDP_IFC)

    • Information flow control functions (FDP_IFF)

    • Import from outside TSF control (FDP_ITC)

    • Internal TOE transfer (FDP_ITT)

    • Residual information protection (FDP_RIP)

    • Rollback (FDP_ROL)

    • Stored data integrity (FDP_SDI)

    • Inter-TSF user data confidentiality transfer protection (FDP_UCT)

    • Inter-TSF user data integrity transfer protection (FDP_UIT)

  1. Class FIA: Identification and authentication

    • Authentication failures (FIA_AFL)

    • User attribute definition (FIA_ATD)

    • Specification of secrets (FIA_SOS)

    • User authentication (FIA_UAU)

    • User identification (FIA_UID)

    • User-subject binding (FIA_USB)

  2. Class FMT: Security management

    • Management of functions in TSF (FMT_MOF)

    • Management of security attributes (FMT_MSA)

    • Management of TSF data (FMT_MTD)

    • Revocation (FMT_REV)

    • Security attribute expiration (FMT_SAE)

    • Security management roles (FMT_SMR)

  1. Class FPR: Privacy

    • Anonymity (FPR_ANO)

    • Pseudonymity (FPR_PSE)

    • Unlinkability (FPR_UNL)

    • Unobservability (FPR_UNO)

  1. Class FPT: Protection of the TSF

    • Underlying abstract machine test (FPT_AMT)

    • Fail secure (FPT_FLS)

    • Availability of exported TSF data (FPT_ITA)

    • Confidentiality of exported TSF data (FPT_ITC)

    • Integrity of exported TSF data (FPT_ITI)

    • Internal TOE TSF data transfer (FPT_ITT)

    • TSF physical protection (FPT_PHP)

    • Trusted recovery (FPT_RCV)

    • Replay detection (FPT_RPL)

    • Reference mediation (FPT_RVM)

    • Domain separation (FPT_SEP)

    • State synchrony protocol (FPT_SSP)

    • Time stamps (FPT_STM)

    • Inter-TSF TSF data consistency (FPT_TDC)

    • Internal TOE TSF data replication consistency (FPT_TRC)

    • TSF self test (FPT_TST)

  2. Class FRU: Resource utilisation

    • Fault tolerance (FRU_FLT)

    • Priority of service (FRU_PRS)

    • Resource allocation (FRU_RSA)

  1. Class FTA: TOE Access

    • Limitation on scope of selectable attributes (FTA_LSA)

    • Limitation on multiple concurrent sessions (FTA_MCS)

    • Session locking (FTA_SSL)

    • TOE access banners (FTA_TAB)

    • TOE access history (FTA_TAH)

    • TOE session establishment (FTA_TSE)

  2. Class FTP: Trusted path/channels

    • Inter-TSF trusted channel (FTP_ITC)

    • Trusted path (FTP_TRP)


Terms:

“TOE” = “Target Of Evaluation”

“TSF” = “TOE Security Functions”



The Common Criteria is comprehensive in that it not only addresses the technical aspects of security (which are listed above), but also addresses lifecycle processes that impact security, such as configuration management, operation, testing, and vulnerability assessment.

Many organizations have endorsed the Common Criteria, such as BITS, the Banking Industry Technology Services arm of the Financial Services Roundtable, a major banking industry group. At this time mostly security products have been CC certified, such as secure operating systems, routers, firewalls, etc. There is no reason why the process could not be applied to an end-use application. In fact, it makes sense to have important applications certified, because certification establishes a security goal instead of merely saying that it “should be secure”. Indeed, the providers of important applications do their customers a disservice by not certifying their applications, because without certification there is no concrete and credible promise of the use of best practices with regard to security.

CC defines seven levels of certification, with the lowest representing a minimum level and the seventh level representing a highly secure system whose design has been formally proven and which implement stringent lifecycle processes in a secure manner. Most security products that have been CC-certified have been certified at level 4, which requires a review of the design.

      1. Neumann et. al. (2003)

Peter Neumann has been a major contributor to the science of secure computing architectures and methodologies. A recent research report published by SRI with Peter Neumann as principal investigator [ref. Principled Assuredly Trustworthy Composable Architectures First-Year Interim Report and Working Draft of the Final Report, Jan. 8, 2003; Peter G. Neumann, Principal Investigator; Principal Scientist, Computer Science Laboratory; SRI International EL-243, 333 Ravenswood Ave, Menlo Park, California 94025-3493, USA] lists a set of secure design principles, which are repeated in the Technical Details table.

Summarized: Neumann’s Principles

Neumann’s principles are summarized here and interpreted in terms of their relationship to secure design:

Sound architecture. A well-planned system archiecture provides “enormous” benefits for system robustness, and by implication security. This applies to a system’s internal design as well as to its external interfaces, and to a lesser degree its internal interfaces.

Minimization of what must be trustworthy. Separate a system into components that must be trustworthy and others that do not require the same high level of trust. That permits attention to be focused where it add the most to overall security, in recognition of the fact that it is too expensive to make every component completely secure.

Abstraction. Design abstraction and a layered design add to the clarity of a system’s design and by implication enhance confidence in the security of that design.

Encapsulation. Encapsulation enhances abstraction and by implication enhances confidence in the security of a design.

Modularity. (Highly paraphrased.) Modularity provides loose coupling and clear definition of system components, and therefore enhances overall design clarify. That loose coupling makes it more likely that security of the overall system can be inferred from the security of its independent parts, since internal dependencies are reduced or eliminated.

Layered and distributed protection. Each resource layer within a system should emply a security model that is meaningful for that layer. A single perimeter is less effective than mulitple perimeters centered on each kind of resource.

Constrained dependency. Keep track of what information has been authenticated and what has not, and make trust determinations accordingly.

Object orientation. OO’s endorsement of abstraction, encapsulation, modularity, type safety, and other features promote many of the principles espoused above; but OO principles must be applied in a safe manner.

Separation of policy & mechanism. Authorization policy should not be inextricably tied to (e.g. embedded in) an implementation. Despite this, policy models must be thought of during design and not be added after the design is complete.

Separation of duties. Define distinct non-overlapping responsbilities with regard to use of the system. These can then become the basis of the definition of roles.

Separation of roles. Role correspond to sets of privileges defined in a particular domain, and should correspond to responsibilities (“duties”) within that domain.

Separation of domains. Separation of domains enables the separation of privilege and compartmentalization of distinct sets of resources.

Sound authentication. All elements of a system should have a known level of trust, based either on authentication or on some authenticated or otherwise secure mechanism of deployment or runtime verification.

Sound authorization and access control. Authorization should be granular and matched to the semantic capabilities of the resource that is being protected. Authorization should be non-subvertible. Authorization relies on trustworthy (e.g. authenticated) inputs.

Administrative controllability. Administration functions must not be so burdensome or complex that the risk of incorrect administrative maintenance becomes significant.

Comprehensive accountability. Monitoring, auditing, and response (e.g. intrusion detection) systems are extremely important, but must be designed with consideration for their own security and confidentiality.