Security Specification Flashcards

1
Q

What is meant by Security Specification?

A

Meaning: A security specification is a set of guidelines that outline how to implement security measures to protect data and ensure confidentiality and integrity.

Note: In common with safety requirements specification – concern is to avoid something bad
happening.

Four Major Differences:
1. Safety problems are accidental – the software is not operating in a hostile environment. In security, you must assume that attackers have knowledge of system weaknesses.

  1. When safety failures occur, you can look for the root cause or weakness that led to the failure. When failure results from a deliberate attack, the attacker may conceal the cause of the failure.
  2. Shutting down a system can avoid a safety-related failure. Causing a shut down may be the aim of an attack.
  3. Safety-related events are not generated from an intelligent adversary. An attacker can probe defences over time to discover weaknesses.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is meant by Security Policy?

A

Meaning: A document that applies to all systems and sets out what should and should not be allowed.

For example, a military policy might be:
* Readers may only examine documents whose classification is the same as or below the readers vetting/security level.

  • A security policy sets out the conditions that must be maintained by a security system and so helps identify system security requirements.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Name and Describe each part of the security risk assessment process? (8 parts)

A

Asset Identification:
Identify the key system assets (or services) that have to be protected.

Asset Value assessment:
Estimate the value of the identified assets.

Exposure Assessment:
Assess the potential losses associated with each asset.

Threat Identification:
Identify the most probable threats to the system assets.

Attack Assessment:
Decompose threats into possible attacks on the system and the ways that these may occur.

Control Identification:
Propose the controls that may be put in place to protect an asset.

Feasibility Assessment:
Assess the technical feasibility and cost of the controls.

Security Requirements Definition:
Security requirements can be infrastructure or application system requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Note on Software Dependability?

A
  • Software customers expect all software to be dependable.
  • However, for non-critical applications, they may be willing to accept some system failures.
  • Some critical systems have very high dependability requirements and special software engineering techniques may be used to achieve this.
    • Medical systems
    • Telecommunications and power
      systems
    • Aerospace systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are the three key areas to achieving software dependability?

A

Fault Avoidance:
- The system is developed in such a way that human error is avoided and thus system faults are minimised.
- The development process is organised so that faults in the system are detected and repaired
before delivery to the customer.

Fault Detection:
- Verification and validation techniques are used to discover and remove faults in a system before it is deployed.

Fault Tolerance:
- The system is designed so that faults in the delivered software do not result in system failure

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Note / Recap on Regulation

A
  • Many critical systems are regulated systems, which means that their use must be approved by an external regulator before the systems go into service.
    • Nuclear systems
    • Air traffic control systems
    • Medical devices
  • A safety and dependability case has to be approved by the regulator. Therefore, critical systems development has to create the evidence to convince a regulator that the system is dependable, safe and secure.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Why can’t we always trust software dependability cases?

A

Economical or technological reasons might make a manufacturer interested
in the software slightly deviating from its main objective.

Example: Volkswagen’s exhaust emission scandal, etc.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is meant by Redundancy and Diversity in relation to dependability.

A

Redundancy:
Meaning: Keep more than 1 version of a critical component available so that if one fails then
a backup is available.

Diversity:
Meaning: Provide the same functionality in different ways so that they will not all fail in the
same way.

Note: diversity adds complexity – more chance of errors.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

An example of Diversity and Redundancy examples

A
  • Redundancy
    • Where availability is critical (e.g.
      in e-commerce systems),
      companies normally keep backup
      servers and switch to these
      automatically if failure occurs.
  • Diversity
    • To provide resilience against
      external attacks, different servers
      may be implemented using
      different operating systems (e.g.
      Windows and Linux)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What is meant by a dependable process?

A

Meaning: A well-defined, repeatable processes that can be carried out by different people.

Note: To ensure a minimal number of software faults, it is important to have a well-defined, repeatable software process.

Note: A well-defined repeatable process is one that does not depend entirely on individual skills; rather can be enacted by different people.

Note: Regulators use information about the process to check if good software engineering practice has been used.

Note: For fault detection, it is clear that the process activities should include significant effort devoted to verification and validation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Name and Describe each attribute attribute of dependable processes?

A

Documentable:
* There should be a defined process model that sets out the process activities and the documentation that is to be produced during
these activities.

Standardised:
* There should be a defined process model that sets out the process activities and the documentation that is to be produced during
these activities.

Auditable:
* The process should be understandable by people apart from process participants, who can check that process standards are being
followed and make suggestions for process improvement.

Diverse:
* The process should include redundant and diverse verification and validation activities.

Robust:
* The process should be able to recover from failures of individual process activities

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Note on Process Diversity and Redundancy

A
  • Process activities, such as validation, should not depend on a single approach, such as testing, to validate the system
  • Rather, multiple different process activities that complement each other and allow for cross-checking help to avoid process errors, which may lead to errors in the software

Types:
* Reviews
* Automated analysis
* Testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Name Different Types of Validation Activities

A
  • Requirements reviews.
  • Requirements management.
  • Formal specification.
  • System modelling
  • Design and code inspection.
  • Static analysis.
  • Test planning and management.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is meant by dependable programming?

A

Meaning; Good programming practices can are adopted to help reduce the incidence of program faults.

These programming practices support
* Fault avoidance
* Fault detection
* Fault tolerance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Name examples of good practice guidelines for dependable programming?

A
  • Limit the visibility of information in a program
  • Check all inputs for validity
  • Provide a handler for all exceptions
  • Minimise the use of error-prone constructs
  • Provide restart capabilities
  • Check array bounds
  • Include timeouts when calling external components
  • Name all constants that represent real-world values
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Summary of Topic (Security Specification)

A
  • Dependability in a program can be achieved by avoiding the introduction of faults, by detecting and removing faults before system deployment, and by including fault tolerance facilities.
  • The use of redundancy and diversity in hardware, software processes and software systems is essential for the development of dependable systems.
  • The use of a well-defined, repeatable process is essential if faults in a system are to be minimised.
  • Dependable programming relies on the inclusion of redundancy in a program to check the validity of inputs and the values of program variables.