Requirements

James WaldenNorthern Kentucky University

Case study and diagrams used from Natarajan Meghanathan’s NSF TUES project: Incorporating Systems Security and Software Security in Senior Projects.

CSC 666: Secure Software Engineering

Topics

1. Security Requirements2. Misuse Cases3. Misuse Case Diagrams4. Sample Requirements5. Case Study: e-commerce

CSC 666: Secure Software Engineering

Requirements

Functional: describe what software must be capable of doing.

Non-functional: describe qualities of software, such as availability, reliability, &c.

Security is a non-functional requirement. Some security requirements can be re-cast as

functional requirements. The app must not accept overly long input data. The app must validate all input to ensure it does not

exceed the specified size for that type of input.

CSC 666: Secure Software Engineering

Sources of Security Requirements

Customers’ expressed security concerns. Security implications of functional

requirements. Protect against SQL injection if app uses DB. Protect against XSS if there is web output.

Regulatory compliance Federal Information Security Management Act Sarbanes-Oxley Health Insurance Portability & Accountability Act

CSC 666: Secure Software Engineering

Methodologies

REVEAL: Requirements Engineering VErification and VAlidation from Praxis

SQUARE: Security QUAlity Requirements Engineering from CMU/SEI

TRIAD: Trustworth Refinement through Intrusion-Aware Design from CMU/SEI

AEGIS: Appropriate and Effective Guidance in Information Security

Abuse Cases, a/k/a Misuse Cases

CSC 666: Secure Software Engineering

Software Security Practices

1. Code Reviews2. Risk Analysis3. Penetration

Testing

SecurityOperations

Requirements Design Coding Testing Maintenance

RiskAnalysis

AbuseCases

Code Reviews +Static Analysis

PenetrationTesting

SecurityTesting

4. Security Testing5. Abuse Cases6. Security

Operations

CSC 666: Secure Software Engineering

Misuse Cases

Anti-requirementsThink about what software should not do.

A use case from an adversary’s point of view.• Obtain Another User’s CC Data.• Alter Item Price.• Deny Service to Application.

Developing misuse casesInformed brainstorming: attack patterns, risks.

CSC 666: Secure Software Engineering

Use Case ExampleUC 1: Login to Web StorePrimary Actor: CustomerStakeholders and Interests:

Customer: Wants to purchase products.Preconditions: Customer has web access.Postconditions: Customer has access to their

account, with the ability to pay for and ship products.

Summary: Customer gains access to system using an assigned username and password.

CSC 666: Secure Software Engineering

Misuse Case ExampleMUC 1: Sniff PasswordPrimary Actor: AttackerStakeholders and Interests:

Attacker: Wants to obtain user credentials.Preconditions: Attacker has access to a machine

on network path between user and system.Postconditions: Attacker has obtained one or

more valid usernames and passwords.Summary: Attacker obtains and later misuses

passwords to gain unauthorized access to system.

Misuse Case RelationshipsMitigates – A use case can mitigate the chance that a misuse case will complete successfully.Threatens – A misuse case can threaten a use case by exploiting it or hindering it.

Source: M. Imran Daud, “Secure Software Development Model: A Guide for Secure Software Life Cycle,” Proceedings of the International Multi Conference on Engineers and Computer Scientists, vol. I, March 2010.

Steal the car

Short the ignition

Regular UserSend Information in

Plaintextin

clud

es

Encrypt all data and Send the Ciphertext

Attacker

Hack the communication Channel and read plaintext

Embed the Ciphertext in an Image and send the

StegoImage

threaten

mitigate

exte

nds

Capture the ciphertext and do cryptanalysis to

extract the plaintext

threaten

mitigate

The attacker has to now do aSteganalysis to detect the presence of secretly hidden Info (ciphertext) and then do a Cryptanalysis on the extracted ciphertext to extract the plaintext

Example 1: Use Case – Misuse Case Diagram for Secure Communication

Regular UserSend a benign message for posting to the Forum

incl

udes

The message gets posted to the Forum

Attacker

Send a Message loaded with XSS Script to post to the Forum

Sanitize the message for any potential script to triggerXSS attack and then post

to the Forum

exte

nds

threaten

miti

gate

Example 2: Use Case – Misuse Case Diagram for Web Forum Design

Administratorincludes

CSC 666: Secure Software Engineering

Detailed Misuse Case Outline

Basic Flow:1. Attacker installs network sniffer.2. Sniffer saves all packets which contain

strings matching “Logon,” “Username,” or “Password.”

3. Attacker reads sniffer logs.4. Attacker finds valid username/password in

log.5. Attacker uses sniffed password to access

system.

CSC 666: Secure Software Engineering

Detailed Misuse Case Outline

Alternate Flows: 1a. Attacker not on path between user and

system:1. Attacker uses ARP poisoning or similar

attack to redirect user packets through his system. 1b. Customer uses wireless connection.

1. Attacker drives to customer location. 2. Attacker uses wireless sniffer to intercept

passwords. 4a. Attacker finds no passwords in log

1. Continue sniffing until a password is found.

Sample Security Requirements Scenario 1: Application stores sensitive information that must be

protected for HIPAA compliance Sec. Req: Strong encryption must be used to protect sensitive

information wherever stored.

Scenario 2: The application transmits sensitive user information across potentially untrusted or unsecured networks

Sec. Req: The communication channels must incorporate encryption to prevent snooping (to protect the confidentiality of the data) and mutual cryptographic authentication must be employed to prevent man-in-the-middle attacks (for integrity and authenticity of communication)

Scenario 3: The application must remain available to legitimate users. Sec. Req: Resource utilization by remote users must be monitored and

limited to prevent or mitigate denial-of-service attacks.

Sample Security Requirements Scenario 4: The application supports multiple users with different levels

of privilege. Sec. Req: The application should define the actions that users at each

privilege level is authorized to perform. The various privilege levels assigned to users should be tested. Mitigations for authorization bypass attacks need to be defined.

Scenario 5: The application takes user input and uses SQL. Sec. Req: SQL injection mitigations need to be defined.

Scenario 6: The application manages sessions for a logged-in user. Sec. Req: Session hijacking mitigations should be in place.

Scenario 7: The system needs to keep track of individual users and authentication must be enforced.

Sec. Req: User passwords should be securely stored and mitigations to combat dictionary attacks must be in place.

Sample Security Requirements Scenario 8: The application is written in C or C++. Sec. Req: The code must be written in such a way that buffer sizes are

always tracked and checked; format strings should not be modified by user input; and integer values should not be allowed to overflow. If the compiler supports the use of stack canaries, use them.

Scenario 9: The application presents user-generated data in HTML. Sec. Req: Mitigations for XSS attacks must be in place.

Scenario 10: The application requires an audit log. Sec. Req: Define all functions that need to be logged; Verify that the

audit log is secure.

Scenario 11: The application uses cryptography Sec. Req: The generated secrets must use a secure random-number

generator.

Scenario 12: The application opens files that are typically exchanged over untrusted links such as a media file over the Internet.

Sec. Req: The application must validate all data read from the file and not trust it.

Case Study: Online Shopping Application

Mounika Challagundla, Graduate StudentDr. Natarajan Meghanathan, Associate Professor

Department of Computer Science Jackson State University, Jackson, MS 39217, USA

Use Case and Misuse Case Diagrams

Use case descriptions• Login: Every user who want to buy the items at first have to

register with the system. After that the user need to provide login details for every login session.

• Search items: Customer searches the items by mentioning item in the search box.

• View items: Here the customer view the selected items that the user want to buy.

• Payment: This use case describe payment procedure. Here customer can pay the amount through credit cards or any other means.

• Deliver items: This use case describe how the administrator deliver items to the customer.

Identification of actors

• Customer: At first the customer get register with the system and logon to buy or view the products.

• Administrator: Administrator monitors the online shopping system . He take the amount paid by the customer and also checks the details.

• Database: Various product information, customer details are stored in the database.

Registration

Login

Select items

View items

Search items

Payment

Customer

Data base

Administrator

use case diagram:

Deliver items

Misuse case description• The misuser can login with any other potential

customer account and use the special offers given to those customers. It can be mitigated by using encryption methods to the login details.

• The misuser will select more than one or all items to the shopping cart so that legitimate customers can’t access those items. To mitigate this the shopping cart should be cleared within some time interval.

• The misuser can hack the bank items from the database by SQL attacks, it can be mitigated by using cryptographic techniques.

Username

PasswordCustomerDatabase

Login:

Username

password

Customer

Login:

Misuser

Threatens

Database

Hacks user nameMitigates

<<includes>>

<<extends>>

Applies cryptographic methods

Hacks password

Threatens

Mitigates

Misuser description

• Misuser can hack the user name easily so that he can access the information.

• To eradicate this a password can be used. But a password also can be hacked.

• Thus some cryptographic methods can be used to provide maximum protection.

Payment details:Name

Address

Expiration date

Card number

Customer

Administrator

Database

CVV number

Shipping address

Billing address

Use case description• The name, address should be given to the seller i.e.,

administrator.• The card details must include card number, expiration

date, CVV number, shipping address, billing address.• All these details will be verified by the administrator

and will be stored in the database. • If all the above details are valid then the items will be

shipped by the administrator.

Payment details:

Name

Address

Expiration date

Card number

Customer

CVV number

Shipping address

Billing address

Hacks the details

Threatens

Threaten

sThreatens

<<includes>>

<<includes>>

<<includes>> Miti

gate

s

Use cryptographic techniques

Data base

Administrator

Misuser

Misuse case description

• The misuser can hack the bank account details such as card number, expiration date, CVV number and etc. so that the misuser can use those details.

• This can be mitigated by encrypting all those details by using cryptographic and steganographic techniques.

Login

Select items

View items

Search items

Payment

Customer

Data base

Administrator

use case Vs Misuse case diagram:

Deliver items

Hacks login

Threatens<<includes>> Mitigates

Apply encryption

Selects all items

Threatens<<includes>>

Miti

gate

s

Cart should be cleared within some time interval

Threatens<<includes>>

Mitig

ates Hacking bank

details

Cryptographic methods should be applied Misus

er

CSC 666: Secure Software Engineering

References1. CLASP, OWASP CLASP Project,

http://www.owasp.org/index.php/Category:OWASP_CLASP_Project, 2008.

2. Noopur Davis et. al., Processes for Producing Secure Software. IEEE Security & Privacy, May 2004.

3. Karen Goertzel, Theodore Winograd, et al. for Department of Homeland Security and Department of Defense Data and Analysis Center for Software. Enhancing the Development Life Cycle to Produce Secure Software: A Reference Guidebook on Software Assurance, October 2008.

4. Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006.

5. Gary McGraw, Software Security, Addison-Wesley, 2006.6. Natarajan Meghanathan, TUES Program: Incorporating Systems

Security and Software Security in Senior Projects, http://www.jsums.edu/cms/tues/, 2012.