1. Beyond Security Testing
A Seminar
C.D. Nguyen, PhD
SE-Group / FBK
http://selab.fbk.eu/dnguyen/
Trento, April 2013
1

2. Before we start
• About the presenter:
• A security-enthusiastic SE researcher:
• work to improve software quality
• promote to build secure softwares, because security is a
feature, not an afterthought
• About this seminar
• Open, don’t hesitate to interrupt
• Love to discuss & learn your “white-hat” hacking experience
• Last but not least good news: No exam related to this
seminar

3. Agenda
1.Introduction
2.Engineering secure software systems
3.The role of a security tester

4. Part I: Introduction

5. The need of secure
systems
• The “good old days, 1990s”, PCs are isolated,
with little (or no) connectivity
• Security is not a problem, as long as Apps
work
• No security concern in most of the
engineering books!!!
• However, old practices still influence
today’s software development
5

6. The need of secure
systems
• In the Internet era:
• All devices are connected, virtually
• This gives a huge opportunity to attackers
• have assess to target devices
• systems are not designed with security
• The Internet was not designed with security
in mind (CERT)

7. Examples

8. Security in mobile
world

9. Security is a product
feature
• Security is a feature, just like other feature in the product
• Ensure availability
• Secure customer information
• Help gain users’ trust
• Do not treat security as an afterthought
• People often add security as a wrapping layer around other
features
• and consider security only when it needs to:
• when having resource
• or after being attacked
This is wrong!!!

10. Security is a product
feature
Adding security as an afterthought is wrong, why?
• Late addition of any feature, including security, is expensive
• Might impact & change other features, expensive too
• Break the current interfaces
It’s better to consider security right from start:
• Security is a feature, it needs resource too, but it’s
planned, no surprise
• Require more resource at the beginning, but overall
cheaper
•The released product is more secure!!!

11. Part II: Engineering
Secure Software
Systems

12. Software Engineering
(SE)
Basis about:
• What is software?
• What is software engineering?
• What is a software process?

13. What is software?
• Computer programs and associated documentation such as
requirements, design models and user manuals.
• Software products may be developed for a particular customer or
may be developed for a general market.
• Software products may be
• Generic - developed to be sold to a range of different
customers e.g. PC software such as Excel or Word.
• Tailored - developed for a single customer according to their
specification.
• New software can be created by developing new programs,
configuring generic software systems or reusing existing software.
Slide credit: Ian Sommerville - Software Engineering, 7th Edition

14. What is software
engineering?
• Software engineering is an engineering
discipline that is concerned with all aspects
of software production.
• Software engineers should adopt a systematic
and organised approach to their work and
use appropriate tools and techniques
depending on the problem to be solved, the
development constraints and the resources
available.
Slide credit: Ian Sommerville - Software Engineering, 7th Edition

15. What is a software
process?
• A set of activities whose goal is the development or evolution
of software.
• Generic activities in all software processes are:
• Specification - what the system should do and its
development constraints
• Development - production of the software system
• Validation - checking that the software is what the
customer wants
• Evolution - changing the software in response to changing
demands
Slide credit: Ian Sommerville - Software Engineering, 7th Edition

16. Software process
models?
• Are software process seen from specific
perspective, e.g. workflow, role/action
• Many process models exist, no “one side fit
all)
Example:
Iterative
developme
nt
!

17. SE for secure systems
Development Activities
Security Feature
Requirement Specification
Analysts
Design
Designers
Implementation
Dev.
Testing &Validation
Test engineers
It’s everyone’s
concerns!

18. SE for secure systems
• Team training
• Security knowledge is essential: secure design,
secure coding, and more thorough testing
• Often team members are not security-equipped,
pre-training is needed
• Security experts can take part in security reviews
• Software process model with security by default
• Embody security engineering aspects in every
activity

19. Microsoft® Security Development
Lifecycle (SDL)
More info: http://www.microsoft.com/security/sdl/default.aspx
The most comprehensive & systematic
process model publicly available.

20. Microsoft® Security Development
Lifecycle (SDL)
• Requirements:
• Security and privacy analysis involves security experts,
define security criteria
• Defines the severity thresholds of security vulnerabilities —
for example, no known vulnerabilities in the application
with a “critical” or “important” rating at time of release
• Security risk assessments (SRAs) and privacy risk
assessments (PRAs) identify functional aspects of the
software that require closer review

21. Microsoft® Security Development
Lifecycle (SDL)
• Design:
• Create security and privacy design
specifications, specification review
• Analyze attack surface
• Threat modeling: understand security threats
to a system, determine risks from those threats,
and establish appropriate mitigations.

22. Microsoft® Security Development
Lifecycle (SDL)
• Verification:
• Dynamic analysis, leveraging tools which
monitor application behavior
• Fuzz Testing
• Attack surface review

23. Thread modeling
• Formally specify:
• Potential enemies attackers
• Security threats
• Risks from those threats
• Mitigation solutions
• Done at design phase, used in
all sub-sequence phases,
including testing

24. Thread modeling
• How to determine threats:
• Using known categories of threats
(STRIDE: Spoofing identity,Tampering with
data ….)
• Tools:
• SDL Threat Modeling Tool 3.1.8 (Microsoft)
• SecureTropos
• Misuse case

25. Examples of threat
models
A Model Transformation from Misuse Cases to
Secure Tropos
Naved Ahmed1
, Raimundas Matuleviˇcius1
, and Haralambos Mouratidis2
1
Institute of Computer Science, University of Tartu, Estonia
{naved,rma}@ut.ee
2
School of Computing and Technology, University of East London, UK
h.mouratidis@uel.ac.uk
Fig. 2. Misuse Case Diagram
A resource (e.g., Account) is an entity required by actors. In Secure Tropos, se-
curity constraint (e.g., Only by bank customer and Only by bank officer)
Threat modeled as Use Cases
& Misuse Cases

26. Examples of threat
models
A Model Transformation from Misuse Cases to
Secure Tropos
Naved Ahmed1
, Raimundas Matuleviˇcius1
, and Haralambos Mouratidis2
1
Institute of Computer Science, University of Tartu, Estonia
{naved,rma}@ut.ee
2
School of Computing and Technology, University of East London, UK
h.mouratidis@uel.ac.uk
A resource (e.g., Account) is an entity required by actors. In Secure Tropos, se-
curity constraint (e.g., Only by bank customer and Only by bank officer)
is a constraint that the system must possess. A threat (e.g., Money stolen) rep-
resents an event that endangers the security features of system. Additionally,
vulnerability point is represented by a black circle in Fig.3 (adapted from [5]).
Fig. 3. Secure Tropos Diagram
Secure Tropos uses relationships to connect constructs. Dependency link
shows that one actor (depender) depends on another actor (dependee) to attain
Threat modeled with Secure
Tropos

27. A successful story:
Windows 7
• Memo from Bill Gates Jan. 15, 2002
... designed from the ground up to deliver Trustworthy
Computing. What I mean by this is that customers will always
be able to rely on these systems to be available and to
secure their information. Trustworthy Computing is computing
that is as available, reliable and secure as electricity, water
services and telephony.
!
...
In the past, we’ve made our software and services more
compelling for users by adding new features and functionality,
and by making our platform richly extensible. We’ve done a
terrific job at that, but all those great features won’t matter
unless customers trust our software. So now, when we face
a choice between adding features and resolving security
issues, we need to choose security. Our products should
emphasize security right out of the box, and we must constantly
refine and improve that security as threats evolve.

28. A successful story:
Windows 7
• Microsoft has changed radically its engineering process
to include security
• Resulting: Windows 7 is much more secure than
previous versions, more security features
• Address Space Layout Randomization (ASLR)
• PatchGuard, to prevent unauthorized programs from
modifying the operating system kernel
• User Account Control (UAC), least privilege principle
• Protected Mode Internet Explorer (PMIE)
Source: http://www.biztechmagazine.com/, http://www.techradar.com

29. Part III:The role of a
security tester

30. Security testing
• Security testing is an important part of the overall process
• If you don’t perform security testing for your application,
someone else NOT working for your company will
• But, it’s different from normal testing
• Security testing is to demonstrate that threat mitigation
techniques work
• Buy showing that user’s identify cannot be spoofed, data
cannot be tampered….
• (Security) testers:
• keep everyone honest
• have the final STAMP as to whether your application ships
• Security testers should adopt a hacker’s mindset
30

31. Security tester role
• Building Security Test Plans from a Threat Model
1.Decompose the application into its fundamental
components.
2.Identify the component interfaces.
3.Rank the interfaces by potential vulnerability.
4.Ascertain the data structures used by each
interface.
5.Find security problems by injecting mutated data.
• Testing (with security templates) & Finding bugs

32. Examples of
component interfaces
• TCP and UDP sockets s Wireless data
• NetBIOS
• Mailslots
• Dynamic Data Exchange (DDE)
• Named Pipes
• Shared memory
• Other named objects—Named Pipes and shared
memory are named objects—such as
semaphores and mutexes
• The Clipboard
• Local procedure call (LPC) and remote
procedure call (RPC) interfaces
• COM methods, properties, and events
• Parameters to ActiveX Controls and Applets
(usually <OBJECT> tag arguments)
• EXE and DLL functions
• System traps and input/output controls (IOCTLs) for kernel-mode
components s The registry
• HTTP requests and responses
• Simple Object Access Protocol (SOAP) requests
• Remote API (RAPI), used by Pocket PCs
• Console input
• Command line arguments
• Dialog boxes
• Database access technologies, including OLE DB and ODBC
• Database stored procedures
• Store-and-forward interfaces, such as e-mail using SMTP, POP, or MAPI,
or queuing technologies such as MSMQ
• Environment (environment variables)
• Files
• Microphone
• LDAP sources, such as Active Directory
• Hardware devices, such as infrared using Infrared Data Association
(IrDA), universal serial bus (USB), COM ports, FireWire (IEEE 1394),
Bluetooth and so on

33. Data mutation (Fuzz
testing)
Important The application has suffered a DoS attack if you can
make a networked service fail with an access violation or some other
exception. The development team should take these threats seriously,
because they will have to fix the bug after the product ships if the
defect is discovered.
Figure 19-1 shows techniques for perturbing an application’s environment.
F19GO01
Figure 19-1 Techniques to perturb applications to reveal security vul-
nerabilities and reliability bugs.
Does not exist (Od)
Exists (Oe)Restricted access (Or)
No access (Oa)
Data
Long (Ll)
Short (Ls)
Zero length (Lz)
Zero (Cz)
Null (Cn)
Valid + Invalid (Cv)
Random (Cr)
Wrong type (Ct)
Replay
(Nr)
Out-of-sync
(No)
High volume
(Nh)
Contents
Applies to
on-the-wire data
Size
Link (Ol)
Name (On)Container
Security
data mutation
techniques
Wrong sign (Cs) Out of bounds (Co)
Special characters
Slashes (Cps)
Quotes (Cpq)
HTML (Cph)
Escaped (Cpe)
Script (Cps)
Meta (Cpm)

34. Hackers' mindset
• See things from different perspectives, with
genius and curiosity
• Breaking things is a nature
• Earn respect by solving interesting
problems.
Hacker's Manifesto: http://www.phrack.org/
issues.html?issue=7&id=3&mode=txt

35. Summary
• Security problems are on the news’
headlines every day
• Unfortunately, there is no security in the
“old-but-still-used” software practices
• We need to build security in software from
ground up
• It is a product feature, not a wrapping
layer

36. Summary
• Software process lifecycle with security does
exist
• Microsoft® SDL is a systematic and
comprehensive one
• Security testing is different from normal testing
• It’s hard but we have to, otherwise your
enemies will do
• Ethical hacker’s mindset helps

37. To read more
Writing Secure Code,
Second Edition
Michael Howard and
David LeBlanc