Security Development Life Cycle Baking Security into Development September 2010.

Slides:



Advertisements
Similar presentations
For SIGAda Conference, 2005 November, Atlanta 1 A New Standards Project on Avoiding Programming Language Vulnerabilities Jim Moore Liaison Representative.
Advertisements

For C Language WG, 2006 March, Berlin 1 A New Standards Project on Avoiding Programming Language Vulnerabilities Jim Moore Liaison Representative from.
SDL in an Agile World MSSD-3 третья по счету конференция, посвященная всестороннему обсуждению популярной и важной темы – минимизация уязвимостей программного.
Now Bill Gates writes “Trustworthy Computing” memo early 2002 “Windows security push” for Windows Server 2003 Security push.
12 November 2009 Bryan Sullivan Senior Security Program Manager, Microsoft SDL.
Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements (ISC)² SecureSDLC May 17, 2012.
Security Controls – What Works
Planning and Managing Information Security Randall Sutton, President Elytra Enterprises Inc. April 4, 2006.
August 9, 2005 UCCSC IT Security at the University of California A New Initiative Jacqueline Craig. Director of Policy Information Resources and.
Security Engineering II. Problem Sources 1.Requirements definitions, omissions, and mistakes 2.System design flaws 3.Hardware implementation flaws, such.
Software Security Testing by Gary McGraw, Bruce Potter presented by Edward Bonver 11/07/2005.
Computer Security: Principles and Practice
Stephen S. Yau CSE , Fall Security Strategies.

Patch Management Strategy
Introduction to Network Defense
1 Business Continuity. 2 Continuity strategy Business impact Incident response Disaster recovery Business continuity.
Resiliency Rules: 7 Steps for Critical Infrastructure Protection.
Information Security Compliance System Owner Training Richard Gadsden Information Security Office Office of the CIO – Information Services Sharon Knowles.
Effective Methods for Software and Systems Integration
SEC835 Database and Web application security Information Security Architecture.
EOSC Generic Application Security Framework
How To Apply Quality Management
Copyright 2005 Welcome to The Great Lakes TL 9000 SIG TL 9000 Requirements Release 3.0 to Release 4.0 Differences Bob Clancy Vice President, BIZPHYX,
CSCE 548 Secure Software Development Risk-Based Security Testing.
CLEANROOM SOFTWARE ENGINEERING.
 Protect customers with more secure software  Reduce the number of vulnerabilities  Reduce the severity of vulnerabilities  Address compliance requirements.
Software Assurance Session 15 INFM 603. Bug hunting vs. vulnerability spotting Bugs are your code not behaving as you designed it. Many can be found by.
Thomas Levy. Agenda 1.Aims: Reducing Cyber Risk 2.Information Risk Management 3.Secure Configuration 4.Network Security 5.Managing User Access 6.Education.
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
Security Development Lifecycle: Changing the Software Development Process to build in Security from the start Eric Bidstrup Ellen Cram Kowalczyk Security.
Version 02U-1 Computer Security: Art and Science1 Penetration Testing by Brad Arkin Scott Stender and Gary McGraw.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
Microsoft Security Development Lifecycle
Web Security for Network and System Administrators1 Chapter 2 Security Processes.
Software Project Management
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Office of Campus Information Security Driving a Security Architecture by Assessing Risk Stefan Wahe Sr. Information Security Analyst.
Principles of Computer Security: CompTIA Security + ® and Beyond, Third Edition © 2012 Principles of Computer Security: CompTIA Security+ ® and Beyond,
Copyright © Microsoft Corp 2006 The Security Development Lifecycle Eric Bidstrup, CISSP Group Program Manager Security Engineering and Communication.
What Causes Software Vulnerabilities? _____________________ ___________ ____________ _______________   flaws in developers own code   flaws resulting.
IS3220 Information Technology Infrastructure Security
By Ramesh Mannava.  Overview  Introduction  10 secure software engineering topics  Agile development with security development activities  Conclusion.
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
How We Got Here PC and Internet changed the rules –Viruses, information sharing, “outside” and “inside” indistinguishable –Vulnerability research for.
INFORMATION ASSURANCE POLICY. Information Assurance Information operations that protect and defend information and information systems by ensuring their.
Configuration Control (Aliases: change control, change management )
CompTIA Security+ Certification Exam SY COMPTIA SECURITY+SY0-401 Q&A is a straight forward,efficient,and effective method of preparing for the new.
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
Computer Security: Principles and Practice First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Chapter 17 – IT Security.
Chapter 13 Network Security Auditing Antivirus Firewalls Authentication Authorization Encryption.
Implementing Trustworthiness – Building and Delivering Secure Software Glenn Pittaway – Trustworthy Computing (TwC), Microsoft Corporation MSSD-3 — третья.
Security Development Lifecycle (SDL) Overview
Tool Support for Testing
CSCE 548 Secure Software Development Risk-Based Security Testing
How To Apply Quality Management
IEEE Std 1074: Standard for Software Lifecycle
The Microsoft® Security Development Lifecycle (SDL)
Microsoft’s Security Strategy
CMGT 245 Education for Service-- snaptutorial.com.
CMGT 431 STUDY Lessons in Excellence--cmgt431study.com.
SEC 210 Education on your terms/tutorialrank.com.
CMGT 245 Teaching Effectively-- snaptutorial.com.
SEC 210 Become Exceptional/ newtonhelp.com. SEC 210 Assignment Emergency Planning And Risk Assessments For more course tutorials visit
Software Assurance Maturity Model
Secure Coding: SDLC Integration Sixfold Path
Software Security.
PSS0 Configuration Management,
Albeado - Enabling Smart Energy
Presentation transcript:

Security Development Life Cycle Baking Security into Development September 2010

The Security Development Life Cycle 2 Source: Microsoft Security Development Lifecycle, 2010

Components Training: Understand fundamentals of secure development and coding – Secure design – Threat modeling – Secure coding and testing – Privacy, risk and best practices 3

Components Requirements: Define functional AND security requirements – Assess SDL applicability in respect to security and privacy implications – Assign SDL responsibilities – Identity SDL tools – Create security/privacy plan 4

Components Design: establish best security practices for project – Does the application design/functionality present vulnerabilities to common threats? – Focus on keeping functionality but reduce attack surface – Predefined prohibitions, e.g., firewall changes, weak cryptography ng.aspx 5

Components Implementation: Detect and remove security and privacy issues early in development – Static code analyzers – Identification of Banned APIs that are difficult to use correctly (e.g., strcpy C routine) – Use secure code libraries – Use operating system “defense in depth” protections, such as address space layout randomization and corrupted heap termination 6

Components Verification: Conduct attack surface analysis and threat modeling – Dynamic analysis tools such as AppScan – Use of fuzzers, e.g., OWASP jBROFuzz, to identify program failure or recovery with random or unexpected results 7

Components Release: Preparing for use of the software – Is there a final security review that tracks the above steps? – Is an exception needed – who approves? – Is there a pre-defined security incident response plan for rollout? – Archive all security documentation 8

Components Response: Ensure development team is available to response to possible security vulnerabilities or privacy issues – Execute security plan, if required 9

Questions Is the Security Development Lifecycle relevant to development at UC Davis? What if the SDL was integrated into IET development? 10