Day O’ Security

1. Day O’ Security An Introduction to the Microsoft Security Development Lifecycle Day 1: Threat Modelling - CIA and STRIDE

2. A Threat Modelling Conversationhttp://msdn.microsoft.com/en-us/magazine/dd727503.aspx The Thespians Paige: a young, bright software developer. Michael: a simple security guy at Microsoft. Scene I A small hallway between two sets of cubicles, supposedly designed to enhance agile software development and communication. Paige: Hey, grumps. I need your help building some software. Michael: So? Paige: Seriously, I want your help building this system I'm working on. Michael: You mean you're going to design something, build it, pretend to test it, and then ask me to find the security vulnerabilities? Paige: Don't be so grumpy. No, I want your help up front. Pause: Michael wipes his hand down his face and forces a smile.

3. http://mycodehere.blogspot.com

4. http://mycodehere.blogspot.com/2009/08/security-glossary.htmlhttp://mycodehere.blogspot.com/2009/08/security-glossary.html

5. Some Definitions • Asset- any valuable resource, e.g. database data, file system data, system resource. • Threat - any potential occurrence (malicious or inadvertent) that could harm or impede an asset. • Vulnerability - any weakness which makes possible a threat to an asset. • Exploit - the implementation of a threat against a vulnerability (previously synonymous with Attack). • Attack - application of an exploit; any action designed to harm an asset. • Mitigation - any strategy, technique or circumstance that reduces the threat posed by a vulnerability. • Spam- cooked meat, nice in sandwiches.

6. C.I.A. • C is for IntecrityData cannot be modified undetectably. • I is for AvailabilityData must be available when needed. • A is for ConfidentialityData cannot be disclosed to unauthorized individuals / systems.

7. I.A.C. • I is for IntegrityData cannot be modified undetectably. • A is for AvailabilityData must be available when needed. • C is for ConfidentialityData cannot be disclosed to unauthorized individuals / systems.

8. Security Development Lifecycle (SDL) • Trustworthy Computing – Directive issued by Bill Gates, January 2002. • Encapsulated “S3+C”: Security (and privacy) by design; Security (and privacy) by default; Security (and privacy) in deployment; Communications. • Set of policies, processes, tools, resources. • Example tool: SDL Process Template for VSTS.

9. So Just What’s So Good about theSDL Process Template for VSTS? • Installs SDL requirements as work items. • Includes SDL-based check-in policies. • Customizes security bugs and queries. • Includes extensive SDL how-to and guidance documentation. • Generates auditable Final Security Review report • Accommodates third-party tool integration, e.g. the SDL Threat ModelingTool. • Includes project plans and security risk assessment templates.

10. SDL Mandatory Security Activities in a Traditional (or should that be Legacy) Software Development Lifecycle

11. A New Process: SDL + Agile • SDL predates Agile • Adaptation involves identifying three requirement categories: • One-Time • Every-Sprint • Bucket

12. Optimizing Secure Software Development

13. Four levels of business maturity

14. The Classic Saltzer and Schroeder Design Principles • Open design: Assume the attackers have the sources and the specs. • Fail-safe defaults: Fail closed; no single point of failure. • Least privilege: No more privileges than what is needed. • Economy of mechanism: Keep it simple, stupid. • Separation of privileges: Don’t permit an operation based on a single condition. • Total mediation: Check everything, every time. • Least common mechanism: Beware of shared resources. • Psychological acceptability: Will they use it?

15. Security Properties • Confidentiality: Data is only available to the people intended to access it. • Integrity: Data and system resources are only changed in appropriate ways by appropriate people. • Availability: Systems are ready when needed and perform acceptably. • Authentication: The identity of users is established (or you’re willing to accept anonymous users). • Authorization: Users are explicitly allowed or denied access to resources. • Non-repudiation: Users can’t perform an action and later deny performing it.

16. Threat Types - S.T.R.I.D.E. • Spoofing • Tampering • Repudiation • Information Disclosure • Denial of Service • Elevation of Privilege

17. Elevation of Privilege (EoP)Card Game

18. Examples • http://mycodehere.blogspot.com/2011/01/elevation-of-privilege-revisited.html

19. Spoofing • Spoofing describes any threat allowing an attacker to:Pretend to be someone or something else. • Threat against: Authentication. • Example: “Phishing”

20. Tampering • Tampering describes any threat allowing an attacker to:Alter or destroy data, where this would normally be disallowed by the application. • Threat against: Integrity. • Tampering attacks can be directed against static data files or network packets.

21. Repudiation • Repudiation describes any threat allowing an attacker to:Perform an action, then deny that they ever did it. • Threat against: Non-repudiation. • Mitigation example: secure log file with time stamps.

22. Information Disclosure • Information Disclosure describes any threat allowing an attacker to:Expose information to someone not authorised to see it. • Threat against: Confidentiality. • Can occur with static data files as well as network packets.

23. Denial of Service • Denial of Service describes any threat allowing an attacker to:Degrade or deny service to users. • Threat against: Availability. • Examples: crash or flood your server.

24. Elevation of Privilege • Elevation of Privilege describes any threat allowing an attacker to:Gain privileges they would not normally have. • Threat against: Authorization. • Example:buffer overflow in an app running as SYSTEM - lets attacker run arbitrary code at a very high privilege level. • Mitigation: principle of least privilege.

25. http://google-gruyere.appspot.com/

26. Auntie Beeb's Virus

27. Your Password Sucks

28. Threat Modelling • http://msdn.microsoft.com/en-us/magazine/cc163519.aspx • Threat modelling is an integral part of the Security Development Lifecycle. • Start with a Data Flow Diagram.

29. Data Flow Diagram Symbols • Data flow: One way arrow • Data store: Two parallel horizontal lines • Process: Circle • Multi-process: Two concentric circles • Interactors: Rectangle • Trust boundary: Dotted line

30. Threats Affecting Elements

31. Analyzer Database • Let's say you need a system to collect the accounting files from your sales force, compute sales data on your database server, and produce weekly reports. • We'll call the system the Analyzer Database. • The goal is fairly simple: getting files from a set of systems and performing some analysis of the files on a centralized server. • There are many obvious potential threats to this system, and many of them come from the implicit security requirements of the problem statement. • The collection process alone raises a number of questions. • Collecting information means moving it from one place to another. • How are you going to secure it in transit? • You'll be manipulating accounting files, which by their very nature are sensitive and often subject to legal requirements. • And you'll need to identify a specific group of people—the sales force. • How will you know them?

32. An Initial DFD for theAnalyzer Database 

33. General Rules for a DFD • First, be careful of magic data sources or sinks: data isn't created out of thin air. • Second, beware of psychokinesis as a data transport. • Third, collapse similar elements within a single trust boundary into a single element for modelling purposes. • Fourth, be careful when modelling details on either side of a trust boundary.

34. A Better DFD

35. Analyzing Data Flows

36. Analyzing Data Stores

37. Analyzing Processes

38. Mitigations • Mitigate a threat with a strong, well-understood solution. • Example: strong cryptography against Information Disclosure threats. • Q1: can the technology be used to mitigate the threat? • Q2: would it actually be used in the given scenario?

39. Attack Patterns • The manifestation of one or more threats in the context of some specific technology. • Example: strcpy in C may let an attacker input long strings to corrupt program memory, allowing arbitrary code execution. • Same vulnerability may be used in other ways.