Upload
victoria-caldwell
View
213
Download
0
Embed Size (px)
Citation preview
SECURITY ISSUES
CS 360
Lecture 9
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESSThe security goal:
To make sure that agents (people or external systems) who interact with a computer system, its data and resources, are those who the owner of the system would wish to have such interactions.
Security considerations need to be part of the software development process.
2
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESSDevelop security requirements:
Security requirements developed along with other requirements Functional, user, legal, etc.
Risk analysis Identify all threats
Develop security policies Used as guidelines for requirements
3
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESSDevelop:
Threat models Security models Security architectures Secure communication models
4
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESS Implementation of security features
From the requirements Using good design and coding practices
5
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESSTesting of the code developed in the previous stageCreation and validation of security testsSecurity vulnerability trackingCode reviews
6
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESSMonitoring security requirementsUpgrade/update security procedures when needed
7
SECURITY IN THE SOFTWARE DEVELOPMENT PROCESSCauses for system security maintenance:
Customer feedback Security incident details and vulnerability reports
Types of maintenance: Introduction of new security functionality Upgrade existing security based on technology trends
8
SECURITY NEEDS AND DANGERS Needs:
Secrecy: control of who gets to read information Integrity: control of how information changes or resources are used.
Availability: providing prompt access to information and resources
Accountability: knowing who has had access to resources
Dangers: Damage to information: Integrity Disruption of service: Availability Theft of money: Integrity Theft of information: Secrecy Loss of privacy: Secrecy
9
THE ECONOMICS OF SECURITYHow secure should your system be?
Building secure systems adds cost and time to software development
“practical security balances the cost of protection and the risk of loss. When a risk is less than the cost of recovering, it’s better to accept it as a cost of doing business..than to pay for better security.”
Butler W. Lampson, 2004
10
THE ECONOMICS OF SECURITY Example: Credit card system
Option A: The card is plastic with all data (name, number, expiration data, etc.)
readable by anyone who has access to the card. A copy of the signature is written on the card.
This is a cheap system to implement, but does little to discourage fraud. Banks in the USA use this system.
Option B (Chip and PIN): The card has an embedded security chip. To use the card, the security chip
must be read by a special reader and the user must type in a secret 4-digit number.
This provides greater protection against fraud, but is more expensive and slightly less convenient for both merchant and user.
Banks in Europe use this system.11
SECURITY AND PEOPLEPeople are inherently insecure
Careless (leaving computer logged on, sharing passwords) Dishonest (stealing, lying)
How is this working out for Volkswagen? Malicious (denial of service attacks)
Many security problems come from inside the organization In a large organization, there will be some disgruntled and dishonest employees
Security relies on trusted individuals. What if they are dishonest?
12
DESIGN FOR SECURITY: PEOPLEMake it easy for responsible people to use your system Make security procedures simple
Make it hard for dishonest or careless people to use your system Password management, malicious users
Train people/users/employees in responsible behavior Test the security of your system thoroughly and often, particularly after changes
Do not hide security violations13
AGENTS AND COMPONENTSThe software development challenge
Develop secure and reliable components Protect the system so that security problems in parts of it do not spread
to the entire system
A large system will have many agents and components Each is potentially unreliable and insecure Components acquired from third parties may have unknown security
problems
The commercial off-the-shelf (COTS) problem Developers of COTS software have considerable incentives to supply
software that has many options and features In developing such software rapidly, they have fewer incentives to be
thorough about security 14
SECURITY TECHNIQUES: BARRIERSPlace barriers that separate different parts of a complex system: Isolate components
EX: some computers are not connected to a network Firewalls Require authentication to access certain systems or parts of the system
15
BARRIERS: FIREWALL
A firewall is a component at the junction of two network segments that: Inspects every packet that attempts to cross the boundary Rejects any packet that does not satisfy certain criteria
An incoming request to open a TCP connection An unknown packet type
Firewalls provide increased security at a loss of flexibility, inconvenience for users, and extra system administration.
16
SECURITY TECHNIQUES: AUTHENTICATION AND AUTHORIZATION Authentication: establishes the identity of an agent:
What does the agent know? (password, url) What does the agent possess? (smart card) What does the agent have physical access to? (network, computer) What are the physical properties of the agent? (fingerprint)
Authorization: establishes what an authenticated agent may do Access control lists
Manager administrator
Group memberships Sudoers group WebDev group
17
SECURITY TECHNIQUES: ENCRYPTION
Allows data to be stored and transmitted securely, even when the bits are viewed by unauthorized agents, and the encryption algorithms are known
Public/Private key encryption18
SECURITY TECHNIQUES: PUBLIC/PRIVATE KEY ENCRYPTION Also known as asymmetric cryptography
User (Alice) generates a key value which they make public Alice then use the public key (plus additional info) to generate a private
key Only Alice knows the private key Others can use Alice’s public key to encrypt a message for Alice Alice can use the private key to decrypt the message
Example: RSA (used extensively) Select two very large prime numbers, P and Q. Compute the product M = P * Q, and make M publically available.
(Public Key) RSA recommends M that’s at least 768 bits long
Next compute T = (P-1) * (Q-1) The user maintains the value of T, P, and Q as a secret. (Private Key)
19
PROGRAMMING SECURE SOFTWARE
Programs that interface with the outside world (websites, mail servers, etc.) need to be written in a manner that resists intrusion. Insecure interactions between components Risky resource management Porous defences
Project management and test procedures must ensure that programs avoid these errors.
For the top 25 programming errors, see: http://cwe.mitre.org/top25/
20
PROGRAMMING SECURE SOFTWARE
The following list is from the SANS security institute, Essential Skills for Secure Programmers Using Java/JavaEE, http://www.sans.org Input handling Authentication & session management Access control (authorization) Java types & JVM management Application faults & logging Encryption services Concurrency and threading Connection patterns 21
SUPPLEMENTAL READINGButler W. Lampson, “Computer Security in the Real World”. IEEE Computer, June 2004.
PDF posted on the course website
22
EXAM 0: STUDY GUIDE Materials (Today’s lecture is excluded from Exam 0):
Feasibility documentation and purpose Software processes Project management Requirements analysis Scenarios and diagrams (UML) System architectures Textbook chapters: 1, 2, 4, 5, 23 Supplemental readings
Exam: five questions, one to omit, graded out of four. Each question equally weighted (25% each) Detailed answers must be legible (marked incorrect if I can’t read your answer)
Answer quality/detail will determine your score for each question Possible multiple section questions; a, b, c, .. One hour to complete the exam in class (1:50pm – 2:50pm)
You may use one 3 x 5 note card on the exam. (front and back)23