1. Security case – buffer overflow
Security assurance case study, 2013 Slide 1

2. Security cases
• A structured body of evidence that supports an
argument related to the security of a system
• Intended to convince a regulator or system controller
that the system is acceptably secure
• Comparable to safety cases
Security assurance case study, 2013 Slide 2

3. The system is acceptably secure CLAIM
SUBCLAIM
Requirements Operation
There are no missing or Operational procedures guard against
Existing requirements that create Security deficiencies
Security vulnerabilities
Coding
There are no implementation errors
Design that create security vulnerabilities
There are no design errors that
Create security vulnerabilities
Security assurance case study, 2013 Slide 3

4. Coding
There are no implementation errors
that create security vulnerabilities
Programmers trained Coding defects
Programmers have been trained Security-threatening coding defects
In secure coding practice for the have been identified and checked
development language used
Buffer overflow
Description of good coding
There are no buffer
practice
overflow possibilities in the code
EVIDENCE Input checks
Records of programmer All inputs checked for
training validity
Security assurance case study, 2013 Slide 4

5. Buffer overflow
There are no buffer
overflow possibilities in the code
System testing
Code review
Testing the code with invalid inputs
Code reviews showed no
(long strings) resulted in all invalid
potential buffer overflows
Inputs being rejected
Static analysis
Static analysis tool did not
Report buffer overflow
possibilities
Security assurance case study, 2013 Slide 5

6. System testing
Testing the code with invalid inputs
(long strings) resulted in all invalid
Inputs being rejected
Test selection analysis Test plan Test results
Justification that the system The tests chosen Results of running the
Tests chosen were adequate and expected tests on the system
To discover buffer overflow test results
Security assurance case study, 2013 Slide 6

7. Security arguments
• Security should be based on multiple arguments
rather than a single argument
• Key elements
– Competence of the development team
– Conformance with recommended development processes
– Use of manual and automated analysis of code, designs and
documents
– System testing
Security assurance case study, 2013 Slide 7

8. Tool support
• Security and safety arguments depend on organising
a large volume of records, documents, test
results, etc.
• Difficult to do manually so tool support for
argumentation, reporting and document management
is required
• Commercial tools available to support this activity e.g.
Adelard safety case editor
Security assurance case study, 2013 Slide 8

9. Security assurance case study, 2013 Slide 9

10. Conclusions
• Security cases involve making structured
arguments, backed up by evidence about the security
of a system.
• Security cases will become increasingly important as
regulators and managers will expect these to be
produced before security-critical software is released
• Interesting challenge of reconciling security cases
(which rely on documentation) and agile software
development (which relies on minimising
documentation)
Security assurance case study, 2013 Slide 10