is 2935: developing secure systems jan 9, 2006 nsf supported jan 9, 2006 nsf supported

IS 2935: Developing Secure Systems

IS 2935: Developing Secure Systems

Jan 9, 2006NSF supportedJan 9, 2006NSF supported

Contact

• James Joshi• 721, IS Building• Phone: 412-624-9982 • E-mail: [email protected]• 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

http://www.sis.pitt.edu/~jjoshi/Devsec/

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

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)

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

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

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.

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

Grading

• Tentative – Homework/Quiz/: 40%– Presentation/Review 10%– Exams 20%– Project 30%

– Extra credits may be obtained through other means. E.g. LERSAIS Seminar

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 GSA’s responsibility

• Check webpage for everything!– You are responsible for checking the webpage for updates

Quiz

....

?

Overview of Secure Design Principles

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


• Principle of Defense in Depth

– Can protect against single points of failure

– Layer security defenses– Incorporate redundant security mechanisms


• 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


• Principle of Least Privilege

– Provide for minimum necessary rights– For shortest duration necessary– Revoke rights when required activity is done– Careful delegation


• 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


• Principle of Economy of Mechanism

– Increased system complexity means increased vulnerability

– Difficult to ensure that everything is tested


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


• 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


• 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


• 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


• 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


• Principle of Promoting Privacy

– Try not to do anything that might compromise the privacy of the user

– This can reduce trust on the system

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.

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

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

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.

Assurance steps

Security requirements

Design

Implementation

1

32

4

Assurancejustification

Design andimplementationrefinement

Life Cycle

• Conception

• Manufacture

• Deployment

• Fielded Product Life

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

Relationship of Stages

Requirementsdefinition andanalysis

System andsoftwaredesign

Implementationand unittesting Integration

and systemtesting

Operationandmaintenance

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


• 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


• 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

is 2935: developing secure systems jan 9, 2006 nsf supported jan 9, 2006 nsf supported

Documents