Understanding and evaluating risk to information assets in your software projects

Size: px

Start display at page:

Download "Understanding and evaluating risk to information assets in your software projects"

Eleanore Stewart
8 years ago
Views:

1 Understanding and evaluating risk to information assets in your software projects ugh.. what a mouthful Dana Epp Windows Security MVP

3 Who am I?

4 Microsoft Windows Security MVP

5 Information Security Professional

6 Computer Security Software Architect

7 Why am I here?

9 It s all about the data

10 DON T FOOL YOURSELF! Businesses care about the information... not the machines or software that it runs on.

11 So. Who cares?

12 You should.

13 Legal liability

14 Privacy legislation

15 It s the right thing to do

16 Ugh. Security sucks.

17 You re looking at it all wrong

18 Security is about risk mitigation, NOT risk avoidance.

19 It is a business problem, NOT a technological one.

20 Side note...

21 Secure software helps reduce unnecessary risk to information assets

22 Where does secure software fit?

23 Ya. Ya. Ya. But...

24 Software development should build secure software to meet corporate security objectives.

25 View Security through CIA Triad

26 So let s talk tech.

28 Secure by Design Secure by Default Secure in Deployment

29 Principles in SD 3 Reduce attack surface Use secure defaults Use defence in depth Use least privilege Assume external systems are insecure Plan on failure Fail securely Security through obscurity... isn t. Don t mix code and data

31 You cannot build secure systems until you know the threats to which you are susceptible to.

32 Threat Modeling

33 The Steps in Threat Modeling Brainstorm the known threats to the system. Rank the threats by decreasing risk. Choose how to respond to the threats. Choose techniques to mitigate the threats. Choose the appropriate technologies from the identified techniques.

34 What is a threat? A threat to a system is a potential event that will have an unwelcome consequence if it becomes an attack.

35 What is a vulnerability? A vulnerability is a weakness in a system, such as a coding bug or a design flaw.

36 What about attacks and motives? An attack occurs when an attacker has a motive, or a reason to attack, and takes advantage of a vulnerability.

37 Things to consider when Brainstorming Which assets need protecting? What value are the assets? To what threats are the assets susceptible? How should you prioritize the threats? How do you mitigate the threats? Address architecture and implementation

38 Core assets to consider Configuration data Authentication data Persistent data Data on the wire State data Temporary data

39 Threat loot Asset Vulnerability

40 Mitigation Techniques loot

41 The STRIDE Threat Model Spoofing identity Attacker obtains something that enables authentication Tampering with data Unauthorized change made to stored or in-transit information Repudiation Performing an illegal operation in a system that lacks the ability to trace such operations Information disclosure Exposing critical information to unauthorized individuals Denial of Service (DoS) Denies service to others Elevation of privileges Attacker exploits a weakness to gain greater privileges on a system than were intended

42 Ranking and Prioritizing Threats Chance of attack occurring 1 = high 10 = low How much effort/cost/time is needed to launch the attack? What is the cost/damage if it occurs? 1 = little 10 = massive RISK = Damage / Chance Goal is to reduce risk Do high risk items first

43 How to Respond to Threats 1. Do nothing. 2. Inform the user of the threat. 3. Remove the problem. 4. Fix the problem.

44 Threat Mitigation Techniques: Spoofing Authentication Protect secrets Don t store secrets

45 Threat Mitigation Techniques: Tampering Authorization Hashes Message Authentication Codes (MAC) Digital signatures Tamper-resistant protocols

46 Threat Mitigation Techniques: Repudiation Digital signatures Timestamps Audit trails

47 Threat Mitigation Techniques: Information disclosure Authorization Privacy-enhanced protocols Encryption Protect secrets Don t store secrets

48 Threat Mitigation Techniques: Denial of Service Authentication Authorization Filtering Throttling Quality of Service (QoS)

49 Threat Mitigation Techniques: Elevation of privileges Run with least privileges

50 Security Techniques: Authentication Basic Digest Forms-based Passport Windows Auth NTLM Kerberos v5 X.509 certs IPSec RADIUS

51 Security Techniques: Authorization Access Control Lists (ACL) Privileges IP restrictions Server-specific permissions

52 Side note...

53 Security Techniques: Tamper resistance SSL/TLS IPSec DCOM and RPC EFS (Encrypted File System)

54 Security Techniques: Privacy Encryption Hashes MACs Digital Signatures

55 Security Techniques: DoS Mitigation Filtering Similar to packet filtering Throttling Limiting the number of connections Quality of Service Provide preferential treatment for specific types of traffic

56 Security Techniques: Least Privilege Have applications run with JUST enough privileges to get the job done, and no more. As long as the job gets done, users will never know you are using least privilege unless they do something they aren t SUPPOSED to do!

57 Defense in Depth Assume external systems are insecure We re secure, we have a firewall *ugh* Assume your code is the last thing standing Plan on failure More layers of security means more work to compromise a target Threat risk goes down as threat difficulty goes up Never depend on security through obscurity

58 Don t trust user input Must validate data as it crosses between untrusted and trusted environments Most vulnerabilities rely on malicious input Don t rely on client side validation Hacker tools exist to bypass client validation All user input is bad until proven otherwise Use regular expressions to check Don t check for invalid data, check for valid data and reject anything else

59 Secure Failures and Defaults Plan on Failure (Fail securely) Failure code path should be most secure Verify success, not failure Don t log detailed failure errors to the client Plan on Ignorance (Use secure defaults) Create solutions in their most secure state, and let users turn off security as needed Don t rely on a user to turn off a feature they don t need

60 QUESTIONS?

61 Break.

62 Group Therapy

63 Project: Create Person Management System for Vancouver s Battered Wife Shelter

64 Discussion.

65 Dana Epp Windows Security MVP Blog: Personal Work

Security and Privacy in Cloud Computing

Security and Privacy in Cloud Computing Ragib Hasan Johns Hopkins University en.600.412 Spring 2010 Lecture 2 02/01/2010 Threats, vulnerabilities, and enemies Goal Learn the cloud computing threat model