requirements james walden northern kentucky university case study and diagrams used from natarajan...
TRANSCRIPT
Requirements
James Walden
Northern 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 Requirements
2. Misuse Cases
3. Misuse Case Diagrams
4. Sample Requirements
5. 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 Reviews
2. Risk Analysis
3. Penetration Testing
SecurityOperations
Requirements Design Coding Testing Maintenance
RiskAnalysis
AbuseCases
Code Reviews +Static Analysis
PenetrationTesting
SecurityTesting
4. Security Testing
5. Abuse Cases
6. 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 Example
UC 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 Example
MUC 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 Relationships
Mitigates – 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 User
Send Information inPlaintext
incl
udes
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 User
Send 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
Administrator
includes
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
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
DB
Admin
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
DB
Admin
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>>
Miti
gate
s
Hacking bank details
Cryptographic methods should be applied Misuser
CSC 666: Secure Software Engineering
References
1. 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.