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

2. 2 DJPS’ Members 1. Danai Wiriyayanyongsuk 2. Jack Leung 3. Patai Sangbutsarakum 4. Sanjaya lai

3. 3 Agenda Background Security System Overview Security Software Approach – CLASP – Threat Modeling – XSE Water Fall Model and Security References Question and Answer

4. 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. 5 Security System Overview A security system depends on: Hardware Software People Procedures Culture

6. 6 Software in Security System Server Operating System ex. Windows TM. Network Operating System ex. IOS. Database ex. Oracle. Application ex. ERP, CRM, E-Mail, Virus Scanner, API etc.

7. 7 Approaches Threat Modeling CLASP (Comprehensive, Lightweight Application Security Process) XSE (Extreme Security Engineering)

8. 8 Extreme Security Engineering (XSE)

9. 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. 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. 11 Inside XSE: Detail Planning game/objective User stories Small releases Testing Continuous integration Simple design and refactoring Pair development On-site customers

12. 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. 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. 14 Threat Modeling

15. 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. 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. 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. 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. 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. 20 Threat Modeling: Limitation Require time, effort, and large number of resources

21. 21 CLASP Comprehensive, Lightweight Application Security Process

22. 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. 23 Effective and easy to adopt. Activity-centric approach. Defines 30 core activities. CLASP: What is CLASP (Cont’)

24. 24 ActivityOwnerParticipants Identify user roles and requirements Requirements Specifier Specify resource-based security properties Software Architecture Perform source-level security review Security AuditorImplementer Identify and implement security tests Test AnalystSecurity Auditor CLASP: Some of 30 core activities

25. 25 CLASP: Limitations Driven by Secure Software, Inc. and IBM (not by a standard organization) Need security expertise

26. 26 Waterfall Model and Security

27. 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. 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. 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. 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. 31 Plain Waterfall Model Security requirements Abuse cases Risk analysis External review Risk-based Security tests Static Analysis (tools) Risk analysis Penetration testing Requirements and use cases Design Test plans Code Test results Field feedback

32. 32 Waterfall Model and Security Security requirements Abuse cases Risk analysis External review Risk-based Security tests Static Analysis (tools) Risk analysis Penetration testing Security breaks Requirements and use cases Design Test plans Code Test results Field feedback

33. 33 Last but not Least The followings are highly recommended: – Recurring risk tracking – Monitoring activities

34. 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. 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.ht ml 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=/msdnma g/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. 36 Q & A