1. Security Issues
CS 560
Lecture 9

2. Security in the software development process
The security goal:
Protect the confidentiality of data.
Preserve the integrity of data.
Promote the availability of data for authorized use.
Security considerations need to be part of the software development process.

3. System layers where security may be compromised

4. Security in the software development process (Documentation)
Develop security requirements:
Security requirements developed along with other requirements
Functional, non-functional (security), user, legal, etc.
Security risk analysis
Identify all (known) threats
Develop security policies
Used as guidelines for security requirements

5. Security in the software development process
Threat Models
Security Design Guidelines

6. Security Threat models (Documentation)
A structured representation of the items that affect security of an application/component.
Objectives of threat models:
Identify vulnerabilities
Component interface, resource management, etc.
Define countermeasures
Prevent or reduce effects of documented threats
General steps in threat modeling:
Evaluation of component scope
Generate system model
Identify vulnerabilities/threats
Evaluate threat history
Develop countermeasures for specific threats

7. Security Threat models (Documentation)
Security Threat using Data Flow Diagrams:
Process – task that performs some action based on the data
External entity – located outside the system, interacts at a system entry/exit point
Data store – place where data is stored/retrieved
Data flow – movement of data between elements
Trust boundary – boundary between trust levels or privileges

8. Security Threat DFD example

9. Design guidelines 1-3 (Documentation)
Base decisions on an defined security policies
Security requirements should apply to all systems/components.
Avoid single points of failure
Ensure that a security failure can only result when there is more than one failure in security procedures.
Fail securely
When a system/component fails, ensure that sensitive information can’t be accessed by unauthorized users.

10. Design guidelines 4-6 (Documentation)
Balance security and usability
Try to avoid security procedures that make the system difficult to use.
Sometimes you have to accept weaker security to make the system more usable.
Log user actions
Maintain a log of user actions that can be analyzed to discover who did what.
If users know about such a log, they are less likely to behave in an irresponsible way.
Specify the format of all system/component inputs
If input formats are known then you can check that they don’t cause problems.

11. Design guidelines 7-9 (Documentation)
Compartmentalize your assets
Organize the system so that assets are in separate areas and users only have access to the information that they need.
Docker Containers will help with this
Design for deployment
Design the system to avoid deployment problems.
Distributed systems have increased security vulnerabilities
Design for recoverability
Design the system to simplify recoverability after a successful attack.

12. Security in the software development process
Implementation of security features
From the requirements and DFD
Using good design and coding practices

13. Security in the software development process (Documentation)
Testing of the code developed in the previous stage
Create and validate security tests
Experience-based testing
Penetration testing
Tool-based analysis
Security vulnerability tracking
logs
Code reviews

14. Security needs and dangers
Secrecy: control of who gets to read information.
Integrity: control how information changes or resources are used.
Availability: prompt access to information and resources.
Accountability: knowing who has had access to resources.
Dangers:
Damage to information: Integrity compromise
Disruption of service: Availability compromise
Theft of information: Secrecy compromise
Loss of privacy: Accountability, Secrecy
compromise

15. The economics of security
How secure should your system be?
Building secure systems adds cost, complexity, and time to software development.
“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

16. Security techniques: Barriers
Place barriers that separate different parts of a complex system:
Require authentication to access certain systems or parts of the system
Isolate components
EX: some computers (and/or containers) are not connected to a public network
Firewalls
NAT routers act as a firewall for your group’s Raspberry Pi.
How?

17. Security Techniques: Authentication and authorization (Documentation)
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
Database group

18. 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 encryption
RSA extensively used to provide secure communication

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.
Reduce insecure interactions between components
Reduce risky resource management
Reduce porous defences
Project management and test procedures must ensure that programs avoid these errors.
What are the most dangerous software errors?

20. Programming secure software (Documentation)
The following slides introduce the top five most dangerous errors in software development.
Each group should examine their components, interfaces, and nodes for these security risks.
Create a subsection in your documentation that includes:
Threat model DFDs of components to show potential security risks.
Original source code that could compromise security.
Documentation on how you solved the security threat.
Modified source code that mitigates security threat.

21. Most dangerous Errors #1
Improper neutralization of special elements used in a SQL command (“SQL Injection”)
SQL injection is a technique where malicious users can inject SQL commands using a web page input.
Ex: UserID: admin or 1 = 1
Server result from input:
SELECT * FROM Users WHERE UserID = admin or 1 = 1
The above SQL statement is valid. It will return all rows from the table Users, since WHERE 1 = 1 is always true.
If the Users table contains names and passwords, security will be compromised.

22. Most dangerous Errors #1
Improper neutralization of special elements used in a SQL command (“SQL Injection”)
Attack frequency: (how often the weakness occurs/attacker exploits)
High
Ease of Detection: (how easy the weakness can be found by an attacker)
Easy
Consequences: (results of weakness being exploited by attacker)
Data loss, Security bypass
Remediation Cost: (effort required to fix the weakness)
Low

23. Most dangerous Errors #2
Improper neutralization of special elements used in an OS command (“OS Command Injection”)
OS command injection is a technique that uses a web interface in order to execute OS commands on a web server.
Ex: PHP
$userName = $_POST["user"];
$command = 'ls -l /home/' . $userName;
system($command);
The $userName variable is not checked for malicious input. An attacker can set the variable to any OS command, such as:
;rm -rf /
The semi-colon is a command separator in Unix/Linux.
The OS would first execute the “ls” command, then execute the “rm” command, which would delete the entire filesystem from the root directory.

24. Most dangerous Errors #2
Improper neutralization of special elements used in an OS command (“OS Command Injection”)
Attack frequency: (how often the weakness occurs/attacker exploits)
Often
Ease of Detection: (how easy the weakness can be found by an attacker)
Easy
Consequences: (results of weakness being exploited by attacker)
Code execution, Data loss
Remediation Cost: (effort required to fix the weakness)
Medium

25. Most dangerous Errors #3
Buffer copy without checking size of input(“Classic Buffer Overflow”)
Buffer overflow attacks are techniques where a program overwrites memory adjacent to a buffer that should not have been modified. C, C++, and Assembly programs are generally targets.
Ex: C
char last_name[20];
printf ("Enter your last name: ");
scanf ("%s", last_name);
The code above doesn’t limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total.

26. Most dangerous Errors #3
Buffer copy without checking size of input(“Classic Buffer Overflow”)
Attack frequency: (how often the weakness occurs/attacker exploits)
Often
Ease of Detection: (how easy the weakness can be found by an attacker)
Easy
Consequences: (results of weakness being exploited by attacker)
Code execution, Denial of Service, Data loss
Remediation Cost: (effort required to fix the weakness)
Low

27. Most dangerous Errors #4
Improper neutralization of input during web page generation (“Cross-site Scripting”)
Attack technique where malicious users can inject Javascript or other client side content into a web page that your web server generates.
Ex: PHP
$username = $_GET['username'];
echo '<div class="header"> Welcome, ' . $username . '</div>';
The parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as
Language="Javascript">alert("You've been attacked!");</Script>

28. Most dangerous Errors #4
Improper neutralization of input during web page generation (“Cross-site Scripting”)
Attack frequency: (how often the weakness occurs/attacker exploits)
Often
Ease of Detection: (how easy the weakness can be found by an attacker)
Easy
Consequences: (results of weakness being exploited by attacker)
Code execution, Security bypass
Remediation Cost: (effort required to fix the weakness)
Low

29. Most dangerous Error #5 Missing authentication for critical function
Attack technique that targets critical functions or modules of software that does not perform security checks before accepting and processing input.
Ex: Java
public BankAccount createBankAccount(String accountNumber, String accountType, String accountName, double balance) {
BankAccount account = new BankAccount();
account.setAccountNumber(accountNumber);
account.setAccountType(accountType);
account.setAccountOwnerName(accountName);
account.setBalance(balance);
return account;}
The above example has no authentication mechanism to ensure that the user creating the account has the authority to create new bank accounts.

30. Most dangerous Errors #5
Missing authentication for critical function
Attack frequency: (how often the weakness occurs/attacker exploits)
Sometimes
Ease of Detection: (how easy the weakness can be found by an attacker)
Moderate
Consequences: (results of weakness being exploited by attacker)
Security bypass
Remediation Cost: (effort required to fix the weakness)
Low to high

31. Programming secure software
For the top 25 programming errors, see:

32. Programming secure software
The following list is from the SANS security institute, Essential Skills for Secure Programmers Using Java/JavaEE,
Input handling
Authentication & session management
Access control (authorization)
Java types & JVM management
Application faults & logging
Encryption services
Concurrency and threading
Connection patterns

33. Supplemental reading
Butler W. Lampson, “Computer Security in the Real World”.