1 / 45

Rocky Heckman CISSP MVP Senior Consultant Security and Monitoring Readify

Rocky Heckman CISSP MVP Senior Consultant Security and Monitoring Readify. Security, Privacy and Compliance for the Application Developer. Agenda. Why Developers Should Care A Holistic Approach A Little Background – SDL at Microsoft Building Security & Privacy Checkpoints into Your SDLC.

olinda
Télécharger la présentation

Rocky Heckman CISSP MVP Senior Consultant Security and Monitoring Readify

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rocky Heckman CISSP MVP Senior Consultant Security and Monitoring Readify

  2. Security, Privacy and Compliance for the Application Developer

  3. Agenda • Why Developers Should Care • A Holistic Approach • A Little Background – SDL at Microsoft • Building Security & Privacy Checkpoints into Your SDLC

  4. Agenda • Why Developers Should Care • A Holistic Approach • A Little Background – SDL at Microsoft • Building Security & Privacy Checkpoints into Your SDLC

  5. Why Should You Care? • Privacy and Compliance • Regulatory compliance compelled by the government to protect Personal Identifiable Information • Corporate policy focused on creating a trust worthy relationship with the customer • Security • Attacks increasingly targeting the Application Layer • Attacks increasingly targeting Personal Identifiable Information (privacy data) • Developers play a major role in determining the security and privacy stance of an application

  6. What is PII? Personal Identifiable Information Any information that identifies or can be used to identify, contact, or locate the person to whom such information pertains, or from which identification or contact information of an individual person can be derived. Sensitive information is a subcategory of PII

  7. International Regulations • Sarbanes Oxley, Section 404 (2002) • Privacy and Integrity of financial data in publicly traded corporations • BASELL II • International standards used to measure the viability of a banks capital • HIPAA (1996) • Baseline standards for the confidentiality, integrity and availability of health care information • PCI • Payment Card Industry Security Standard • Gramm-Leachy Bliley Act (GLBA) (1996) • Modernizes financial institutions privacy law • FISMA, BS7799, Safe Harbor Obligations/EU, …

  8. International Regulations • California Senate Bill 1386 (2003) • Confidentiality of PII data stored by organizations that do business in California: • Ensure privacy of customer data at all costs • Disclose all cases where PII has been suspected of being improperly disclosed or acquired by an unauthorized person • Many cases of companies in violation • 26 State Laws and growing… • European Union Data Protective Directive • Each State transposes the Directive into internal law for the state • Personal data may only be transferred to third parties who agree to Directive standards (e.g. Safe Harbor)

  9. ANZ Privacy Regulations • Australian Privacy Act (Private Sector Amendments) • Provides for ten National Privacy Principles (NPPs) • How companies should collect, use, keep secure and disclose PII • 31st January 2006: Attorney-General announces Australian Law Reform Commission to review Privacy Act • Will examine existing Commonwealth, State and Territory laws in light of evolving technology and international practice • Various State Privacy Regimes • New South Wales: Privacy & Personal Information Protection Act 1998 • Victoria: Information Privacy Act 2000

  10. Australian Privacy Complaints http://www.privacy.gov.au/about/complaints/index.html

  11. Regulatory RequirementsCommon Data Lifecycle Data collection obligations: type of data, necessary disclosures and consent Where data goes once you are finished with it How data is stored and managed, accessed and secured 3rd party data sharing: opt-in policies and security How data is used: who should have access and why

  12. Regulatory RequirementsCommon Application Technology Best Practice Confidentiality - Data cannot be viewed by unauthorized individuals Integrity - Data cannot be modified by unauthorized individuals Availability - Data is available for authorized individuals and data owners Access Controls - Support role-based access and revocation of accounts Auditing and Logging - Auditing/logging of relevant events in processes with sensitive data Change Management - Changes to IT that touch PII data are documented and reported

  13. When Best Practice is Not Applied http://www.privacyrights.org/ar/ChronDataBreaches.htm

  14. When Best Practice is Not Applied Breakdown by Volume of Data Breakdown by Number of Incidents

  15. The Importance of Application Security The Gartner Group states: "Today over 70% of attacks against a company's Web site or Web application come at the 'Application Layer' not the Network or System layer." Microsoft Developer Research: "64 percent of developers are not confident in their ability to write secure applications"

  16. Example Threats Against The Application

  17. Example Threats Against The Application SQL Injection Cross-Site Scripting Arithmetic Overflow Path Traversal Denial of Service

  18. Understanding The Attackers

  19. National Interest, Chaos Steal Something of Value / assets Personal Fame, To Embarrass, To Win Curiosity Nothing Understanding The Attackers Spy, Terrorist Thief, Booster, Fence, Classic Criminals Disgruntled Employee Mal-Tech Trespasser Author Vandal, Cyberpunk Anyone Un- intentional HobbyistHacker Script- Kiddie Expert Specialist

  20. Agenda • Why Developers Need to Care • A Holistic Approach • A Little Background – SDL at Microsoft • Building Security & Privacy Checkpoints into Your SDLC

  21. Network Host Application Port blocking Filtering Encryption Updates IIS hardening ACLs CAS Logging Least privilege Account management Validation Hashing Encryption Secrets Mgt. Cookie Mgt. Session Mgt. Error handling Defend the network Spoofed packets, etc. Buffer overflows, illicit paths, etc. Defend the host SQL injection, XSS, input tampering, etc. Defend the application Holistic Approach to Security

  22. Attacker needs to understand only one security issue Defender needs to secure all entry points Attacker has unlimited time Defender works with time and cost constraints Attackers versus Defenders Secure systems are more difficult to use Complex and strong passwords are difficult to remember Users prefer simple passwords Security versus Usability Developers and management think that security does not add any business value Cost of addressing security issues only increasesas software design lifecycle proceeds Security As an Afterthought Do I need security… Holistic Approach Challenges

  23. Requires Process Improvement • Security is not about being “buzzword compliant” • Security Features ≠ Secure Features • Simply “looking for bugs” doesn’t make software secure • You must reduce the chance defects are entered into the design and code • Requires executive commitment and investment • Requires process improvement • Requires education (initial and ongoing)

  24. Agenda • Why Developers Need to Care • A Holistic Approach • A Little Background – SDL at Microsoft • Building Security & Privacy Checkpoints into Your SDLC

  25. Sometime in the mid 1990’s • A developer working on DCOM wrote some simple code to copy the server name from an object activation request • The process listening for object activation requests on a well known port (135) is RPCSS…and it runs as LOCALSYSTEM • The buffer allocated was the max size for a computer name, but nobody ever checked for a buffer overrun…and the rest is history

  26. Copies buffer from the network until ‘\’ char found Sitting on port 135 Buffer Overrun ExampleDCOM Remote Activation (MS03-026) error_status_t _RemoteActivation(..., WCHAR *pwszObjectName, ... ) { *phr = GetServerPath( pwszObjectName, &pwszObjectName); ... } HRESULT GetServerPath(WCHAR *pwszPath, WCHAR **pwszServerPath ){ WCHAR * pwszFinalPath = pwszPath; WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]; hr = GetMachineName(pwszPath, wszMachineName); *pwszServerPath = pwszFinalPath; } HRESULT GetMachineName( WCHAR * pwszPath, WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]) { pwszServerName = wszMachineName; LPWSTR pwszTemp = pwszPath + 2; while ( *pwszTemp != L'\\' ) *pwszServerName++ = *pwszTemp++;... }

  27. Blaster Virus • July 16th 2003 – The Last Stage of Delirium Research Group informs Microsoft of a flaw in DCOM object activation but does not publish technical details • July 25th 2003 – XFocus releases technical details of the flaw • August 11th 2003 – nearly 4000 computers an hour are infected in the first week as un-patched systems are attacked • Ultimately, over 1.5 million computers are infected • 3, 370, 000 PSS calls in Sept ’03 (normal virus volume is 350,000) • “After two decades' worth of Swiss cheese software security, the world's biggest supplier of operating system software has run out of excuses. “ Charles Cooper – CNET • Estimated economic impact: $2 billion

  28. Security Development Lifecycle (SDL) A PROCESS by which Microsoft develops software and defines security requirements and milestones • Mandatory for products that are exposed to meaningful security risk (needs to withstand malicious attacks) • Evolving and new factors, such as privacy, are being added *Steve Lipner, Director of Security Engineering Strategy, Microsoft

  29. Microsoft’s SDL Use SecurityDevelopment Tools & Security Best Dev & Test Practices Create SecurityDocsand ToolsFor Product PrepareSecurityResponsePlan Security Push FinalSecurity Review Security Servicing &ResponseExecution Security Training Security Arch & Attack SurfaceReview Security Kickoff& Register withSWI Security DesignBest Practices Pen Testing ThreatModeling Traditional Microsoft Software Product Development Lifecycle Tasks and Processes Testing and Verification Feature ListsQuality GuidelinesArch DocsSchedules Code Signing A CheckpointExpress Signoff RTM Product SupportService Packs/QFEs SecurityUpdates DesignSpecifications Development of New Code FunctionalSpecifications Bug Fixes Requirements Design Implementation Verification Release Support&Servicing

  30. 55 SQL Server 2000 pre- and post-SDL security bulletins 17 Windows pre- and post-SDL critical and important security bulletins 455 Early Results of the SDL Exchange Server 2000 pre- and post-SDL security bulletins http://msdn.microsoft.com/security/sdl

  31. Why Should You Care? • Security challenge has thus far hit system software • “Target rich” environment • As system software gets better, attackers will seek next weak point • E.g. Customer applications • We are encouraging customers to emulate the SDL or something like it

  32. Agenda • Why Developers Need to Care • A Holistic Approach • A Little Background – SDL at Microsoft • Building Security & Privacy Checkpoints into Your SDLC

  33. Security & Privacy Checkpoints • Goal • Create security and privacy checkpoints into your Software Development Life Cycle (SDLC) • It doesn’t matter what SDLC you adopt • Agile, Waterfall, Spiral etc. • How?? • Create a process that dovetails into your SDLC • The SDL that you adopt will be dependent on the type of applications you create • ISV development shops vs. IT enterprises

  34. SDL Process Inline With SDLC Develop/ Purchase Release/Sustainment SDLC Envision Design Test Pre-ProductionAssessment Post-Production Assessment Application Entry/Risk Assessment Threat Model/Design Review Internal Review SDL EvolutionaryProcess

  35. Pre-ProductionAssessment Post-Production Assessment Application Entry/Risk Assessment Threat Model/Design Review Internal Review Application Entry/Risk Assessment • Key Objectives: • Application Inventory / Security Goals • Determine Application Risk Categorization • High Risk: Compulsory threat model/design review plus white box code review and host level scan • Medium Risk: White box code review and host level scan • Low Risk: Host level scan

  36. Additional Supporting Activities • Resource assignment • Training and education those involved in the SDLC • Threat Modeling (Lead Developers, Architects and Program Management) • Secure Application Development (All Developers) • Application Security Testing (QA, Functional Testers) • Secure Application Deployment (Operations and Production Support)

  37. Pre-ProductionAssessment Post-Production Assessment Application Entry/Risk Assessment Threat Model/Design Review Internal Review Threat Model/Design Review • Key Objectives: • Threat Modeling • Application design to verify compliance with security and privacy standards and best practices • Confidentiality, Integrity and Non-repudiation • Availability • Access Controls - Authentication and Authorization • Auditing and Logging • Change Management

  38. Pre-ProductionAssessment Post-Production Assessment Application Entry/Risk Assessment Threat Model/Design Review Internal Review Internal Review • Key Objectives: • Adherence to security and privacy checklist, policy, guidelines and principles • Use and build tools to scale the problem • Team conducts self code and peer reviews • Specialised (not the developer) attack, penetration and fuzz testing where applicable

  39. Pre-ProductionAssessment Post-Production Assessment Application Entry/Risk Assessment Threat Model/Design Review Internal Review Pre-Production Assessment • Key Objectives: • Low Risk Applications • Host Level Scans can be focused on identifying deployment level issues • High/Medium Risk Applications • Host Level Scan • White Box Code Review

  40. Common Attack Patterns A White Box Code Review May Reveal • Cross Site Scripting Vulnerabilities • SQL Injection • Buffer Overflow • Poor Authorization • Secrets Stored in Clear Text • No Separation of Privilege

  41. Common Deployment Issues • Clear text Communication channels • Weak passwords on services accounts • Use of High privileged accounts • Using SA to connect to DB • Running IIS under Local System account • Weak NTFS permissions • Open Shares on the web server with poor ACL’s • Unpatched Servers

  42. Pre-ProductionAssessment Post-Production Assessment Application Entry/Risk Assessment Threat Model/Design Review Internal Review Post-Production Assessment • Key Objectives: • High/Medium/Low Risk Applications • Host Level Scan • Security and Privacy Response Execution

  43. Conclusions • Continuous improvement of the process • Invest time in upfront activities • Threat Modeling • Design Reviews • Training is imperative (follow SDLC) • Developers • Testers • Production Support

  44. Security seminar follow up… • Security e-forum sitewww.microsoft.com.au/eforum • View On demand web casts of all presentations from this event (tell your work colleagues!) • Online Live chats • Have a live chat with Microsoft’s leading security experts. Check the e-forum site for the Live Chat schedule. • Evaluation forms - we value your feedback! • Need help with your business’ security? • Q7 - register your interest on the eval form if you want to meet with Microsoft / a MS Security Solutions Partner to discuss solutions to address your Security challenges • Fill in your form to go into the draw to win a HP Media Centre PC or Xbox 360

More Related