1 software engineering and security djps april 12, 2005 professor richard sinn cmpe 297: software...

1

Software Engineering and Security

DJPSApril 12, 2005Professor Richard SinnCMPE 297: Software Security Technologies

2

DJPS’ Members

1. Danai Wiriyayanyongsuk

2. Jack Leung

3. Patai Sangbutsarakum

4. Sanjaya lai

3

Agenda

Background Security System Overview Security Software Approach

– CLASP– Threat Modeling– XSE

Water Fall Model and Security References Question and Answer

4

Backgrounds

The computer virus is obvious example of software security.

Nimda first surfaced on September 18, 2001. Nimda targets both server and client

computers. Nimda propagated via email attachments,

shared files on server, and web page containing java script.

5

Security System Overview

A security system depends on: Hardware Software People Procedures Culture

6

Software in Security System

Server Operating System ex. WindowsTM. Network Operating System ex. IOS. Database ex. Oracle. Application ex. ERP, CRM, E-Mail, Virus

Scanner, API etc.

7

Approaches

Threat Modeling CLASP (Comprehensive, Lightweight

Application Security Process) XSE (Extreme Security Engineering)

8

Extreme Security Engineering(XSE)

9

XP & XSE

What is Extreme Programming (XP)– An "agile" software development methodology characterized by face-to-

face collaboration between developers and an on-site customer representative, limited documentation of requirements in the form of "user stories," and rapid and frequent delivery of small increments of useful functionality.

What is Extreme Security Engineering (XSE)– An adoption of "agile" software development principles in general and XP

practices in particular to security engineering and to security development projects

– XSE is meant to aid the projects developed for business customers with achieving “good enough security” without defining a proposition what it is.

Relation Between XP & XSE– XSE implements XP styled “patterns” to deliver “Good Enough Security” to

customers not the opposite, an “Absolute” security. – XSE exists with XP.

10

XSE: “Good Enough Security”

Defined by customer NOT by security engineer.

Simple, small, and secure. Provides what the customers want, no

more and no less.

11

Inside XSE: Detail

Planning game/objective User stories Small releases Testing Continuous integration Simple design and refactoring Pair development On-site customers

12

XSE: Advantages

Increase customer satisfaction Lower defect rates Faster development times Able to handle rapidly changing requirements,

caused by budget priorities and business process

Give customers freedom to adjust security requirements as often as they want

13

XSE: Limitations

XSE is best when exists with XP. Difficulty (in some projects) of creating

staging environment where early versions of the solution are deployed.

Hard to perform incremental security testing.

14

Threat Modeling

Threat Modeling

15

What is Threat Modeling?

Threat Modeling allows you to systematically identify and rate the threats that are most likely to affect your system.

Thus you can address threats and prioritize from the greatest risk.

16

Threat Modeling: Principles

Threat Modeling Process is an iterative process.

Starts during the early phases of the design and continues throughout the application development life cycle.

17

Threat Modeling: Process

1. Identify assets

2. Create an architecture overview

3. Decompose the application

4. Identify the threats

5. Document the threats

6. Rate the threats

18

TM’s output document: Audience

Designers make secure design choices Developers use it to mitigate the risk Testers can write test cases to test for the

vulnerabilities.

19

Threat Modeling: Advantages

Prioritize the risk of each threat. Ensure that security is built into the product. Could help prevent bugs since the design

process. Eliminate potentially costly patches later.

20

Threat Modeling: Limitation

Require time, effort, and large number of resources

21

CLASP

Comprehensive, Lightweight Application

Security Process

22

A set of process pieces for secure application development.

A Plug-in for Rational Unified Process (RUP) environment.

Also a stand-alone process.

CLASP: Definition

23

Effective and easy to adopt. Activity-centric approach. Defines 30 core activities.

CLASP: What is CLASP (Cont’)

24

Activity Owner ParticipantsIdentify user roles and requirements

Requirements Specifier

Specify resource-based security properties

Software Architecture

Perform source-level security review

Security Auditor Implementer

Identify and implement security tests

Test Analyst Security Auditor

CLASP: Some of 30 core activities

25

CLASP: Limitations

Driven by Secure Software, Inc. and IBM (not by a standard organization)

Need security expertise

26

Waterfall Model and Security

27

A sequence of stages in which the output of each stage becomes the input for the next.

The Waterfall model is a different model from the iterative model.

What is Waterfall Model

28

What is Waterfall Model (Cont’)

Example of Waterfall model’s stages:– Requirements and use cases– Design– Test plans– Code– Test results– Field feedback

29

Advantages of Water Fall Model

Clearly state of the progress of development stages– Good for project management– Engineers know their tasks

Good for short life-time project

30

Disadvantages of Water Fall Model

Difficult (expensive) to accommodate change after process is underway

Does not allow for much revision Does not work with complex system

31

Plain Waterfall Model

Securityrequirements

Abusecases

Riskanalysis

Externalreview

Risk-basedSecurity tests

StaticAnalysis(tools)

Riskanalysis

Penetrationtesting

Requirementsand use cases

Design Testplans

Code Testresults

Fieldfeedback

32

Waterfall Model and Security

Securityrequirements

Abusecases

Riskanalysis

Externalreview

Risk-basedSecurity tests

StaticAnalysis(tools)

Riskanalysis

Penetrationtesting

Securitybreaks

Requirementsand use cases

Design Testplans

Code Testresults

Fieldfeedback

33

Last but not Least

The followings are highly recommended:– Recurring risk tracking– Monitoring activities

34

Conclusion

No Silver Bullet for security Carefully adopt the proper security

processes that fit your project needs Possible to combine, more than one techniqu

es. Security is an iterative process

35

References

http://www.processimpact.com/UC/Module_3/Export/data/downloads/glossary.html#e http://konstantin.beznosov.net/professional/projects/Agile_Security_Engineering.html http://konstantin.beznosov.net/professional/papers/

Towards_Agile_Security_Assurance.html http://konstantin.beznosov.net/professional/papers/eXtreme_Security_Engineering.html http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx?pull=/library/

en-us/dnnetsec/html/thcmch03.asp#c03618429_014 http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx?pull=/

msdnmag/issues/03/11/resourcefile/default.aspx http://www.securesoftware.com/CLASP/ http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/oct04/

viega/viega.pdf http://elvis.rowan.edu/~clamen/classes/S02/SE/Chapter3-I.ppt http://c2.com/cgi/wiki?WaterFall http://www.cigital.com/papers/ download/software-security-gem.pdf

36

Q & A