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

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

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

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

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

6. CSC 666: Secure Software Engineering Software Security Practices 1.Code Reviews 2.Risk Analysis 3.Penetration Testing Security Operations RequirementsDesignCodingTestingMaintenance Risk Analysis Abuse Cases Code Reviews + Static Analysis Penetration Testing Security Testing 4.Security Testing 5.Abuse Cases 6.Security Operations

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

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

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

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

11. Regular User Send Information in Plaintext includes 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 extends Capture the ciphertext and do cryptanalysis to extract the plaintext threaten 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 Example 1: Use Case – Misuse Case Diagram for Secure Communication

12. Regular User Send a benign message for posting to the Forum includes 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 trigger XSS attack and then post to the Forum extends threaten mitigate Example 2: Use Case – Misuse Case Diagram for Web Forum Design Administrator includes

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

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

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 Mounika Challagundla, Graduate Student Dr. Natarajan Meghanathan, Associate Professor Department of Computer Science Jackson State University, Jackson, MS 39217, USA Use Case and Misuse Case Diagrams

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. Registration Login Select items View items Search items Payment Customer Data base Administrator use case diagram: 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. Username Password Customer Database Login:

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

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 Expiration date Card number Customer Administrator Data base CVV number Shipping address 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 Expiration date Card number Customer CVV number Shipping address Billing address Hacks the details Threatens > Mitigates Use cryptographic techniques DB Admin 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. Login Select items View items Search items Payment Customer DB Admin Use Case vs Misuse Case Diagram: Deliver items Hacks login Threatens > Mitigates Apply encryption Selects all items Threatens > Mitigates Cart should be cleared within some time interval Threatens > Mitigates Hacking bank details Cryptographic methods should be applied Misuser

31. CSC 666: Secure Software Engineering References 1.CLASP, OWASP CLASP Project, http://www.owasp.org/index.php/Category:OWASP_CLASP_Project, 2008. http://www.owasp.org/index.php/Category:OWASP_CLASP_Project 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.Enhancing the Development Life Cycle to Produce Secure Software 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. http://www.jsums.edu/cms/tues/