Software Engineering and Security

1
Software Engineering and Security

• DJPS
• April 12, 2005
• Professor Richard Sinn
• CMPE 297 Software Security Technologies

2
DJPS Members

• Danai Wiriyayanyongsuk
• Jack Leung
• Patai Sangbutsarakum
• 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
TMs 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
CLASP Definition

• A set of process pieces for secure application
  development.
• A Plug-in for Rational Unified Process (RUP)
  environment.
• Also a stand-alone process.

23
CLASP What is CLASP (Cont)

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

24
CLASP Some of 30 core activities
Activity Owner Participants
Identify 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
25
CLASP Limitations

• Driven by Secure Software, Inc. and IBM (not by a
  standard organization)
• Need security expertise

26
Waterfall Model and Security
27
What is Waterfall Model

• 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.

28
What is Waterfall Model (Cont)

• Example of Waterfall models 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
External review
Security requirements
Static Analysis (tools)
Penetration testing
Abuse cases
Risk analysis
Risk-based Security tests
Risk analysis
Requirements and use cases
Test results
Field feedback
Test plans
Code
Design
32
Waterfall Model and Security
External review
Security requirements
Static Analysis (tools)
Penetration testing
Abuse cases
Risk analysis
Risk-based Security tests
Risk analysis
Security breaks
Requirements and use cases
Test results
Field feedback
Test plans
Code
Design
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 techniques.
• Security is an iterative process

35
References

• http//www.processimpact.com/UC/Module_3/Export/da
  ta/downloads/glossary.htmle
• http//konstantin.beznosov.net/professional/projec
  ts/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/thre
  atmodeling/default.aspx?pull/library/en-us/dnnets
  ec/html/thcmch03.aspc03618429_014
• http//msdn.microsoft.com/security/securecode/thre
  atmodeling/default.aspx?pull/msdnmag/issues/03/11
  /resourcefile/default.aspx
• http//www.securesoftware.com/CLASP/
• http//www-106.ibm.com/developerworks/rational/lib
  rary/content/RationalEdge/oct04/viega/viega.pdf
• http//elvis.rowan.edu/clamen/classes/S02/SE/Chap
  ter3-I.ppt
• http//c2.com/cgi/wiki?WaterFall
• http//www.cigital.com/papers/ download/software-s
  ecurity-gem.pdf

36
Q A