1. 1 ISEC0511 Programming for Information System Security Lecture Notes #3 Security in Software Systems

2. Building Secured Systems You need to architect your system so that it can defend against any attack. Attack patterns can be grouped into the following: Unauthorized release of privileged information Unauthorized access to resources Unauthorized modification of privileged information. DoS When computers were not networked, there were not security risks. Today, it’s not so. 2

3. Security Development Lifecycle 3

4. you may break down the application’s security objectives into the following categories Identity Financial Proprietary and sensitive data Property and life Reputation Privacy and regulatory Availability guarantees regulatory 4

5. Security Requirements Analysis Functional vs. Nonfunctional requirements Functional requirement is a system or software requirement that specifies a function that a system/software system or system/software component must be capable of performing. Nonfunctional requirement is a software requirement that describes not what the software will do but how the software will do it, e.g. performance, quality attributes. 5

6. Use Case Use cases answer the question: what is the system supposed to do for a legitimate user? Use case-related terms Actor Use case Relationships: include, extend, generalization 6

7. Use Case 7

8. Misuse Case A misuse case is the inverse of a use case, which is a function that the system should not allow. 8

9. Misuse Case Analysis 9

10. Defining Security Requirements 1. First. concentrate on the functional requirements through normal actors and the main use cases requested by these actors 2. Second. Look at security-related misuse cases. Introduce the major misactors and misuse cases. Consider all likely threats for your system. 10

11. Defining Security Requirements 3. Investigate the potential relations between use cases and misuse cases, in terms of potential “includes” relations. Threats to your system that can largely be achieved by exploiting the system’s normal functionality. 4. Look at security-related nonfunctional requirements as functional requirements. Introduce new use cases that are necessary to create with the purpose of detecting or preventing misuse cases. 5. Continue with the preceding four steps with more and more refinements 11

12. Threat Modeling You use threat modeling to determine security threats. Threat modeling is a process that helps you to identify, analyze, document, and possibly rate the system’s vulnerabilities. Threat modeling centers around: Assets Vulnerabilities Threats (possible occurrence of undesirable event) Exploits Countermeasures 12

13. Threat Modeling Some techniques proposed to model threats. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, DoS, elevation of privilege) Attack tree DREAD Attack surface 13

14. STRIDE STRIDE is a methodology for identifying possible threats. Spoofing identity An adversary impersonates a different person and pretends to be a legitimate user to the system. Spoofing attack is mitigated through authentication. 14

15. STRIDE Tampering with data Any data to the application or from the application should be secured so that it cannot be altered. The application should validate all data received from the user before storing or using it for any processing. An attacker should not be able to change data delivered to a user. Data in the disk and any other storage media need to be protected. 15

16. STRIDE Repudiation A dishonest user may dispute a genuine transaction if there is insufficient auditing or record keeping of their activity. For example, a bank customer may say, “The signature on the check is forged and the money should be credited in my account!” Applications need to have audit trails and systems by which the activity of a user can be proved beyond doubt. 16

17. STRIDE Information disclosure If it is possible for an attacker to publicly reveal user data, whether anonymously or as an authorized user, there will be an immediate loss of confidence and reputation. Disclosure of proprietary or secured information may lead to serious financial loss. 17

18. STRIDE DoS Application designers should be aware that their applications may be subject to a DoS attack. 18

19. STRIDE Elevation of privilege If an application provides distinct user and administrative roles, it is vital to ensure that the user cannot elevate his role to a higher privilege one. All actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality. The privileged access must be for the minimum duration it is necessary. 19

20. Attack Tree Attack tree is a tool to evaluate the system security based on various threats. Various vulnerabilities and compromises are used to build the attack tree. 20

21. 21

22. Attack Tree Intrusion scenario can also be expressed as (Replay Attack) (Account-identifier, sniff-Password) (Account-identifier, guessed-Password) (Account-identifier, social-engineered- Password) (Account-identifier, cracked-Password- through-brute-force) 22

23. DREAD DREAD methodology is another tool to determine possible threats and their impact. Risk _ DREAD = (Damage + Reproducibility + Exploitability + Affected users + Discoverability)/5 23

24. DREAD Damage potential. If a threat exploit occurs in reality, how much damage will it cause? 0 = nothing. 5 = individual user data are compromised or affected. 10 = complete system or data are destruction. 24

25. DREAD Reproducibility. How easy is it to reproduce the threat exploit? 0 = very hard or impossible, even for administrators of the application. 5 = one or two steps required, may need to be an authorized user. 10 = just a Web browser and the address bar is sufficient, without authentication. 25

26. DREAD Exploitability. What tool is needed to exploit this threat? 0 = advanced programming and networking knowledge, with custom or advanced attack tools. 5 = malware exists on the Internet, or an exploit is easily performed, using available attack tools. 10 = just a Web browser. 26

27. DREAD Affected users. How many users will be affected? 0 = none. 5 = some users, but not all. 10 = all users. 27

28. DREAD Discoverability. How easy is it to discover this threat? 0 = very hard to impossible; requires source code or administrative access. 5 = can figure it out by guessing or monitoring network traces. 9 = such details of faults are already in the public domain and can be easily discovered using a search engine. 10 = the information is visible in the Web browser address bar or in a form. 28

29. Attack Surface If you want to attack an enemy target, the target must be visible or exposed. This is precisely the reason for using bunkers and trenches in a war. In computers, only that part of the program can be a target of attack that is accessible to an attacker. The attack surface of an application is the union of code, interfaces, services, protocols, and practices exposed to a user (or attacker alike). In security design, therefore, the attempt is always to analyze the attack surface and reduce it. If the attack surface is reduced, the risk of attack is also reduced. 29

30. Attack Surface To reduce the attack surface: Question 1. Is this feature really necessary? Question 2. Is it necessary to offer this feature from remote location? Question 3. Who are the users that need to access this feature? Question 4. What type of privilege does this feature need to provide the service? Question 5. What are the interfaces this feature has with other services, interfaces, and protocols? 30

31. Putting It All Together 31 System objective Functional requirement Identity assets Misuse-case Analysis STRIDE CIAAAA STRIDE CIAAAA Use-case analysis Attack tree analysis DREAD Reduce attack surface

32. Security Design Patterns A design pattern is a formal way of documenting successful solutions to problems. Joseph Yoder and Jeffrey Barcalow were first to adapt design patterns for information security. 32

33. Security Design Patterns Single access point. Providing a security module and a way to log in the system. There should be only one way to enter into the system. Checkpoint. Organizing security checks and their repercussions. Roles. Organizing users with similar security privileges. Session. Localizing global information in a multiuser environment. 33

34. Security Design Patterns Full view with errors. Providing a full view to users showing exceptions when needed. Limited view. Allowing users to see only what they have access to. Secure access layer. Integrating application security with low-level security. 34

35. Security Design Patterns 35

36. Security Design Patterns Single Access Point The single access point pattern recommends that there should be only one point of entry into the system. Any security system is difficult to manage when it has multiple doors. 36

37. Security Design Patterns Checkpoint the user of a system should be validated. This check is governed by the security policy of the organization. The authentication can be single or multi- factor. 37

38. Security Design Patterns Role In authentication, we verify who the user is, whether the user is genuine. Through authorization, we determine what privilege the user has and what type of facility and access right the user has in the system. In an organization, quite often a user has several types of roles. 38

39. Security Design Patterns Session A session remembers the context of a transaction. It remembers where the user is at any point in time with respect to a transaction. Full view with errors Users should be allowed to roam around anywhere and know a system. However, they should not be allowed to access a resource that they are not privileged to use. 39

40. Security Design Patterns Limited View Unlike the full view with errors, this pattern allows the user to know only that part of the system that he is authorized to know. This pattern is used widely in network security. 40

41. Security Design Patterns Secure Access Layer Build your application security around the existing OS, networking, and database security mechanisms of the computer. On top of the lower-level security foundation, build a secure access layer for communicating in and out of the program. An example is to use SSL for web applications. 41

42. Security Design Patterns Least Privilege Any computer program must always remain in a least-privileged state. When there is a need, it will elevate the privilege only for the duration needed. Journaling All usage details must be recorded. This will be done through journal files. it is necessary that all these files are protected so that they cannot be tampered with. 42

43. Security Design Patterns Close Gracefully All systems should close gracefully. Any resources allocated during the system operation should be released at this point. All files should be closed; all temporary files in disk and memory should be cleaned, deleted, and returned back to the OS. 43

44. Authentication Through the authentication process, you verify users are who they claim to be. Once the identity is proven, you use authorization to determine the access rights. Most computer security hinges on the strength of the password. 44

45. Authentication Issues Encrypt the Password Strong Password Prevent Replay Attack on Password One-Time Password Multi-key Authentication Multi-factor Authentication Build Knowledgebase on Password Usage Challenge Questions 45

46. Authentication Issues Pass Sentences and Passphrases You do not want to know:Udunwant2no I love you for what you are:1lovU4whatUr My daughter Debi is now twenty years old: MydauterDBizNOW20yarZld Mnemonic Password love to ski at Jounfrow in Switzerland -> IL2SAJIS -> !L25@j1$ 46

47. Authentication Issues Single Sign-On CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) Storing passwords using hashes. crypt() functions in UNIX char *crypt(char *key, const char *salt) 47 * From wikipedia *

48. Authorization There could be various sensitive areas where not every user should be allowed to visit. There may be security levels like “top secret,” “secret,” “confidential,” and “unclassified.” In role-based security, you use the role of a user to determine the privilege the user might have to access a resource. It is also called role-based access control (RBAC). 48

49. Security Algorithms Security algorithms generally use various encryption or scrambling algorithms. Encryption algorithms use different complex-number theoretic techniques to hide the meaning of the message so that if the content falls into unsafe hands, it can protect the inner meaning of the content. 49

50. Symmetric Key Cryptography In a symmetric key cryptography, the same key is used for both encryption and decryption. Symmetric key algorithms are much faster compared to its public key counterparts. Example: DES, 3DES, AES 50

51. Public Key Cryptography In public key cryptography, you use two different mathematically related keys. These keys together form a key pair. One of these keys from the pair is used for encryption and the other key for decryption. It is not true that public key cryptosystem is more secure. Example: Diffie–Hellman, RSA (Rivest, Shamir, and Adleman) 51

52. Public Key Cryptography Encryption/Decryption Nonrepudiation 52

53. Secret Sharing / Threshold Cryptography In secret sharing you split the secret key into multiple parts and store this in n different places or share this with n parties. Any k parts of these shares are necessary and sufficient to reconstruct the secret key. This algorithm is called the (k, n) threshold scheme or threshold cryptography. This is like a company check. 53

54. Digital Signature 54 * From wikipedia

55. Session Management TCP protocol has session management by using sequence number. HTTP is connectionless. Many web applications maintain sessions by having session ID through cookies. Issues Session ID guessing Session hijacking and Replay attack. 55

56. Logging and Auditing You should journal the following areas: Authentication Access to security sensitive area Critical modifications Recovery Change in log file Management of log file 56