1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software...

36
1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies

Transcript of 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software...

Page 1: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

1

Software Engineering and Security

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

Page 2: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

2

DJPS’ Members

1. Danai Wiriyayanyongsuk

2. Jack Leung

3. Patai Sangbutsarakum

4. Sanjaya lai

Page 3: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

3

Agenda

Background Security System Overview Security Software Approach

– CLASP– Threat Modeling– XSE

Water Fall Model and Security References Question and Answer

Page 4: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 5: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

5

Security System Overview

A security system depends on: Hardware Software People Procedures Culture

Page 6: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 7: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

7

Approaches

Threat Modeling CLASP (Comprehensive, Lightweight

Application Security Process) XSE (Extreme Security Engineering)

Page 8: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

8

Extreme Security Engineering(XSE)

Page 9: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 10: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 11: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

11

Inside XSE: Detail

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

Page 12: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 13: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 14: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

14

Threat Modeling

Threat Modeling

Page 15: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 16: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 17: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 18: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 19: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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.

Page 20: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

20

Threat Modeling: Limitation

Require time, effort, and large number of resources

Page 21: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

21

CLASP

Comprehensive, Lightweight Application

Security Process

Page 22: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 23: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

23

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

CLASP: What is CLASP (Cont’)

Page 24: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 25: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

25

CLASP: Limitations

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

Need security expertise

Page 26: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

26

Waterfall Model and Security

Page 27: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 28: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

28

What is Waterfall Model (Cont’)

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

Page 29: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 30: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 31: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

31

Plain Waterfall Model

Securityrequirements

Abusecases

Riskanalysis

Externalreview

Risk-basedSecurity tests

StaticAnalysis(tools)

Riskanalysis

Penetrationtesting

Requirementsand use cases

Design Testplans

Code Testresults

Fieldfeedback

Page 32: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 33: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

33

Last but not Least

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

Page 34: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 35: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

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

Page 36: 1 Software Engineering and Security DJPS April 12, 2005 Professor Richard Sinn CMPE 297: Software Security Technologies.

36

Q & A