Safety/Security

Question 1

4 causes for a lack of SW safety

Answer 1

• there’s no bug-free code
• the spec is always incomplete
• hardware errors can cause weird readings
• users’ inputs can be locally correct but collectively bad

Question 2

what is a hazard

Answer 2

a situation in which something bad MAY (or may not) happen

Question 3

3 ways to address hazards

Answer 3

• avoidance
• detection and removal
• limit damage after the fact

Question 4

4 hazard management steps

Answer 4

1) ID hazards
2) assess the probability and impact
3) analyze the root causes
4) add requirements that will mitigate the hazard(s)

Question 5

3 types of hazards

Answer 5

• intolerable (people die)
• ALARP (as low as reasonably practicable, bad but not lethal)
• acceptable (minor damage)

Question 6

2 activities that ensure SW safety in the SW process

Answer 6

• ID people in charge of safety

- conduct regular hazard reviews

Question 7

what is static program analysis

Answer 7

the use of a tool to check for errors in the code

Question 8

3 types of things checked using a static program analysis tool

Answer 8

• looks for characteristic errors (common programming errors)
• looks for user-defined error patterns
• checks assertions at different points in the program

Question 9

3 axioms of security

Answer 9

• confidentiality (keep stuff private)
• integrity (keep data reliable)
• availability (able to use through authorized access)

Question 10

3 organization security levels

Answer 10

• infrastructure (IT crowd)
• application (users)
• operational (management)

Question 11

4 types of security threats

Answer 11

• interception (steal some data)
• interruption (prevent use)
• modification (get in and change assets)
• fabrication (falsify private data)

Question 12

4 aspects of documented security policy

Answer 12

• lists assets
• ID protection level of each asset
• responsibilities of people on each level of security
• list procedures and technologies

Question 13

4 reasons why security is harder than safety

Answer 13

• there is a hostile environment with deliberate attacks
• attackers try to mislead about the root causes
• shut down doesn’t work for security as it does with safety
• attacks adapt to any precautions taken to stop them

Question 14

9 security requirement considerations according to Firesmith

Answer 14

1) ID system before prompting the user to authenticate?
2) how to authenticate users
3) Immune-type requirements. How will you defend yourself
4) Integrity. how to detect viruses/data corruption
5) Intrusion Requirements. How will intrusion be detected?
6) non-repudiation. how can ensure that third-parties have in fact agreed to some terms and conditions
7) how to ensure privacy
8) how to audit the system (make sure it’s secure)
9) maintaining system security over time

Question 15

10 guidelines for security in architectural design

Answer 15

1) base decisions on security policy
2) use defense in depth
3) fail securely
4) balance security and usability
5) log user actions
6) use redundancy and diversity
7) have a specific format for inputs and validate them
8) compartmentalize your assets. Secure like assets in the same way
9) design for deployment (make configuration mistakes hard to make)
10) design for recovery (backup auth system)

Question 16

4 types of testing for security holes

Answer 16

1) experience-based testing (test your system against common problems)
2) penetration testing (try and break in)
3) tool-based analysis (scans code)
4) formal verification (FMs)