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

Beyond security testing

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Beyond security testing

Beyond Security Testing A Seminar

C.D. Nguyen, PhD SE-Group / FBK http://selab.fbk.eu/dnguyen/

Trento, April 2013

1

Page 2: Beyond security testing

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

Page 3: Beyond security testing

Agenda

1.Introduction

2.Engineering secure software systems

3.The role of a security tester

Page 4: Beyond security testing

Part I: Introduction

Page 5: Beyond security testing

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

Page 6: Beyond security testing

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)

Page 7: Beyond security testing

Examples

Page 8: Beyond security testing

Security in mobile world

Page 9: Beyond security testing

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!!!

Page 10: Beyond security testing

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!!!

Page 11: Beyond security testing

Part II: Engineering Secure Software

Systems

Page 12: Beyond security testing

Software Engineering (SE)

Basis about:

• What is software?

• What is software engineering?

• What is a software process?

Page 13: Beyond security testing

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

Page 14: Beyond security testing

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

Page 15: Beyond security testing

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

Page 16: Beyond security testing

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

development !

Page 17: Beyond security testing

SE for secure systemsDevelopment Activities

Security Feature

Requirement SpecificationAnalysts

DesignDesigners

ImplementationDev.

Testing & Validation

Test engineers

It’s everyone’s concerns!

Page 18: Beyond security testing

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

Page 19: Beyond security testing

Microsoft® Security Development Lifecycle (SDL)

More info: http://www.microsoft.com/security/sdl/default.aspx

The most comprehensive & systematic process model publicly available.

Page 20: Beyond security testing

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

Page 21: Beyond security testing

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.

Page 22: Beyond security testing

Microsoft® Security Development Lifecycle (SDL)

• Verification:

• Dynamic analysis, leveraging tools which monitor application behavior

• Fuzz Testing

• Attack surface review

Page 23: Beyond security testing

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

Page 24: Beyond security testing

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

Page 25: Beyond security testing

Examples of threat models

A Model Transformation from Misuse Cases to

Secure Tropos

Naved Ahmed1, Raimundas Matulevicius1, 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, [email protected]

Abstract. In current practices security concerns are typically addressedat the design or implementation stages, leaving aside the rationale forsecurity analysis. The reason is that a systematic approach to addresssecurity from late development stages to early analysis stages does notexist. This paper presents transformation rules to perform model trans-lation from misuse case diagram to Secure Tropos model. The transla-tion justifies the system security concerns, and keep the traceability ofthe security decisions. Our proposal is based on the systematic domainmodel for information systems security risk management (ISSRM); thus,it preserves the semantics of both security languages’ constructs andsynchronise the mechanisms across language boundaries to elicit, correctand complete security requirements. An example from banking sectordemonstrates the applicability of our proposal.

Keywords: Information System (IS), Requirements engineering, SecureTropos, Misuse cases, Model transformation.

1 Introduction

It is recognised that blemishes in requirements, on one hand, cost 10 to 200times more once handled [3], and glitches in early requirements analysis stagesoutcomes a high percentage of system failures [12]. On another hand currentpractice starts develop security only after the system design or implementationis done [6]. However, this might lead to a gap between requirement analysis andthe actual implementation. Although security modelling languages are used atdi↵erent stages of the system development, they still lack dedicated constructsto identify the security concerns [7, 8], such as vulnerabilities, risks and theircountermeasures. There exists little e↵ort to integrate di↵erent security mod-elling languages into the coherent modelling approach so that developers couldbenefit from various modelling viewpoints along di↵erent system developmentstages. Such integration could also contribute to security traceability across thedevelopment cycle, thus, also keeping the rationale for the security decisions.

In this paper we introduces a set of transformation rules to translate misusecase diagrams [11] to Secure Tropos models [10]. This is a continuation of our

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)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 linkshows that one actor (depender) depends on another actor (dependee) to attainsome dependum (e.g., goal, plan or resource). A secure dependency is restrictedby the security constraint that must be respected by both actors (e.g., relation-ship between Customer and Banking IS). A means-end link indicates how thegoal (end) is satisfied. A decomposition relationship represents a breakdown ofplan into several plans or goals. Restricts and attacks relationships are intro-

Threat modeled as Use Cases & Misuse Cases

Page 26: Beyond security testing

Examples of threat models

A Model Transformation from Misuse Cases to

Secure Tropos

Naved Ahmed1, Raimundas Matulevicius1, 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, [email protected]

Abstract. In current practices security concerns are typically addressedat the design or implementation stages, leaving aside the rationale forsecurity analysis. The reason is that a systematic approach to addresssecurity from late development stages to early analysis stages does notexist. This paper presents transformation rules to perform model trans-lation from misuse case diagram to Secure Tropos model. The transla-tion justifies the system security concerns, and keep the traceability ofthe security decisions. Our proposal is based on the systematic domainmodel for information systems security risk management (ISSRM); thus,it preserves the semantics of both security languages’ constructs andsynchronise the mechanisms across language boundaries to elicit, correctand complete security requirements. An example from banking sectordemonstrates the applicability of our proposal.

Keywords: Information System (IS), Requirements engineering, SecureTropos, Misuse cases, Model transformation.

1 Introduction

It is recognised that blemishes in requirements, on one hand, cost 10 to 200times more once handled [3], and glitches in early requirements analysis stagesoutcomes a high percentage of system failures [12]. On another hand currentpractice starts develop security only after the system design or implementationis done [6]. However, this might lead to a gap between requirement analysis andthe actual implementation. Although security modelling languages are used atdi↵erent stages of the system development, they still lack dedicated constructsto identify the security concerns [7, 8], such as vulnerabilities, risks and theircountermeasures. There exists little e↵ort to integrate di↵erent security mod-elling languages into the coherent modelling approach so that developers couldbenefit from various modelling viewpoints along di↵erent system developmentstages. Such integration could also contribute to security traceability across thedevelopment cycle, thus, also keeping the rationale for the security decisions.

In this paper we introduces a set of transformation rules to translate misusecase diagrams [11] to Secure Tropos models [10]. This is a continuation of our

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)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 linkshows that one actor (depender) depends on another actor (dependee) to attainsome dependum (e.g., goal, plan or resource). A secure dependency is restrictedby the security constraint that must be respected by both actors (e.g., relation-ship between Customer and Banking IS). A means-end link indicates how thegoal (end) is satisfied. A decomposition relationship represents a breakdown ofplan into several plans or goals. Restricts and attacks relationships are intro-

Threat modeled with Secure Tropos

Page 27: Beyond security testing

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.

Page 28: Beyond security testing

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

Page 29: Beyond security testing

Part III: The role of a security tester

Page 30: Beyond security testing

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 mindset30

Page 31: Beyond security testing

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

Page 32: Beyond security testing

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

Page 33: Beyond security testing

Data mutation (Fuzz testing)

576 Part IV Special Topics

The easiest threats to test for are denial of service threats, which make theapplication fail. If your test code can make the application fail and issue anaccess violation, you’ve identified a DoS threat, especially if the application is anetworked service. Data mutation is an excellent test mechanism for findingDoS vulnerabilities.

Important The application has suffered a DoS attack if you canmake a networked service fail with an access violation or some otherexception. The development team should take these threats seriously,because they will have to fix the bug after the product ships if thedefect is discovered.

Figure 19-1 shows techniques for perturbing an application’s environment.

F19GO01Figure 19-1 Techniques to perturb applications to reveal security vul-nerabilities and reliability bugs.

When designing security tests, keep this diagram close at hand. It willhelp you determine which test conditions you need to create. Let’s look ateach category.

!"#$%&"'%#()$'%*+,-

.()$'$%*+#-/#$'0)1'#,%211#$$%*+0-

3"%211#$$%*+2-

!2'2

4"&5%*46-

78"0'%*4$-

9#0"%6#&5'8%*4:-

9#0"%*;:-

3<66%*;&-

=26),%>%?&@26),%*;@-

/2&,"A%*;0-

B0"&5%'CD#%*;'-

/#D62C*30-

+<'E"FE$C&1*3"-

G)58%@"6<A#*38-

;"&'#&'$

!""#$%&'())*+(,%+-$.%'/0(0

7):#

4)&H%*+6-

32A#%*+&-;"&'2)&#07#1<0)'C

,2'2%A<'2')"&'#18&)I<#$

B0"&5%$)5&%*;$- +<'%"F%J"<&,$%*;"-

7D#1)26%182021'#0$762$8#$%*;D$-

K<"'#$%*;DI-

GLM4%*;D8-

.$12D#,%*;D#-

710)D'%*;D$-

M#'2%*;DA-

Page 34: Beyond security testing

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

Page 35: Beyond security testing

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

Page 36: Beyond security testing

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

Page 37: Beyond security testing

To read more

Writing Secure Code, Second Edition

Michael Howard and David LeBlanc

To learn more about this book, visit Microsoft Learning at http://www.microsoft.com/MSPress/books/5957.aspx

9780735617223 Publication Date: December 2002