Requirements

1. Requirements James Walden Northern Kentucky University Case study and diagrams used from NatarajanMeghanathan’s NSF TUES project: Incorporating Systems Security and Software Security in Senior Projects.

2. Topics • Security Requirements • Misuse Cases • Misuse Case Diagrams • Sample Requirements • Case Study: e-commerce CSC 666: Secure Software Engineering

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

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

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

6. AbuseCases Risk Analysis Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Requirements Design Coding Testing Maintenance Software Security Practices • Code Reviews • Risk Analysis • Penetration Testing • Security Testing • Abuse Cases • Security Operations CSC 666: Secure Software Engineering

7. Misuse Cases Anti-requirements Think 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 cases Informed brainstorming: attack patterns, risks. CSC 666: Secure Software Engineering

8. Use Case Example UC 1: Login to Web Store Primary Actor: Customer Stakeholders 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

9. Misuse Case Example MUC 1: Sniff Password Primary Actor: Attacker Stakeholders 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. CSC 666: Secure Software Engineering

10. 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. Steal the car Short the ignition 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.

11. Example 1: Use Case – Misuse Case Diagram for Secure Communication Regular User Attacker Send Information in Plaintext threaten Hack the communication Channel and read plaintext includes mitigate Encrypt all data and Send the Ciphertext threaten Capture the ciphertext and do cryptanalysis to extract the plaintext extends mitigate The attacker has to now do a Steganalysis to detect the presence of secretly hidden Info (ciphertext) and then do a Cryptanalysis on the extracted ciphertext to extract the plaintext Embed the Ciphertext in an Image and send the StegoImage

12. Example 2: Use Case – Misuse Case Diagram for Web Forum Design Regular User Send a benign message for posting to the Forum Attacker Send a Message loaded with XSS Script to post to the Forum includes threaten The message gets posted to the Forum mitigate extends Sanitize the message for any potential script to trigger XSS attack and then post to the Forum includes Administrator

13. Detailed Misuse Case Outline Basic Flow: • Attacker installs network sniffer. • Sniffer saves all packets which contain strings matching “Logon,” “Username,” or “Password.” • Attacker reads sniffer logs. • Attacker finds valid username/password in log. • Attacker uses sniffed password to access system. CSC 666: Secure Software Engineering

14. 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. CSC 666: Secure Software Engineering

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

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

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

18. Case Study: Online Shopping Application Use Case and Misuse Case Diagrams Mounika Challagundla, Graduate Student Dr. Natarajan Meghanathan, Associate Professor Department of Computer Science Jackson State University, Jackson, MS 39217, USA

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

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

21. use case diagram: Login Registration Select items Data base View items Customer Search items Payment Administrator Deliver items

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

23. Login: Username Database Customer Password

24. Login: Database Username Threatens <<includes>> Mitigates Customer Hacks user name password Threatens <<extends>> Mitigates Hacks password Applies cryptographic methods Misuser

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

26. Payment details: Name Address Card number Data base Expiration date Customer CVV number Shipping address Administrator Billing address

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

28. Payment details: Name Address Data base Threatens Hacks the details Card number <<includes>> Threatens Threatens Expiration date Mitigates <<includes>> Customer <<includes>> Admini strator CVV number Use cryptographic techniques Shipping address Billing address Misuser

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

30. use case Vs Misuse case diagram: Threatens Mitigates <<includes>> Login Hacks login Apply encryption Threatens Data base Select items <<includes>> Selects all items Mitigates View items Cart should be cleared within some time interval Customer Admini strator Search items Threatens <<includes>> Payment Hacking bank details Mitigates Cryptographic methods should be applied Misuser Deliver items

31. References • CLASP, OWASP CLASP Project, http://www.owasp.org/index.php/Category:OWASP_CLASP_Project, 2008. • Noopur Davis et. al., Processes for Producing Secure Software. IEEE Security & Privacy, May 2004. • 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. • Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006. • Gary McGraw, Software Security, Addison-Wesley, 2006. • NatarajanMeghanathan, TUES Program: Incorporating Systems Security and Software Security in Senior Projects, http://www.jsums.edu/cms/tues/, 2012. CSC 666: Secure Software Engineering