Lecture 3 - Misuse Cases Final.ppt
- 2. Misuse Case • Misuse case is a business process modeling tool used in the software development industry. • The term Misuse Case or mis-use case is derived from and is the inverse of use case.
- 3. Overview • Use cases specify required behavior of software and other products under development, and are essentially structured stories or scenarios detailing the normal behavior and usage of the software. • A Misuse Case on the other hand highlights something that should not happen (i.e. a Negative Scenario) and the threats hence identified, help in defining new requirements, which are expressed as new Use Cases.
- 4. From use to misuse case • In an industry it is important to describe a system's behavior when it responds to a request that originates from outside : • The use cases have become popular for requirements between the engineers thanks to its features like the visual modeling technique, • They describe a system from an actor's viewpoint and its format explicitly conveys each actor's goals and the flows the system must implement to accomplish them. • The level of abstraction of a use case model makes it an appropriate starting point for design activities, thanks to the use of UML use case diagrams and the end user's or domain expert's language. • But for software security analyses, the developers should pay attention to negative scenarios and understand them. That is why, in the 1990s, the concept of "inverse of an use case" was born in Norway.
- 5. From use to misuse case Use Cases Misuse Cases Goal: to represent what the system should do Goal: to represent a function that the system should not allow Scenario: a "positive" scenario is a sequence of actions leading to a Goal desired by a person or organization Scenario: a "negative" one is a scenario whose goal is desired not to occur by the organization in question or desired by a hostile agent (not necessarily human). Use case as a completed sequence of actions which gives increased value to the user. Misuse case as a completed sequence of actions which results in loss for the organization or some specific stakeholder. Area of use: any business domain application Misuse case are most commonly used in the field of security. With the ever-growing importance of IT system, it has become vital for every company to develop capability to protect its data.
- 6. Area of Use • Misuse cases are not about human error (handled in alternate flows) or system errors (handled in exception flows). • Hence, for example a misuse case might be used to define what a hacker would want to do with the system and define his or her requirements. • A developer or designer can then define the requirements of the user and the hacker in the same UML diagram which in turn helps identify the security risks of the system.
- 7. Why build misuse cases? • You draw your teams attention to forms of attack. • You get the team thinking about security issues early in the project • You make it more likely to prevent attacks • Security becomes part of the functional requirements
- 8. Diagram Basic Concepts • A misuse case diagram is created together with a corresponding use case diagram. The model introduces 2 new important entities (in addition to those from the traditional use case model, use case and actor: • Misuse case : A sequence of actions that can be performed by any person or entity in order to harm the system. • Misuser : The actor that initiates the misuse case. This can either be done intentionally or inadvertently.
- 9. Diagram Basic Concepts • The misuse case model makes use of those relation types found in the use case model; include, extend, generalize and association. • In addition, it introduces two new relations to be used in the diagram: • Mitigates: A use case can mitigate the chance that a misuse case will complete successfully. • Threatens: A misuse case can threaten a use case, e.g. by exploiting it or hinder it from achieving its goals.
- 11. Usage Scenario
- 12. Misuse case Description There are two different ways of describing a misuse case textual; • One is embedded in a use case description template - where you add an extra description field called Threats. This is the field where you fill in your misuse case steps (and alternate steps). This is referred to as the lightweight mode of describing a misuse case. • The other way of describing a misuse case, is by using a separate template for this purpose only. It is suggested to inherit some of the field from use case description (Name, Summary, Author and Date). In addition to there, it is proposed to use several other fields too:
- 13. Misuse case Description • Misuse case name • Summary • Author • Date • Mitigation points • Extension points • Triggers • Preconditions • Assumptions • Mitigation guarantee • Related business rules • Potential misuser profile • Stakeholders and threats • Terminology and explanations • Scope
- 15. Misuse case Description • As one might understand, the list above is too comprehensive to be completely filled out every time. • Not all the fields are required to be filled in at the beginning, and it should thus be viewed as a living document. • There has also been some debating whether to start with diagrams or to start with descriptions. • The recommendation given by Sindre and Opdahl on that matter is that it should be done as with use cases. • Do it the way you feel most familiar with, since both variants each have their strengths and their weaknesses.
- 16. Example 1
- 17. What is a Trojan? • A Trojan horse or Trojan is a type of malware that is often disguised as legitimate software. • Trojans can be employed by cyber-thieves and hackers trying to gain access to users' systems. • Users are typically tricked by some form of social engineering into loading and executing Trojans on their systems. • Once activated, Trojans can enable cyber-criminals to spy on you, steal your sensitive data, and gain backdoor access to your system. These actions can include: • Deleting data • Blocking data • Modifying data • Copying data • Disrupting the performance of computers or computer networks
- 18. New Android Trojan malware discovered in Google Play (Nov 2017) • New piece of mobile malware has been discovered in Google Play masquerading as multiple apps: an alarm clock app, a QR scanner app, a compass app, a photo editor app, an Internet speed test app, and a file explorer app. • It starts innocently enough with an icon created on the mobile device after install. Click on the icon, and it opens a functioning QR scanner, as promised. • However, this QR scanner is short lived. You only get one chance to use the app, because after clicking out of it, the icon disappears! • Out of frustration, you may immediately go to your apps list to uninstall this bizarre-behaving QR scanner, but good luck finding it. Instead, this deceiving app is called Download Manager in the app list. • The first step performed by the malicious app in the background is checking the location of the mobile device. This is done by using the website ip-api.com which provides Geolocation using IP. • If the location is in an area that satisfies rules within the code, then it proceeds to the next step.
- 19. Checksum • A checksum is a small-sized datum derived from a block of digital data for the purpose of detecting errors that may have been introduced during its transmission or storage. • It is usually applied to an installation file after it is received from the download server. • Let's say you download a big update, like a service pack, to a program you use every day, like a graphics editor. This is probably a really big file, taking several minutes or more to download. • Once downloaded, how do you know that the file downloaded properly? What if a few bits were dropped during the download and the file you have on your computer right now isn't exactly what was intended? Applying an update to a program that isn't exactly the way the developer created it is likely to cause you big problems. • This is where comparing checksums can put your mind at ease.
- 21. Example 2
- 22. Example 2
- 23. Cryptography
- 24. Example 3
- 25. Man-in-the-middle attack • In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. • Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to intercept the conversation to eavesdrop and optionally to deliver a false message to Bob. • First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. • Mallory sends a forged message to Alice that purports to come from Bob, but instead includes Mallory's public key. • Alice, believing this public key to be Bob's, encrypts her message with Mallory's key and sends the enciphered message back to Bob. • Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. • When Bob receives the newly enciphered message, he believes it came from Alice.
- 26. Example 4
- 27. Using misuse cases to identify security requirements • Sindre and Opdahl proposes the following 5 steps for using misuse cases to identify security requirements: • Identify critical assets in the system • Define security goals for each assets • Identify threats to each of these security goals, by identifying the stakeholders that may want to cause harm to the system • Identify and analyze risks for the threats, using techniques like Risk Assessment • Define security requirements for the risks. • It is suggested to use a repository of reusable misuse cases as a support in this 5-step process.
- 28. Strengths This modeling tool has several strengths: • It allows you to provide equal weightage to functional and non-functional requirements, which may not be possible with other tools. • It makes you focus on security from the beginning of the design process and it allows you to avoid premature design decisions. • It is a very good tool for improving communication between developers and stakeholders and is valuable in ensuring that both agree on critical system solutions and Trade-off analysis. • Creating misuse cases often trigger a chain reaction which eases the identification of functional and non-functional requirements. The discovery of a misuse case will often leads to the creation of a new use case which acts as a counter measure. This in turn might be the subject of a new misuse case. • As compared to other tools, It relates better to use cases and UML and eases the seamless employment of the model.
- 29. Thank You.