1. Secure Development With Microsoft .NET
Julian Templeman
Xpertise Training

2. Objectives Review security best practice Introduce Threat Modelling
Explain how to handle sensitive data in .NET applications
Introduce .NET security features
Objectives:
Review security best practice
Introduce Threat Modelling and the Threat Modelling tool
Introduce .NET security features: understand how the .NET Framework helps developers write secure code
Review procedures for handling sensitive data in .NET applications, including user input
Understand the improved support for handling X509 certificates in .NET 2.0
Explain support for XML Encryption and XML Digital Signature
Note: The focus for this session is not to present technical details of APIs and technologies. It is to focus upon the need for a security mindset, and to get people thinking about security. While some details of new Whidbey technologies will be mentioned, these are not the most important points.

3. Agenda Security Best Practice Threat Modelling Handling Data
.NET Framework Security Features

4. Principles To Live By Learn from mistakes Minimize your attack surface
Use "defence in depth"
Use least privilege
Employ secure defaults
Fixing security may impact backward compatibility
Assume external systems are insecure
Learn from mistakes: approach every bug as a learning opportunity, so you don't fall into the same trap again
Minimize your attack interface: number of open sockets/pipes, services running, accounts in admin group, objects with weak ACLs
Use defense in depth: layers of defense, e.g. bank - guards, tellers, safes. You don't want total compromise if a firewall is breached...
Use least privilege: execute with least privilege to get the job done, and no more. Does the application really need admin privilege? Separation of privilege spawns different processes that can handle non-critical tasks as low-privilege principals
Employ secure defaults: turn off features that are rarely used. 80/20 rule. Each enabled feature adds more possibility for a security problem
Fixing security may impact backward compatibility: tightening security may mean older features may not work.. Consider letting users choose compatibility with older versions, or the newer secure (but incompatible) version
Assume external systems are insecure: assume any external system you talk to is a possible source of attack, whether it is an external client or server

5. Principles To Live By Plan on failure Fail to a secure mode
Security features != secure features
Never depend on security through obscurity alone
Don't mix code and data
Fix security issues correctly
Plan on failure: things do go wrong, so be prepared for it
Fail to a secure mode: ensure that data/resources not compromised if applications fail. Deny access by default, and only allow access if checks work
Security features != secure features: adding security features to an application doesn't make it secure
Never depend on security through obscurity alone: always assume an attacker knows what you know
Don't mix code and data: i.e. viruses in attachments, bad macros on spreadsheets. Set defaults so such code doesn't run by default
Fix security issues correctly: once fixed, go looking for similar problems elsewhere in the application. If you see one cockroach, there are probably more... Be open about what you've fixed, or people will assume the worst.

6. Development Security Define secure coding guidelines
Developers must own code security
Control who can check in code
Peer review of new code by security experts
Learn from old bugs
Set the tolerance limit
Keep track of bug metrics
No surprises or Easter eggs...
Define secure coding guidelines: get experts to lay down guidelines that the team has to adhere to. New features in Visual Studio 2005 help make this work at several levels. Examples include the use of FxCop, PREFast and Application Verifier to check code, and the use of enterprise templates to define application architectures.
Developers must own code security: each developer must own the security for their own code, and be prepared to take the responsibility for any security vulnerabilities found.
Control who can check in code: checking in code is a privilege that is granted, maybe after training in good security practice
Peer review of new code by security experts: make sure the reviewers know what they're looking for! It is no use having code reviewed by those who don't have a clue.
Review old bugs: i.e. learn from past mistakes
Set the tolerance limit: no software is perfectly bug free. Decide on the 'good enough' limit.
Keep track of bug metrics: know whether you're coming or going.
No surprises or Easter eggs: you don't have enough time to meet the deadlines, so don't waste time on clever or spurious features.

7. Agenda Security Best Practice Threat Modelling Handling Data
.NET Framework Security Features

8. Threat Modeling Process
1 - Identify Assets
2 - Create Architecture Overview
3 - Decompose Application
4 - Identify Threats
The threat modelling process has six steps:
1) Identify assets - i.e. valuable data and resources
2) Develop an architectural overview - what the application is designed to do (use cases), how you plan to architect and design the application to achieve that functionality, and what technologies are required to implement the design
3) Decompose the application to create a security profile.
4) Identify threats that may affect the system and compromise the assets. Work up from network threats (how does data get through routers and firewalls?), through host threats (patches, files, directories) to application threats
5) Document each threat - description, target, likelihood, techniques used, strategy to manage risk
6) Prioritize the threats
5 - Document Threats
6 - Prioritize Threats

9. Threat Types S T R I D E poofing ampering epudiation
nformation Disclosure
enial of Service
levation of Privilege S T R I D E
Categories of threats can be remembered using the STRIDE acronym:
Spoofing. Attempting to gain access by using a false identity
Tampering. Unauthorized modification of data, either in situ or in transit
Repudiation. Ability of users to deny that they performed an action (i.e. covering tracks)
Information Disclosure. Unwanted exposure of private data, e.g. spyware and trojans
Denial of Service. Making a system or service unavailable
Elevation of privilege. Increasing privilege level in order to perform an operation that wouldn't otherwise be allowed

10. Prioritizing Threats D R E A amage Potential eproducibility
For Each:
High = 3
Medium = 2
Low = 1
xploitability
ffected Users
iscoverability
Microsoft uses the DREAD model as an aid in prioritizing threats:
Damage potential. How great is the damage if the vulnerability is exploited?
Reproducibility. How easy is it to reproduce the attack?
Exploitability. How easy is it to launch an attack?
Affected users. As a rough percentage, how many users are affected? Or how important are the users that are affected?
Discoverability. How easy is it to find the vulnerability?
A score can be assigned to each category, and a cumulative score produced for the threat as a whole. A cumulative value of 5-7 denotes a low risk, while 8-11 denotes medium risk, with scores of 12 or more showing those risks that should be given the highest priority.
Note that many users will always give discoverability the highest rating, since it is hard to foretell how a vulnerability may be discovered.
5-7 Low risk
8-11 Medium risk
High risk

11. Demo
Threat Modeling
Julian Templeman
Xpertise Training

12. Agenda Security Best Practice Threat Modelling Handling Data
.NET Framework Security Features

13. Best Practices Don’t store secrets at all if possible
Because it is hard to do it securely
Store secrets indirectly
E.g. Salted hashes for passwords
Zero memory after use
Stop data being saved in page files and crash dumps
Encrypt long-lived memory data
Validate all input
Don't store secrets at all, if possible, because it is hard to store them securely - if someone gets login access to the system, they can often get at everything.
Where possible, store verifiers instead, e.g. a hash of a password rather than the password itself. Consider using salted hashes - add a random 'salt' value to passwords before hashing so that users with same password get a different hash value This makes it harder to mount dictionary attacks. PKCS (Public Key Cryptography Standard) #5 hashes a salted password a number of times, and it requires lots of effort to crack these by dictionary attacks.
When using secrets in memory, zero the memory once it has been used. This will stop secret data being saved in page files, or in crash dumps if the application crashes.
For long-lived data in memory, encrypt it (but then you have to manage the keys). Two new functions, both part of the DP API in .NET Server 2003, handle this for you - CryptProtectMemory() and CryptUnprotectMemory()

14. The API Helps You... Data Protection API (DPAPI) Isolated Storage ACLs
Per-user automatic encryption of in-memory data
Isolated Storage
Safe local storage per user/assembly
ACLs
Good interaction with Win32 security in .NET 2.0

15. .NET Security Robust, multi-level solution Code verification
Role-based security
Code Access security
Cryptography
Isolated Storage
A high-level overview of the main areas that come under the 'security' banner.
Verification: MSIL is checked at JIT time, and assembly metadata is verified when loaded into the GAC or download cache.
Role-based security is used for authentication and authorization.
Code Access security (CAS) is used for authorization of code.
Cryptography provides a way to hide secret information, and is used to support digital signatures for secure verification of data.
Isolated storage provides a way for untrusted or partially trusted applications to store data on client machines.

16. Controlling Applications
Admin controls policy
Code groups and permission sets
Loader gathers evidence
Who, where, what?
Precise control over execution
Click Once in .NET 2.0
Secure on-demand deployment

17. Summary Reviewed security best practice Introduced Threat Modelling
Explained how to handle sensitive data in .NET applications
Introduced .NET security features
Objectives:
Review security best practice
Introduce Threat Modelling and the Threat Modelling tool
Introduce .NET security features: understand how the .NET Framework helps developers write secure code
Review procedures for handling sensitive data in .NET applications, including user input
Understand the improved support for handling X509 certificates in .NET 2.0
Explain support for XML Encryption and XML Digital Signature
Note: The focus for this session is not to present technical details of APIs and technologies. It is to focus upon the need for a security mindset, and to get people thinking about security. While some details of new Whidbey technologies will be mentioned, these are not the most important points.

18. Resources Writing Secure Code, 2nd Edition Threat Modeling
Howard and LeBlanc, Microsoft Press
Threat Modeling
Swiderski and Snyder, Microsoft Press
Threat Modeling Tool
From the Download Center
Microsoft Security Developer Centre

19. Microsoft Technical Roadshow 2005
2-days of in-depth technology information
Birmingham – May
Harrogate – 1-2 June
London – 7-8 June
Register now at:

20. www.microsoft.com/uk/security www.microsoft.com/uk/technet/learning
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.