IS 2935: Developing Secure Systems

1
IS 2935 Developing Secure Systems

• Jan 9, 2006
• NSF supported

2
Contact

• James Joshi
• 721, IS Building
• Phone [phone]
• E-mail jjoshi_at_mail.sis.pitt.edu
• Web http//www.sis.pitt.edu/jjoshi/Devsec/
• Office Hours Wednesdays 1.00 3.00 p.m. or By
  appointments
• GSA will be announced later

3
Course Objective

• The objective of the course
• To learn the principles and practice of secure
  information system design
• Life cycle models/ security engineering
  principles
• To learn about how to implement secure and high
  assurance information systems
• Secure programming (e.g., C, C, Java)
• To learn about the tools and techniques to
  conduct testing and analysis of systems

4
Course Coverage

• Secure software development process
• Security Engineering/Lifecycle models
• Software Development Models
• Capability Maturity Models and Extensions
• Trustworthy computing Security Engineering
  Lifecycle
• Possible Microsoft Onsite Training
• Secure Design/Implementation Principles
• Systems / software
• Formal methods
• UMLSec, Model Checking (code, protocols)

5
Course Coverage

• Secure programming
• Coding practices and guidelines
• Code analysis
• Language specific issues (C, C, Java, .Net, ??)
• Buffer overflows Race conditions
• Input validation SQL injection
• Cross-site scripting Mobile Code
• Safe Languages
• High assurance architectures
• System/Software assurance (Web Services/
  Service-oriented architectures)
• Privacy/Digital Rights Management Issues
• Testing
• Evaluations
• Tools

6
Pre-requisite

• IS 2150/TEL 2810 Introduction to Computer
  Security
• Following courses are preferred but not required
  
• IS 2170/TEL 2820 Cryptography TEL 2821 Network
  Security
• IS 2511 or 2540
• Talk to the instructor if you are not sure of the
  background

7
Course References

• Building Secure Software How to avoid the
  Security Problems the Right Way, John Viega, Gary
  McGraw, Addison-Wesley, 2002
• Enterprise Java Security Building Secure J2EE
  Applications, Marco Pistoia, Nataraj Nagaratnam,
  Larry Koved, Anthony Nadalin, Addition-Wesley,
  2004
• Secure Systems Development with UML, Jan Jurjens,
  Springer-Verlag, 2005.
• Securing Web Services with WS-Security
  Demystifying WS-Security, WS-Policy, SAML, XML
  Signature, and XML Encryption Jothy Rosenberg,
  David Remy, 2004, Sams Publishing, 2004.

8
Course References

• High Assurance Design Architecting Secure and
  Reliable Enterprise Applications, Clifford J.
  Berg, Addison-Wesley, 2006.
• Core Security Patterns Best Practices and
  Strategies for J2EE?, Web Services, and Identity
  Management, Christopher Steel, Ramesh Nagappan,
  Ray Lai Prentice-Hall
• How to Break Software Security - James
  Whittaker, Herbert Thompson, Addition Wesley,
  2003
• Secure Coding in C and C, Robert C. Seacord,
  Addition-wesley, 2006
• Computer Security Art and Science by Matt Bishop
  (ISBN 0-201-44099-7), Addison-wesley 2003.
• Papers MSDN, US-CERT

9
Grading

• Tentative
• Homework/Quiz/ 40
• Presentation/Review 10
• Exams 20
• Project 30
• Extra credits may be obtained through other
  means. E.g. LERSAIS Seminar

10
Course Policy

• Your work MUST be your own
• Zero tolerance for cheating/plagiarism
• You get an F for the course if you cheat in
  anything however small NO DISCUSSION
• Discussing the problem is encouraged
• Homework
• Penalty for late assignments (15 each day)
• Ensure clarity in your answers no credit will
  be given for vague answers
• Homework is primarily the GSAs responsibility
• Check webpage for everything!
• You are responsible for checking the webpage for
  updates

11
Quiz
?
..
12
Overview of Secure Design Principles
13
Secure Design Principles

• Principle of Securing the weakest link
• Attackers focus on weak spot rather than
  fortified components
• If strong cryptosystem is used attackers will
  focus on attacking end systems

14
Secure Design Principles

• Principle of Defense in Depth
• Can protect against single points of failure
• Layer security defenses
• Incorporate redundant security mechanisms

15
Secure Design Principles

• Principle of Failing Securely
• System should fail securely
• Secure defaults
• Default may be to deny access
• Use failure modes
• On failure undo changes and restrore secure state
• Sensitive information should not be revealed upon
  failure

16
Secure Design Principles

• Principle of Least Privilege
• Provide for minimum necessary rights
• For shortest duration necessary
• Revoke rights when required activity is done
• Careful delegation

17
Secure Design Principles

• Principle of Separation of Privilege/duty
• Two keys to open now the two keys can be made
  unavailable to potential attacker
• Fraud protection integrity of system
• Multiple conditions should be met before
  permission is granted

18
Secure Design Principles

• Principle of Economy of Mechanism
• Increased system complexity means increased
  vulnerability
• Difficult to ensure that everything is tested

19
Secure Design Principles

• Principle of Least Common Mechanism
• Avoid having multiple subjects sharing mechanisms
  to grant access to a resource
• limits sharing
• Shared mechanisms represent potential information
  path between users.

20
Secure Design Principles

• Principle of Reluctance to Trust
• assume that the environment in which the system
  resides is insecure
• anticipate malformed input from unknown users
• interface between two systems should be secured

21
Secure Design Principles

• Principle of Never Assuming that Your Secrets are
  Safe
• always assume that an attacker can obtain enough
  information about your system to launch an attack
  
• Relying on an obscure design or implementation
  does not guarantee that a system is secured

22
Secure Design Principles

• Principle of Complete Mediation
• Every access to every object must be checked for
  authority
• implies that a foolproof method of identifying
  the source of every request must be devised

23
Secure Design Principles

• Principle of Psychological Acceptability
• If security mechanisms hinder the usability or
  accessibility of resources, then users may opt to
  turn off those mechanisms.
• security mechanisms should be transparent to the
  users of the system or at most introduce minimal
  obstruction
• Security mechanisms should be user friendly

24
Secure Design Principles

• Principle of Promoting Privacy
• Try not to do anything that might compromise the
  privacy of the user
• This can reduce trust on the system

25
Overview Assurance

• Assurance is confidence that a system/software
  meets its security requirements based on evidence
  provided by the application of assurance
  techniques
• Formal methods, design analysis, testing etc.

26
Role of Requirements

• Requirements are statements of goals that must be
  met
• Vary from high-level, generic issues to
  low-level, concrete issues
• Security objectives are high-level security
  issues and business goals
• Security requirements are specific, concrete
  issues

27
Types of Assurance

• Policy assurance is evidence establishing
  security requirements in policy is complete,
  consistent, technically sound
• To counter threats and meet objectives
• Design assurance is evidence establishing design
  sufficient to meet requirements of security
  policy
• Implementation assurance is evidence establishing
  implementation consistent with security
  requirements of security policy
• Need to use good engineering practices

28
Types of Assurance

• Operational assurance is evidence establishing
  system sustains the security policy requirements
  during installation, configuration, and
  day-to-day operation
• Also called administrative assurance
• Example,
• Do a thorough review of product or system
  documentation and procedures, to ensure that the
  system cannot accidentally be placed in a
  non-secure state.

29
Assurance steps
30
Life Cycle

• Conception
• Manufacture
• Deployment
• Fielded Product Life

31
Waterfall Life Cycle Model

• Requirements definition and analysis
• Functional and non-functional
• General (for customer), specifications
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance

32
Relationship of Stages
33
Other Models of Software Development

• Exploratory programming
• Develop working system quickly
• Used when detailed requirements specification
  cannot be formulated in advance, and adequacy is
  goal
• No requirements or design specification, so low
  assurance
• Prototyping (Similar to Exploratory)
• Objective is to establish system requirements
• Future iterations (after first) allow assurance
  techniques

34
Other Models of Software Development

• Formal transformation
• Create formal specification
• Translate it into program using
  correctness-preserving transformations
• Very conducive to assurance methods
• System assembly from reusable components
• Depends on whether components are trusted
• Must assure connections, composition as well
• Very complex, difficult to assure
• This is common approach to building secure and
  trusted systems

35
Other Models of Software Development

• Extreme programming
• Rapid prototyping and best practices
• Project driven by business decisions
• Requirements open until project complete
• Programmers work in teams
• Components tested, integrated several times a day
• Objective is to get system into production as
  quickly as possible, then enhance it
• Evidence adduced after development needed for
  assurance