Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

1. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 1 BUILDING SECURE SOFTWARE APPLICATIONS An introduction to SSDLC for web and mobile applications robertGrupe, CISSP, CSSLP, PE, PMP version: 2017-06-21 Tags :: SSDLC, Application, Software, Security, Development, AppSec, DevOps, DevSecOps OWASP, Agile, Kanban, Scrum, Best Practices, Feature Driven Development, FDD, Test Driven Development , TDD

2. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 2 Contents • Threats and Impacts of Insecurity • Risks & Controls • Secure Application Development Process: SSDLC • Reducing Risks: Secure-SDLC & Testing

4. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 4 US Data Breach Costs per person/record • Data Breaches Increasing Every Year • Despite mature IDS & vulnerability prevention tools and techniques • Increased spending on security • Top Industries Cost (increasing remediation consequences) • 1. Healthcare $233 • 2. Finance $215 • 3. Pharmaceutical $207 • Top Causes • 41% Malicious attack • 33% Human Factor • 26% System glitch

5. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 5 Critical Data Breaches Analysis • Attack Types • 76% weak or stolen credentials • 29% social engineering • 13% privilege use or misuse • Other: 52% hacking, 40% malware, 35% physical • Malicious Actors Types • 14% insiders • 7% multiple actors • 1% business partners • Other: 92% external (50% criminals,19% foreign states (e.g. NK, etc) • Commonalities • 75% are considered opportunistic attacks • 78% of initial intrusions rated as low difficulty • 66% took months or more to discover

6. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 6 Top Web Application Vulnerabilities • Praetorian Study of Penetration Tests and • 66% Weak domain user passwords (a root cause of compromise) • 64% Broadcast name resolution poisoning (aka WPAD) • 61% Local administrator attacks (aka Pass the Hash) • 56% Cleartext passwords stored in memory (aka Mimikatz) • 52% Insufficient network access controls

7. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 7 The Need for Secure Software Development Life Cycle (SSDL) • 40% of breaches occur due to hacking (i.e. successful exploitation of a software vulnerability) • Responsible for 90% of the compromised records • Bad News: >half applications found with vulnerabilities • applications fail to achieve compliance on 1st submission (OWASP Top 10, list of critical web application errors) • 56% of outsourced applications • 54% of internal developed applications • Good News • >80% achieve an acceptable security quality within 1 month

8. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 8 Top Vulnerability Categories Vendor Supplied Web Application • 79% Information Leakage • 71% Cross-Site Scripting (XSS) • 67% Cryptographic Issues • 67% Directory Traversal • 67% CRLF Injection • 51% Time and State • 48% Insufficient Input Validation • 40% SQL Injection • 35% API Abuse • 34% Credential Management • 23% Encapsulation • 21% OS Command Injection • 19% Session Fixation • 18% Race Conditions • 11% Error Handling

9. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 9 Minimizing Data Exposure • Users and credentials significant vulnerability that can’t be addressed by technical protection solutions alone • Protecting critical data access, privileges, and credentials • Usability design to minimize unintended data exposure • Administrative processes to minimize potential abuse

10. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 10 The Cost of Bad SW Testing Introduced/ Detected Rqmnts Design Dev Sys Test Prod. Requirements 1× 3× 5–10× 10× 10–100× Architecture - 1× 10× 15× 25–100× Construction - - 1× 10× 10–25× “Code Complete”, Steve McConnell, Microsoft Press NIST US Study Software bugs cost $59.5 billion annually More than 1/3 of this cost could be avoided if better software testing was performed.

11. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 11 Costs of Delayed Vulnerability Detection Cost to Fix Defects • Not to mention potential… • Regulatory fines • Legal Regress • Reputation damage • Business loss • Therefore: Primary AppSec Objective Should Be • to minimize vulnerabilities during design and coding (proactive) • not just detect and fix prior to release in Testing (reactive) • to minimize project impact costs • to minimize production fix costs and liability exposure due from ‘should-have-known’ Coding $80 94X savings Build $240 31X savings Test $960 7X savings Production $7,600 *

12. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 12 Why AppSec is important and need for SSDLC • Compliance: legal & regulatory requirements to provide business services online • Federal & states Laws: personal data privacy & business licensing • PCI: Payment card transactions • HIPAA: Heath Care Information • SOX: Publicly traded companies (or plan for IPO) • Trust: Customer Specific Requirements (protecting their systems, data, and reputations): • DoD, Federal agencies, etc. • Commercial supplier/partner • Business Continuity • Minimize malicious disruptions • Data loss protection • 92% of organization vulnerabilities through Internet applications

14. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 14 The first little pig built his house out of straw… No S-SDLC: Code, Release, & Hope • Project Execution without S-SDLC • No IT-Security involvement in estimation, scheduling, or delivery. • Potential Outcome after 1st production release • Hacker discovers vulnerabilities and compromises application • Data Breach with PII and PHI posted and sold • Company impacts • $600+MM fine compliance fines • $$MM’s for remediation and communications • Civil lawsuits to company and individuals • Unknown lost new business opportunities • Reduced customer renewals • Company stock shares lost value (company bonuses) • Personal impacts • Project and Program managers and their managers termination • Involved in subsequent legal proceedings • Lost professional reputation

15. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 15 The second little pig built his house out of wood… Minimum Security: Final Phase Security Testing • Risk Assessment at beginning of project • Too little information to properly evaluate • (Especially when using Agile) • Relies on information provided by non-security experts • End of Project: Pen Testing • Delays caused by resolving found defects • 2 weeks to run test, 1+ weeks to remediate • Results in avoidable Risk Acceptances due to time and budget constraints • Potential Outcome • Hacker discovers vulnerabilities and compromises system • user management design flaw • Accepted known risks • Company impacts - same as #1 • Personal impacts • IRM and Executives professional reputations

16. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 16 Can’t just rely on periodic spot checking • Periodic Audit and Fix • Few man-days of ethical hacking FOR man-years of dev coding • Business logic flaws (can’t test of unknown by tester) • Code flaws • Security errors • PEN Testing • against known vulnerabilities (OWASP) • 80-90%?? of app coverage • Easily overlooks privileged data access validation • Just before release • but not enough time to address properly, not funding to resolve the causing architecture issues • Maybe a couple times throughout year in production • But attackers have 24x7x365

17. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 17 But the third little pig built his house with bricks… S-SDLC with parallel security verifications • Security involved throughout development • Identified & estimate included security • Design • Coding • Testing • Outcomes • More accurate project cost and schedule estimates • Faster development (re-useable requirements, tools, and processes) • Final QA: Minimal release disruptions • Hackers unable to find easily exploitable/known vulnerabilities • But if breach… • No compliance fines • Positive company PR: lessons learned - prevention and response

19. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 19 Regulatory Best Practice Requirements PCI DSS Requirements Testing Procedures Guidance 6.5 Address common coding vulnerabilities in software-development processes as follows: Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. Develop applications based on secure coding guidelines. Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements. 6.5.a Examine software-development policies and procedures to verify that up-to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance. The application layer is high-risk and may be targeted by both internal and external threats. Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding practices as applicable to the particular technology in their environment. Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Training for developers may be provided in-house or by third parties and should be applicable for technology used. As industry-accepted secure coding practices change, organizational coding practices and developer training should likewise be updated to address new threats—for example, memory scraping attacks. The vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum baseline. It is up to the organization to remain up to date with vulnerability trends and incorporate appropriate measures into their secure coding practices. 6.5.b Examine records of training to verify that software developers receive up-to-date training on secure coding techniques at least annually, including how to avoid common coding vulnerabilities. 6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: • Example: Payment Card Industry (PCI)

20. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 20 Open Web Application Security Project (OWASP) • A 501c3 not-for-profit • worldwide charitable organization focused on improving the security of software. • Mission is to make application security visible • So that people and organizations can make informed decisions about true application security risks • Everyone is welcomed • to participate, and • all of materials are available under free and open software licenses.

21. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 21 OWASP Top 10 • Not a standard… OWASP Top 10 is an Awareness Document • Was probably 3rd or 4th OWASP project, after • Developers Guide • WebGoat • Maybe WebScarab ?? First developed in 2003 • 2003, 2004, 2007, 2010, 2013, 2017 Released

22. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 22 OWASP Risk Rating Methodology Threat Agent Attack Vector Weakness Prevalence Weakness Detectability Technical Impact Business Impact ? Easy Widespread Easy Severe ?Average Common Average Moderate Difficult Uncommon Difficult Minor 1 2 2 1 1.66 * 1 1.66 weighted risk rating Injection Example 1 2 3

23. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 23 OWASP Top 10: 2010 OWASP Top 10: 2013 2010-A1 – Injection 2013-A1 – Injection 2010-A2 – Cross Site Scripting (XSS) 2013-A2 – Broken Authentication and Session Management 2010-A3 – Broken Authentication and Session Management 2013-A3 – Cross Site Scripting (XSS) 2010-A4 – Insecure Direct Object References 2013-A4 – Insecure Direct Object References 2010-A5 – Cross Site Request Forgery (CSRF) 2013-A5 – Security Misconfiguration 2010-A6 – Security Misconfiguration 2013-A6 – Sensitive Data Exposure 2010-A7 – Insecure Cryptographic Storage 2013-A7 – Missing Function Level Access Control 2010-A8 – Failure to Restrict URL Access 2013-A8 – Cross-Site Request Forgery (CSRF) 2010-A9 – Insufficient Transport Layer Protection 2013-A9 – Using Known Vulnerable Components (NEW) 2010-A10 – Unvalidated Redirects and Forwards (NEW) 2013-A10 – Unvalidated Redirects and Forwards 3 Primary Changes:  Merged: 2010-A7 and 2010-A9 -> 2013-A6  Added New 2013-A9: Using Known Vulnerable Components  2010-A8 broadened to 2013-A7 Changes over Time

25. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 25 OWASP Top Ten Proactive Controls 2016 C1: Verify for Security Early and Often C2: Parameterize Queries C3: Encode Data C4: Validate All Inputs C5: Implement Identity and Authentication Controls C6: Implement Appropriate Access Controls C7: Protect Data C8: Implement Logging and Intrusion Detection C9: Leverage Security Frameworks and Libraries C10: Error and Exception Handling

28. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 28 Your Metrics Pen Test Defect Tracking • Metric Quality Problems • Not all applications are tested • Limited staffing, only test some of requests • Each new/release is not tested • Annual testing only for selected • QA is not a mirror of production • Result inconsistencies • If improve rigor of testing (improve frequency and depth through automation) •Metrics will suffer (find more defects) • Frequency of tests is not uniform • If decrease frequency of testing, then metrics will improve (less defects found)

32. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 32 Secure Software Development Life Cycle (SSDLC) Objectives & Benefits • Regulatory: • Reduce regulatory compliance auditing time and effort • Common documented and logged process • Risk • Reduce risk and potential business disruptions from • Malicious data breach • Accidental misuse or malicious attacks • Proficiency • Reduce development time to find and fix vulnerabilities • Improve secure application developer and testing skills

33. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 33 Requirements (Scoping) Design Implementation (Development) Verification (Test) Release Secure Software Development Life Cycle • AppSec Requirements (User Stories with Acceptance Criteria) • Security & Regulatory Risk Assessment • Frameworks Patterns • Analyze Attack Surface • Threat Modeling • Approved Tools • Deprecate Unsafe Functions • Static Analysis • Unit Tests/ User Story Acceptance • Dynamic Analysis • Fuzz Testing • Attack Surface Review • Penetration Testing • Deferred Defects Risk Acceptance • Go/No-Go Response • Security Incident Response Plan Retire • Decommissioning Plan Select Design Develop Verify Release Agile

35. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 35 Agile: Scrumban FDD* • Kanban workflow† • Scrum development Ideas Features w/User Stories Design Dev Test Static Test Dynamic Final Approval Release WIP Limit * Feature Driven Development † Adaptive Software Development

36. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 36 DevOps with Agile, CI, and CD Plan Code Build Test Release Deploy Operate Dev Ops Continuous Delivery Continuous Integration Agile Development

37. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 37 DevOps Dev • Plan: Requirements, Architecture, Schedule • Create: Design, Coding, Build • Verify: Test • Package: Pre-Production Staging Ops • Release: Coordinating, Deploying • Configure: Infrastructure, Applications • Monitor: Performance, Use, Metrics DevOps Collaboration of software delivery teams: • Developers; • Operations; • Quality Assurance: Testers • Management; • ... etc. Continuous Development automate delivery, focuses on • Bringing together different processes; • Executing them more quickly and more frequently.

38. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 38 SSDLC with DevOps Security Feature Driven Development • User Stories • Assess Risks • Frameworks/Patterns • Attack Analysis • Threat Modeling • Approved Tools • Deprecate Functions • Static Analysis • Unit Tests • Dynamic Analysis • Fuzz Testing • Attack Review • Penetration Testing • Risk Acceptance • Go/No-Go • Logs • Alerts • Management • Usage • Changes • Vulnerabilities • Dashboards & Reports

39. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 39 Agile: Features Program Management • Backlog: Product(s) Program Management • Development: Scrum (or could be Kanban) Ideas Business Case Approval & Priority Features Detailing Features Completed Security Evaluation Features Ready Features In Work WIP Limit Initial draft Rational for prioritization Approval to proceed US detailing US’ done Sec Rqmnts & Pen Test ? Y/N Ready for team(s) In team backlogs

40. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 40 Automation AppSec Test Harness Security Code Reviews STAT: Static AppSec Testing Defect and Task Tracker DAST: Dynamic AppSec Testing Manual Interactive AppSec Testing Vulnerability Test Manager Security Penetration (Pen) Testing App Svr RASP: Responsive Application Security Protection AppSec Rqmnts QA Tests

41. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 41 DevSecOps Security Test Driven Development • Threat Analysis • CI Training • SAST in IDE • SAST in build mgmt • Automated Security Requirements QA • DAST • RASP • SIEM • Secure Code Review • Fuzzing (PenT) • Bug Bounty

43. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 43 Requirements (Scoping) Design Implementation (Development) Verification (Test) Release Secure Software Development Life Cycle • AppSec Requirements (User Stories with Acceptance Criteria) • Security & Regulatory Risk Assessment • Frameworks Patterns • Analyze Attack Surface • Threat Modeling • Approved Tools • Deprecate Unsafe Functions • Static Analysis • Unit Tests/ User Story Acceptance • Dynamic Analysis • Fuzz Testing • Attack Surface Review • Penetration Testing • Deferred Defects Risk Acceptance • Go/No-Go Response • Security Incident Response Plan Retire • Decommissioning Plan Select Design Develop Verify Release Agile

44. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 44 AppSec Risk Assessment Core Artifacts • Risk Assessment Inputs 1. Context Diagram • User Roles • Features (Epic User Stories) • Main interactive systems 2. User Roles & Privileges/Permissions Matrix 3. Feature Use Case Process Flow Diagrams • Feature Use Cases of Users for each Feature • Notifications & Messages (with errors information) 4. Data Flow Diagram • Application communications/services: authentication & encryption 5. Data Map • From UI to storage: sensitivity & encryption • Threat Modeling Risk Assessment Output: Security Requirement User Stories • From AppSec Requirements Library (compliance & standards) • From SSDLC based on sensitivity of data and application complexity

47. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 47 Scope & Design 2 Access Roles & Permissions Matrix Role Name Description Permissions Product Requirements External Regular User Default external user X X External Group Manager SAM primary contact X X X Internal User Default internal user X X X X Support User Help Desk, administrate user accounts and change user settings X X X X Application Administrator Administrate all users and settings X X X X X Per Design Service 1, ... Connector for XyZ functionality X X X X X X

49. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 49 Architecture Design 4 Data Flow Diagram • Note: Consider all APIs and Content Delivery Networks (CDNs) + For all connections add: • Communication protocol & • Security used

52. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 52 Calculating How Much You Should Invest Business Risk Exposure & Mitigation • Application Attractiveness (AA=$BMRV*Records) • Black Market Resell Value of Your Data Records • Number of Records • Breach Cost Exposure • Multi-Jurisdiction Fines per Record • Incident Response & Recovery Costs • Lost Business • Your Security Confidence (use as annual probability) • Testing Methodology Coverage (types used in each phase) • NOTE: The problem with AppSec is that its costs aren’t factored into the Solution ROI. Analysis needs to be done as part of Business Case to Identify Exposure, and Mitigation Investment Required (tools, processes, staffing)

53. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 53 Improving Your Application Security • Keep in mind • Periodic Penetration isn’t enough • AppSec isn’t quick, easy, or free • Prerequisites • Select an ISMS framework • Understand your legal & regulatory data protection requirements • Create a Threat Agent and Mis-Use Library • Establish your standard security requirements list • Define your security requirement test cases • Define your S-SDLC: Waterfall, Agile, CI/CD • Design Phase • UI critical data work-flow-diagramming • Critical data storage and communications diagramming • Threat Assessments with Business Team • QA Test Case Scripts • User Acceptance Testing • Secure administration and mis-use UI testing

54. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 54 S-SDLC Dev & Testing • Develop Secure Code • Follow the best practices in OWASP’s Guide to Building Secure Web Applications • https://www.owasp.org/index.php/Guide • And the cheat sheets: https://www.owasp.org/index.php/Cheat_Sheets • Use OWASP’s Application Security Verification Standard as a guide to what an application needs to be secure • https://www.owasp.org/index.php/ASVS • Use standard security components that are a fit for your organization • Use OWASP’s ESAPI as a basis for your standard components • https://www.owasp.org/index.php/ESAPI • Review Your Applications • Have expert SMEs/Mavens review your applications • Leverage OWASP Guidelines • OWASP Code Review Guide: https://www.owasp.org/index.php/Code_Review_Guide • OWASP Testing Guide: https://www.owasp.org/index.php/Testing_Guide

55. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 55 enisa: AppSec Is More People Than tech • Information technology security administrators should expect to devote approximately one-third of their time addressing technical aspects. • The remaining two-thirds should be spent developing policies and procedures, performing security reviews and analyzing risk, addressing contingency planning and promoting security awareness; • Security depends on people more than on technology; • Employees are a far greater threat to information security than outsiders; • Security is like a chain. It is as strong as its weakest link; • The degree of security depends on three factors: • the risk you are willing to take, the • functionality of the system and • the costs you are prepared to pay; • Security is not a status or a snapshot but a running process. • Conclusion • Security administration is a management and NOT a purely technical issue

56. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 56 Recommendations for Your AppSec SSDLC Implementation 1. Evaluate where you are • Start Small: Recognize that this is a journey • OWASP SSAM 2. Make a prioritized plan 3. Microsoft SSDL: stripped down to what you can realistically do 4. Identify your business security requirements 5. Specify your controls (encryption) 6. Make sure you are building with clean tools 7. Document your designs (intake documents) 8. Understand your threats and their motivations • Risk Assessments: think like a malicious attacker 9. Get a Dynamic Testing tool and start to use it

57. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 57 And Finally: Implementation Progress Tracking • OWASP SAMM (Software Assurance Maturity Model) • ~12 month implementation • Additional resourcing staffing and skills (QA for compliance) • OWASP Top 10 • Threat Modeling • Risk Management • Assessment Tools

58. Red7:|:applicationsecurity © Copyright 2017 Robert Grupe. All rights reserved. 58 Finis • Robert Grupe, CSSLP PMP CISSP robert@rgrupe.com +1.314.278.7901 • References • This presentation @ http://rgrupe.com • Microsoft Secure Development Lifecycle @ https://www.microsoft.com/en-us/sdl/ • OWASP @ https://www.owasp.org • Software Assurance Maturity Model (SAMM) • Best Practices: Web & Mobile Applications • Testing Guidance • Reference Sheets • Much more

Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

You are reading a preview.

Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

More Related Content

Similar to Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

More from Robert Grupe, CSSLP CISSP PE PMP

Featured

Related Books

Related Audiobooks