Figures - Chapter 15
Figures - Chapter 15
Figures - Chapter 15
Security checklist
1. Do all files that are created in the application have appropriate access permissions?
The wrong access permissions may lead to these files being accessed by unauthorized
users.
2. Does the system automatically terminate user sessions after a period of inactivity?
Sessions that are left active may allow unauthorized access through an unattended
computer.
3. If the system is written in a programming language without array bound checking, are
there situations where buffer overflow may be exploited? Buffer overflow may allow
attackers to send code strings to the system and then execute them.
4. If passwords are set, does the system check that passwords are ‘strong’? Strong
passwords consist of mixed letters, numbers, and punctuation, and are not normal
dictionary entries. They are more difficult to break than simple passwords.
5. Are inputs from the system’s environment always checked against an input
specification? Incorrect processing of badly formed inputs is a common cause of security
vulnerabilities.
Figure 15.6 A simplified hazard log entry
Hazard Log Page 4: Printed 20.02.2009
Criticality class 1
Fault tree identified YES Date 24.01.07 Location Hazard Log, Page 5
1. The system shall include self-testing software that will test the sensor system, the clock, and the insulin delivery system.
3. In the event of the self-checking software discovering a fault in any of the system components, an audible warning shall be issued and the pump display shall indicate the
name of the component where the fault has been discovered. The delivery of insulin shall be suspended.
4. The system shall incorporate an override system that allows the system user to modify the computed dose of insulin that is to be delivered by the system.
5. The amount of override shall be no greater than a pre-set value (maxOverride), which is set when the system is configured by medical staff.
Figure 15.7 The contents of a software safety case
Chapter Description
System description An overview of the system and a description of its critical components.
Safety requirements The safety requirements abstracted from the system requirements specification.
Details of other relevant system requirements may also be included.
Hazard and risk analysis Documents describing the hazards and risks that have been identified and the
measures taken to reduce risk. Hazard analyses and hazard logs.
Design analysis A set of structured arguments (see Section 15.5.1) that justify why the design is
safe.
Verification and validation A description of the V & V procedures used and, where appropriate, the test
plans for the system. Summaries of the test results showing defects that have
been detected and corrected. If formal methods have been used, a formal system
specification and any analyses of that specification. Records of static analyses of
the source code.
Review reports Records of all design and safety reviews.
Team competences Evidence of the competence of all of the team involved in safety-related systems
development and validation.
Process QA Records of the quality assurance processes (see Chapter 24) carried out during
system development.
Change management processes Records of all changes proposed, actions taken and, where appropriate,
justification of the safety of these changes. Information about configuration
management procedures and configuration management logs.
Associated safety cases References to other safety cases that may impact the safety case.
Figure 15.8 Structured arguments
Figure 15.9 A safety claim hierarchy for the insulin pump
Figure 15.10 Insulin dose computation with safety checks
currentDose = computeInsulin () ;