Unit 3 - Design & Evaluation and Hardware Security

Question 1

What are the The eight Saltzer-Schroeder principles?

Answer 1

1. Economy of mechanism
2. Fail-safe defaults
3. Complete mediation
4. Open design
5. Leastprivilege
6. Least common mechanism
7. Separation ofprivilege
8. Ease of use

Question 2

What is the Saltzer-Schroeder Economoy of Mechanism principle?

Answer 2

The design of a protection mechanism should be as simple as possible.

Errors in design or implementation can cause vulnerabilities which may lead to incorrect granting of access to resources. These vulnerabilities may not be noticed during normal use:

• an attacker will not reportthem, because itis notin the attacker’s interest;
• an authorised user may not notice, and even if he/she does notice, he/she may not reportit to a security administrator.

In general, the simpler the mechanism, the more likely it is that errors will be detected during developmentand testing.

Question 3

What is the Saltzer-Schroeder Fail-safe defaults principle?

Answer 3

Access should be denied unless it is explicitly authorised (default deny).

That is, if no protection is specified for a resource, access should be denied. As a result of following this principle, if the mechanism has implementation errors then they are more likely to be noticed:

• fail-safe defaults will lead to incorrectdenial ofaccess to resources;
• if authorised users have valid requests denied, they are likely to bring it to the attention of the systems administrator; the opposite policy leads to false positives (bad guys gain access when they shouldn’t); the bad guys don’ttend to reportthese types of problems. Black-listing vs white-listing.

Question 4

What is the Saltzer-Schroeder Complete mediation principle?

Answer 4

Every attempt to access resources must be intercepted and evaluated by the protection mechanism.

That is, all accesses to resources must be evaluated against the access policy in force.

This is perhaps the most important principle, and forms an integral part of the definition of a reference validation mechanism (i.e. an access control mechanism) in the Orange Book.

Question 5

What is the Saltzer-Schroeder Open design principle?

Answer 5

Do not rely on ‘security by obscurity’.

That is, the strength of a protection mechanism should be independent of who knows how the mechanism works. Instead of secrecy, the strength of the mechanism should depend on the secrecy and strength of the secret values used as input to the protection mechanism, such as cryptographic keys or passwords. Users are likely to feel more confident in the quality of a protection mechanism if it has been subjectto independent scrutiny and been found to be secure.

This does not, of course, mean that all security mechanisms must be made public, although it can be argued that the user may gain greater assurance if this is the case. The pointis that security should notrely on secrecy.

Question 6

What is the Saltzer-Schroeder Least privilege principle?

Answer 6

Only give a program access toresources if it requires access.

This is a variant of the military ‘need-to-know’ principle. If an incorrect program malfunctions, or a malicious program exploits a vulnerability, then the fewer privileges ithas,the less damage it can do. This lesson is frequently forgotten by system administrators:

• unnecessary access rights are assigned to users (and are not removed when they are no longer needed);
• unnecessary programs and utilities are installed on machines (e.g., as part of a generic build) or not‘uninstalled’ from an ‘out-of-the-box’ configuration.

Question 7

What is the Saltzer-Schroeder Least common mechanism principle?

Answer 7

The use of sharedresources should be minimised.

Taken to its extreme this principle requires that each program should run on its own dedicated machine (either physically or logically distinct). Clearly such an extreme interpretation is likely to conflict with functional requirements and lead to poor resource utilisation.

Ultimately must compromise betweenefficiency and security

Question 8

What is the Saltzer-Schroeder Separation of privilege principle?

Answer 8

Wherever possible two or more independent checks should be used to confirm that a requestis authorised.

Thus wherever possible a system should use two or more security mechanisms to protecta resource. For example:

• deploy a security guard at the front door of a building and also put locks on the doors within the building;
• use two-factor authentication.

This relates closely to the notion of dual control: it should be impossible for a single user to perform a sequence of mission- or business-critical actions. For example:

• two differentgenerals must separately arm and launch a nuclear missile;
• two differentindividuals must separately authorise cheques over £5000

Question 9

What is the Saltzer-Schroeder Ease of use principle?

Answer 9

Never underestimate the unwillingness of users to interact with security mechanisms!

The human element of computer systems is probably the most significant vulnerability. For example:

• users and likely to choose poor passwords and also to manage them poorly;
• users are likely to make system configuration errors;
• ‘good’ users can be persuaded to run malicious software or do other damage to their own system.

If a security mechanism is invisible, or if it is easy to use when visible, then users are more likely to use it rather than circumvent it. On the other hand, if a security mechanism is highly intrusive,then users are likely to find ways to bypass it.

Question 10

What is the Microsoft SDL?

Answer 10

Microsoft’s Security Development Lifecycle (SDL)

This is a process that Microsoft has adopted for the development of software that needs to withstand malicious attack. It was developed as part of the Microsoft Trustworthy Computing initiative, launched in the early 2000s with the goal of addressing Microsoft’s then very poor reputation for providing reliable and trustworthy software. Some ten years on, this ongoing initiative has transformed the company’s internal software developmentpractices

Question 11

What are the microsoft SDL design phases?

Answer 11

Question 12

What is the Microsoft SDL Training phase?

Answer 12

All members of a software development team should receive appropriate training to stay informed about security basics and recenttrends in security and privacy.

Individuals who develop software (software developers or simply ‘devs’) should attend at least one security training class each year.

Security training can help ensure software is created with security and privacy in mind,and can also help developmentteams stay currenton security issues.

Project team members are strongly encouraged to seek additional security and privacy education that is appropriate to their needs or products.

SDL Practice #1: Core Security Training

This practice is a prerequisite for implementing the SDL. Foundational concepts for building better software include secure design, threat modeling, secure coding, security testing,and best practices surrounding privacy.

Question 13

What is the Microsoft SDL Requirements phase?

Answer 13

The need to consider security ‘from the ground up’ is a fundamental principle of secure system development. While many development projects produce ‘next versions’ that build on previous releases, the requirements phase and initial planning of a new release or version offers the best opportunity to build secure software. The requirements phase of the SDL includes:

• project inception: in which security and privacy are considered at a fundamental level;
• cost analysis: in which the development and support costs for improving security and privacy are compared with the business needs.

SDL Practice #2: Establish Security and Privacy Requirements

Defining and integrating security and privacy requirements early helps make it easier to identify key milestones and deliverables and minimize disruptions to plans and schedules.

SDL Practice #3: Create Quality Gates/Bug Bars

Defining minimum acceptable levels of security and privacy quality at the start helps a team understand risks associated with security issues, identify and fix security bugs during development, and apply the standards throughout the entire project.

SDL Practice #4: Perform Security and Privacy Risk Assessments

Examining software design based on costs and regulatory requirements helps a team identify which portions of a project will require threat modeling and security design reviews before release and determine the Privacy Impact Rating of a feature, product, or service.

Question 14

What is the Microsoft SDL Design phase?

Answer 14

The design phase identifies the overall requirements and structure for the software. The design phase involves building the plan for taking the project through the rest of the SDL process, including from implementation, to verification, to release.

During the design phase, the team members must:

• establish best practices that will be followed in the functional and design specifications;
• perform a risk analysis (or, in SDL terminology, ‘risk modelling’) to identify threats to, and vulnerabilities in, the software

SDL Practice #5: Establish Design Requirements

Considering security and privacy concerns early helps minimize the risk of schedule disruptions and reduce a project’s expense.

SDL Practice #6: Attack Surface Analysis/Reduction

Reducing the opportunities for attackers to exploit a potential weak spot or vulnerability requires thoroughly analyzing overall attack surface and includes disabling or restricting access to system services, applying the principle of least privilege, and employing layered defenses wherever possible.

SDL Practice #7: Use Threat Modeling

Applying a structured approach to threat scenarios during design helps a team more effectively and less expensively identify security vulnerabilities, determine risks from those threats, and establish appropriate mitigations.

Question 15

What is the Microsoft SDL Implementation phase?

Answer 15

During the implementation phase, the product team codes, tests, and integrates the software. Steps taken to remove security flaws or prevent their initial insertion during this phase have a high impact — they significantly reduce the likelihood that security vulnerabilities will make their way into the final version of the software that is released to customers.

The Implementation phase involves establishing development best practices to detect and remove security and privacy issues early in the development cycle.

Code reviews should be conducted, which supplement automated tools and tests by applying the efforts of trained developers to examine source code and detect and remove potential security vulnerabilities. They are a crucial step in the process of removing security vulnerabilities from software during the development process.

In this phase, the development team must create the documentation and tools to be used by the customer to make informed decisions about secure deploymentof the software.

SDL Practice #8: Use Approved Tools

Publishing a list of approved tools and associated security checks (such as compiler/linker options and warnings) helps automate and enforce security practices easily at a low cost. Keeping the list regularly updated means the latest tool versions are used and allows inclusion of new security analysis functionality and protections.

SDL Practice #9: Deprecate Unsafe Functions

Analyzing all project functions and APIs and banning those determined to be unsafe helps reduce potential security bugs with very little engineering cost. Specific actions include using header files, newer compilers, or code scanning tools to check code for functions on the banned list, and then replacing them with safer alternatives.

SDL Practice #10: Perform Static Analysis

Analyzing the source code prior to compile provides a scalable method of security code review and helps ensure that secure coding policies are being followed.

Question 16

What is the Microsoft SDL Verification phase?

Answer 16

The verification phase is the point at which the software is functionally complete and enters user beta testing. During this phase, while the software is undergoing beta testing, the product team conducts a “security push” that includes security code reviews beyond those completed in the implementation phase as well as focused security testing.

The verification phase involves ensuring that the code meets the security and privacy rules established in the previous phases. This involves:

• security and privacy testing,
• a security push, i.e. a team-wide focus on updating the threat model, reviewing the code, code testing, and a thorough review and edit of the system documentation.

A public release privacy review is also completed during this phase.

In this phase, security-testing tools including fuzzing tools should be applied. ‘Fuzzing’ supplies structured but invalid inputs to software application programming interfaces (APIs) and network interfaces so as to maximize the likelihood of detecting errors that may lead to software vulnerabilities. Static-analysis code scanning tools are also applied that can detect some types of coding flaws that result in vulnerabilities, including buffer overruns, integer overruns, and uninitialized variables. Microsoft has made a major investment in the development of such tools (the two that have been in longest use are known as PREfix and PREfast) and continually enhances those tools as new kinds of coding flaws and software vulnerabilities are discovered.

SDL Practice #11: Perform Dynamic Analysis

Performing run-time verification checks software functionality using tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.

SDL Practice #12: Fuzz Testing

Inducing program failure by deliberately introducing malformed or random data to an application helps reveal potential security issues prior to release while requiring modest resource investment.

SDL Practice #13: Attack Surface Review

Reviewing attack surface measurement upon code completion helps ensure that any design or implementation changes to an application or system have been taken into account, and that any new attack vectors created as a result of the changes have been reviewed and mitigated including threat models.

Question 17

What is the Microsoft SDL Release phase?

Answer 17

During the release phase, the software should be subject to a Final Security Review (FSR). The goal of the FSR is to answer one question: ‘From a security viewpoint, is this software ready to deliver to customers?’. A privacy review is also required prior to release.

During the release phase the software is prepared for public consumption, and the development team prepares for what happens once their software is in the hands of the user.

A core concept for this phase is planning, and in particular the creation of an action plan that should be followed if and when security or privacy vulnerabilities are discovered. This phase also includes the post-release period, including response execution.

SDL Practice #14: Create an Incident Response Plan

Preparing an Incident Response Plan is crucial for helping to address new threats that can emerge over time. It includes identifying appropriate security emergency contacts and establishing security servicing plans for code inherited from other groups within the organization and for licensed third-party code.

SDL Practice #15: Conduct Final Security Review

Deliberately reviewing all security activities that were performed helps ensure software release readiness. The Final Security Review (FSR) usually includes examining threat models, tools outputs, and performance against the quality gates and bug bars defined during the Requirements Phase.

SDL Practice #16: Certify Release and Archive

Certifying software prior to a release helps ensure security and privacy requirements were met. Archiving all pertinent data is essential for performing post-release servicing tasks and helps lower the long-term costs associated with sustained software engineering.

Question 18

What is the Microsoft SDL Response phase?

Answer 18

After the software has been released, the product development team must be available to respond to any security vulnerabilities or privacy issues that a sufficiently significan tto warrant a response.

In addition, the development team must develop a response plan that includes preparations for potential post-release issues.

SDL Practice #17: Execute Incident Response Plan

Being able to implement the Incident Response Plan instituted in the Release phase is essential to helping protect customers from software security or privacy vulnerabilities that emerge.

Question 19

What are the problems with SDL?

Answer 19

The SDL was designed for use with ‘boxed products’, e.g. Windows and Office, new versions of which are released only infrequently.

Use of the SDL involves a significantwork overhead and time delay.

The SDL is not suitable for products with a very short development and release cycle, e.g. software that is used to provide cloud services, which may be updated almoston a weekly basis.

Question 20

What is the purpose of evaluation criteria?

Answer 20

The main purpose of evaluation criteria is to provide a basis for independent evaluations of security products using a fixed setof criteria (requirements).

The purpose of such an evaluation is to establish a level of confidence that the security functionality of a product satisfies the criteria. Ultimately, this is intended to assist consumers of security technology in making an informed decision.

They are are also intended to help guide vendors in the development and production of security technology

Question 21

What are the general principles behind any set of security evaluation criteria?

Answer 21

The general principles behind any set of security evaluation criteria (and several sets have been defined, starting with the Orange Book and culminating in the Common Criteria) are as follows.

1. Identify the criteria against which a security product (or, more generally, a set of countermeasures) should be evaluated.
2. Identify a set of security classifications (typically this consists of an ordered sequence of security levels).
3. Evaluate the extent to which the security product being evaluated satisfies each criterion.
4. ap the extent to which the product satisfies the criteria to one of the security classifications.

Question 22

What is the Orange Book?

Answer 22

The Trusted Computer Security Evaluation Criteria (TCSEC) or the Orange Book (so named because of the covers in which the TCSEC were published) were the first set of evaluation criteria. They were published by the US Department of Defense (DoD) in the 1980s (although they reflectideas dating back to the 1960s).

They were designed for use in assisting US Government departments in purchasing security products.

The Orange Book focuses on computer systems. Subsequently published sets of evaluation criteria have broader scope (e.g. anti-virus technology, firewalls, biometrics,etc.).

Question 23

What are the Orange Book 5 control objectives?

Answer 23

• mandatory security;
• discretionary security;
• object marking;
• accountability;
• assurance.

Question 24

What is the difference between mandatory and discretionary policies?

Answer 24

A system-wide policy decrees who is allowed to have access. Policies imposed by the system are called mandatory.

We can define an owner for each resource and let the owner decree who is allowed to have access. Policies defined by the owner are called discretionary, because access control is at the discretion ofthe owner.

Question 25

What is mandatory security?

Answer 25

Security policies defined for systems that are used to process classified or other specifically categorized sensitive information must include provisions for the enforcementofmandatory access control rules.

That is, they must include a set of rules for controlling access based directly on a comparison of the individual’s clearance or authorization for the information and the classification or sensitivity designation ofthe information beingsought…

The mandatory access control rules must accurately reflect the laws, regulations, and general policies from which they are derived.

Question 26

What is discretionary security?

Answer 26

Security policies defined for systems that are used to process classified or other sensitive information must include provisions for the enforcement of discretionary access control rules.

That is, they must include a consistent set of rules for controlling and limiting access based on identified individuals who have …a need-to-know … the information.

Question 27

What is object marking in reference to the Orange Book?

Answer 27

Systems that are designed to enforce a mandatory security policy must store and preserve the integrity of classification or other sensitivity labels for all information.

Labels exported from the system must be accurate representations of the corresponding internal sensitivity labels beingexported.

Question 28

What is accountability in reference to the Orange Book?

Answer 28

Systems that are used to process … classified or other sensitive information must assure individual accountability when … a mandatory or discretionary security policy is invoked.

Furthermore, to assure accountability, the capability must exist for an authorized and competent agent to access and evaluate accountability information by a secure means,within a reasonable amountoftime, and without undue difficulty.

Question 29

What is assurance in reference to the Orange Book?

Answer 29

Systems that are used to process or handle classified or other sensitive information must be designed to guarantee correct and accurate interpretation of the security policy and mustnot distort the intent of that policy.

Assurance must be provided that correct implementation and operation of the policy exists throughout the system’s life-cycle.

Question 30

What are the 6 security requirements that the five control objectives define?

Answer 30

• Security policy;
• Marking;
• Identification;
• Accountability;
• Assurance;
• Continuous protection

Question 31

What are the Orange Book security classes?

Answer 31

This table summarises the six protection classes defined in the Orange book, ranging from D (no protection) to A (highest level of protection). The level of requirements of each type (0=no requirement) in order to obtain each classification level is indicated in the table entries. That is, the higher the number indicated, the higher the degree to which the requirement must be met in order to obtain the classification.

Question 32

What is the Common Criteria?

Answer 32

The Common Criteria (CC) extend the Orange Book, ITSEC and the US Federal Criteria:

• the US Federal Criteria were introduced by NIST and NSAin 1992 (to replace the Orange Book);
• ITSEC (Information Technology Security Evaluation Criteria) was an EU initiative that was formally endorsed in 1995;
• the CC, developed as a result of an international collaborative effort (the Common Criteria Editorial Board, or CCEB) involving the US, Europe and Asia, became internationalstandard ISO/IEC 15408 parts 1-3 in 1999.

Question 33

What does the Common Criteria provide?

Answer 33

The CC provide a set of requirements and methods for assessing the security functionality of IT products. The CC use the notions of:

• protection profile – originally introduced in the US Federal Criteria;
• target of evaluation (ToE) – originally introduced in ITSEC, i.e. the product (or, more generally,the set of functionality) being submitted for evaluation;
• evaluation assurance levels (EALs) – corresponding (roughly) to the Orange Book protection classes.

Question 34

What is Common Criteria protection profile?

Answer 34

Aprotection profile is a set of requirements designed to enable the evaluation of a security product of a particular type. Examples of categories of security product include anti-virus systems and biometric identification/authentication system,etc.).

A protection profile covers:

• threats to be addressed by product;
• security objectives ofthe features of the product;
• assumptions;
• security functional requirements (SFRs);
• security assurance requirements (SARs);
• a specific evaluation assurance level (EAL), i.e. for a particular class of products a differentprotection profile may existfor each of the EALs defined by the CC.

Question 35

What is a security target in regards to the Common Criteria?

Answer 35

A vendor of a product to be evaluated (the ToE) uses an appropriate protection profile (i.e. one matching the type of product or set of functionality being evaluated) to define a security target, which specifies the security functionality of the ToE which is to be evaluated.

The security target specifies a set of countermeasures to security threats, as provided by the ToE.

The goal of the vendor is to have the set of countermeasures certified as meeting the specificEAL associated with the protection profile.

A security target defines:

• the assets to be protected by the ToE;
• the threats to which the assets mightbe exposed;
• the security objectives for the ToE, also known as the security functional requirements (SFRs);
• the security objectives for the operational environment.

Question 36

What is a security objective in regards to the Common Criteria?

Answer 36

The security objectives for the ToE are the countermeasures for which an evaluation is sought. They are chosen by the party that defines the security target. For example:

• a vendor may wish to obtain accreditation for a product;
• a consumer may wish to obtain assurance that a product satisfies certain criteria.

Assurance about the correctness of the security objectives of the ToE (SFRs) are obtained as a result of the evaluation. Here ‘correctness’ captures a range of notions, including the appropriateness of the countermeasures in meeting the specified threats, the robustness of the chosen security measures (e.g. strength of encryption algorithm),and assurance in implementation.

The security objectives of the operational environment are not evaluated. They allow the evaluator to focus its attention on those aspects of the security target that are relevant. For example:

• if certain countermeasures are already known to be correct (e.g. because of previous evaluations) then they can be included in the operational environment;
• non-technological countermeasures always form part of the operational environment.

Assurance about the correctness of the security objectives of the operational environmentare notobtained as a resultof the evaluation.

Question 37

What are the security assurance requirements in regards to the Common Criteria?

Answer 37

The security assurance requirements (SARs) are a formal description of the activities to be undertaken to establish the correctness ofthe SFRs.

They must be specified in a standardised languagedefined by the CC.

The rationale for the SARs is to ensure exactness of evaluation, and to facilitate comparisons ofindependent evaluations of competitor products.

The main idea is that, if the SARs are satisfied, the user of the evaluation has assurance (i.e. confidence) in the correctness ofthe ToE.

In general, if one ToE satisfies all the SARs satisfied by another ToE, together with some additional SARs,then the level of assurance is higher.

If a ToE satisfies more demanding SARs than another ToE, then the level of assurance is higher

Question 38

What are the 7 Common Criteria EALs?

Answer 38

EAL1 (functionally tested)

• tests confirm the documented functionality. [This is the only level that does not have a matching level under Orange Book or ITSEC

EAL2 (structurally tested)

• the developer provides test documentation and the test results from a vulnerability analysis;
• the evaluator reviews documentation and repeats tests.

EAL3 (methodically testedand checked)

• the developer uses configuration management, and provides documentation of the design (ata high level) and ofthe security of development process.

EAL4 (methodically designed, testedand reviewed)

• the developer provides low-level design documentation and source code of the TCB;
• the evaluator performs an independent vulnerability analysis;
• EAL4 is typically the highest level that can be achieved for existing products, i.e. products not developed with evaluation in mind from the outset of the development process.

EAL5 (semi-formally designed and tested)

• there must exist a formal (mathematical) model of the security policy;
• a semi-formal high-level design and functional specification mustbe provided;
• the full source code of the security functions must be submitted for evaluation;
• the evaluator performs independent penetration testing.

EAL6 (semi-formally verifieddesignand tested)

• the product must possess well-structured source code;
• the access control implementation must have low complexity;
• it requires more intensive penetration testing by the evaluator.

EAL7 (formally verifieddesign and tested)

• requires a formal functional specification and high-level design;
• a formal analysis of the security functions must be provided.

Question 39

What is the difference between the evaluation levels of the common critieria, TCSEC (orange book) and the European ITSEC?

Answer 39