Thursday, January 10, 2008

A Look Inside the Security Development Lifecycle at Microsoft

http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/

This article discusses:Overview of the Security Development Lifecycle
Security in the design and development processes
Threat modeling and testing
Security reviews and responses

Contents

Leadership and Education
The Design Phase
Threat Modeling
The Development Phase
Security Testing
Starting a Security Push
Final Security Reviews
The Security Response
Does SDL Work?

Security Policy Management

http://msdn2.microsoft.com/en-us/library/c1k0eed6(vs.80).aspx

Security policy is the configurable set of rules that the common language runtime follows when determining the permissions to grant to code. The runtime examines identifiable characteristics of the code, such as the Web site or zone where the code originates, to determine the access that code can have to resources. During execution, the runtime ensures that code accesses only the resources that it has been granted permission to access.

Security policy defines several code groups and associates each of them with a set of permissions. Code groups categorize code by characteristics such as its publisher, digital signature, the URL from where it originates, and so on. After all evidence is considered, code is placed into code groups and the resulting permission grant is the total set of permissions associated with every code group that the code obtains membership in. Although the default security policy is suitable for most situations, administrators can modify or customize security policy to tailor it to the specific needs of their organizations. The runtime grants permissions to both assemblies and application domains based on security policy.

In This Section
Security Policy Model
Describes the components of the security policy system.

Permission Grants
Describes how the common language runtime grants permission to code.

Default Security Policy
Describes how security policy is configured by default.

Administering Security Policy
Describes how administrators can view and modify security policy.

How to: Enable Internet Explorer Security Settings for Managed Execution
Describes how Microsoft Internet Explorer security settings affect managed execution.

Related Sections
Security Policy Best Practices
Describes techniques that administrators can use to maintain security policy on a machine or in an enterprise.

Key Security Concepts
Introduces fundamental concepts you must understand before using .NET Framework security.

Permissions
Describes permission objects and how they are used by the runtime.

Code Access Security
Describes .NET Framework code access security in detail and provides instructions for using it in your code.

Security Tools
Lists and briefly describes the security tools included in the .NET Framework.

MS: Group Policy homepage

http://technet.microsoft.com/en-us/windowsserver/grouppolicy/default.aspx

Friday, December 28, 2007

Saturday, November 24, 2007

ms site for security

http://www.microsoft.com/security/portal/sir.aspx

Friday, October 12, 2007

Patterns & practices Security Guidance for .NET Framework 2.0

Summary
This page explains the rationale behind the patterns & practices Security Guidance for .NET Framework 2.0 project and provides an index into the guidance. You can use the guidance referenced on this page to improve both the security of your applications and your approach to building secure applications.
Contents
Overview
Approach
About the ProjectGuidelines
Checklists
Practices at a Glance
Explained
How Tos
Security Engineering
Security Design Guidelines
Threat Modeling
Security Architecture and Design Review
Security Code Review
Security Deployment Review

Overview
The purpose of this project is to provide world-class security guidance for Microsoft .NET Framework 2.0 centered on the following themes:
Security engineering. Security engineering represents the set of life-cycle activities that are proven to produce more secure software.
Application scenarios. Application scenarios represent end-to-end guidance for building and deploying secure software in common user scenarios.
Technical guidance. Technical guidance represents precise, context-specific guidance to solve particular engineering problems.

Approach
The project has adopted the following approach:
Modular guidance. Successful guidance is modular, specific, and accessible. When you have a specific security problem, whether it involves process or technology, you should be able to quickly find guidance that precisely applies and gives you with the set of steps to solve the problem quickly.
Tools integration. The MSF Agile process guidance that ships with Visual Studio 2005 Team System incorporates the patterns & practices security

engineering practices.
Validation. Industry leaders, experts, customers, and product groups and product support teams at Microsoft validate the guidance.

About the Project

In the past few years, Microsoft has made sweeping changes to development processes to ship more secure software. This includes process changes, such as the Secure Windows Initiative and the Trustworthy Computing Release Process, as well as technology initiatives such as managed code. Along the way, we have talked to experts in the industry and learned a lot about developing secure applications. The motivation for this project is to distill the best engineering practices, secure application scenarios, and technology advice into guidance that you can use to make your applications as secure as possible. For more information about the project, see About the Project: patterns & practices Security Guidance for .NET Framework 2.0.

Guidelines

Guideline modules organize key information and explain what to do, why, and how. Guideline modules often have corresponding checklists.
Security Guidelines: .NET Framework 2.0
Security Guidelines: ADO.NET 2.0
Security Guidelines: ASP.NET 2.0

Checklists

Checklists enumerate recommendations as itemized lists. The recommendations within the checklists are typically organized using an information model based on a problem domain.
Security Checklist: .NET Framework 2.0
Security Checklist: ADO.NET 2.0
Security Checklist: ASP.NET 2.0

Practices at a Glance

Practices at a Glance modules are quick answers organized around common tasks and questions.
Security Practices: .NET Framework 2.0 Security Practices at a Glance
Security Practices: ASP.NET 2.0 Security Practices at a Glance

Explained

Explained modules address how things work along with design intentions, extensibility points, and usage scenarios.
Explained: Forms Authentication in ASP.NET 2.0
Explained: Windows Authentication in ASP.NET 2.0

How Tos

How Tos provide step-by-step, task-based guidance.
How To: Configure the Machine Key in ASP.NET 2.0
How To: Connect to SQL Server Using SQL Authentication in ASP.NET 2.0
How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0
How To: Create a Service Account for an ASP.NET 2.0 Application
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA
How To: Improve Security When Hosting Multiple Applications in ASP.NET 2.0
How To: Instrument ASP.NET 2.0 Applications for Security
How To: Prevent Cross-Site Scripting in ASP.NET
How To: Protect Forms Authentication in ASP.NET 2.0
How To: Protect From Injection Attacks in ASP.NET
How To: Protect From SQL Injection in ASP.NET
How To: Use ADAM for Roles in ASP.NET 2.0
How To: Use Authorization Manager (AzMan) with ASP.NET 2.0
How To: Use Code Access Security in ASP.NET 2.0
How To: Use Forms Authentication with Active Directory in ASP.NET 2.0
How To: Use Forms Authentication with Active Directory in Multiple Domains in ASP.NET 2.0
How To: Use Forms Authentication with SQL Server in ASP.NET 2.0
How To: Use Health Monitoring in ASP.NET 2.0
How To: Use Impersonation and Delegation in ASP.NET 2.0
How To: Use Medium Trust in ASP.NET 2.0
How To: Use Membership in ASP.NET 2.0
How To: Use the Network Service Account to Access Resources in ASP.NET
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
How To: Use Regular Expressions to Constrain Input in ASP.NET
How To: Use Role Manager in ASP.NET 2.0
How To: Use Windows Authentication in ASP.NET 2.0

Security Engineering

patterns & practices Security Engineering builds on, refines, and extends core development activities to create security-specific activities.
patterns & practices Security Engineering Index
Security Engineering Explained

Security Design Guidelines

Security design guidelines provide pattern-based recommendations around architecturally significant challenges. See the following security design guidelines resource.
Security Design Guidelines for Web Applications

Threat Modeling

Threat modeling is an engineering technique that can help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk. See the following threat modeling resource.
Threat Modeling Web Applications
Security Architecture and Design Review
Security architecture and design reviews provide question-driven analysis of key application design decisions. See the following security architecture and design review resource.
Security Architecture and Design Review for Web Applications

Security Code Review

Security code reviews provide question-driven analysis of coding practices and implementation. See the following security code review resource.
How To: Perform a Security Code Review for Managed Code (Baseline Activity)
Security Question List: ASP.NET 2.0
Security Question List: Managed Code (.NET Framework 2.0)

Security Deployment Review

Security deployment reviews provide configuration and run-time analysis. See the following security deployment review resource.
How To: Perform a Security Deployment Review for ASP.NET 2.0

Feedback

Provide feedback by using either a Wiki or e-mail:
Wiki. Security guidance feedback page at http://channel9.msdn.com/wiki/default.aspx/Channel9.SecurityGuidanceFeedback
E-mail. Send e-mail to secguide@microsoft.com.

We are particularly interested in feedback regarding the following:
Technical issues specific to our recommendations
Usefulness and usability issues
Technical Support
Technical support for the Microsoft products and technologies referenced in this guidance is provided by Microsoft Support Services. For product support information, see the Microsoft Support Web site at http://support.microsoft.com/.
Community and Newsgroups
Community support is provided in the forums and newsgroups:
MSDN Newsgroups: http://msdn.microsoft.com/newsgroups/default.asp
ASP.NET Forums: http://forums.asp.net/
To get the most benefit, find the newsgroup that corresponds to your technology or problem. For example, if you have a problem with ASP.NET security features, you should use the ASP.NET Security forum.
Contributors and Reviewers
External Contributors and Reviewers: Andy Eunson; Anil John; Akshay Aggarwal; Brian Cowan; Brian Gran, Ascentium Corporation (Threat Modeling); Chris Ullman; Darren Simmonds, Ascentium Corporation (Threat Modeling); David Raphael, Foundstone Professional Services ; Eric Marvets, Dunn Training and Consulting; Frank Heidt; Jan Drake, Ascentium Corporation (Threat Modeling); Jason Taylor, Security Innovation ; Keith Brown, Pluralsight LLC (Threat Modeling); Manoranjan M Paul; Mark Curphey, Foundstone Professional Services; Michael Panciroli, Ascentium Corporation (Threat Modeling); Mrinal Bhao, Infosys Technologies Ltd (Threat Modeling); Pete Coupland, VMC Consulting Corporation (Threat Modeling); Rudolph Araujo, Foundstone Professional Services
Microsoft Contributors and Reviewers: Adam Semel (PSS); Aaron Margosis ; Bradley Millington (ASP.NET); Brian Johnson; Charlie Kaufman (CLR); Corey Ladas (EEG); Dave McPherson; Denny Dayton; Devendra Tiwari; Don Wilits ; Edward Jezierski; Eric Rachner; Erik Olson; Girish Chander; Hao Kung; Jason Hogg; Jonathan Wanagel; Kate Baroni; Kent Sharkey (MSDN); Maarten Van De Bospoort; Mike Downen; Naveen Yajaman; Nobuyuki Akama (MCS); Randy Miller (MSF Agile); Rick Somona; Rico Mariani (CLR); Rob Beck; Shawn Veney (ACE Team); Shai Kariv; Stefan Schackow (ASP.NET); Tom Christian (PSS); Vikas Malhotra (ASP.NET); Wade Mascia (PSS)
Test team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Sameer Tarey, Infosys Technologies Ltd.
Edit team: Nelly Delgado, Microsoft Corporation; Tina Burden McGrayne, TinaTech Inc.
Release Management: Sanjeev Garg, Microsoft Corporation