Starting your Software Security Assurance Program. May 21, 2015 ITARC, Stockholm, Sweden

Transcription

1 Starting your Software Security Assurance Program May 21, 2015 ITARC, Stockholm, Sweden

2 Presenter Max Poliashenko Chief Enterprise Architect Wolters Kluwer, Tax & Accounting Max leads the Enterprise Architecture practice across 15 geographies of WK T&A Division and defines its Technology Strategy as well as oversees the architecture of its software products. He chairs the Architecture Review Board, which performs EA governance Max is active in the IT Architecture community. He has served on IASA Architect Education and Certification committees. Max is IASA Fellow, holds Microsoft Certified Architect and CITA-P certifications, and served on multiple CITA-P and MCA boards

3 Dramatic Changes in IT Security Environments n Security landscape has substantially changed in the recent years: the number of breaches and their financial and reputational impact. n Automated penetration tools are becoming more main stream and attacker s barrier of entry is lower and lower n The corporate IT perimeter is rapidly eroding with data in the Cloud, hybrid deployments, BYOD devices, etc. n The attackers no longer doing it just for fun and bragging but to exploit the compromised assets for financial or political gains n The government agencies are also rapidly expanding security regulation and levels of responsibility of application providers n Average cost of dealing with a compromised record - $1.2K n Many companies are spending millions and billions to raise their security defenses 3

4 Holistic Security Ecosystem Defense in Depth n Infrastructure and Perimeter Firewalls, anti-malware, Intrusion Detection and Prevention systems Secure settings on Routers, Switches n IT Controls User account management, password expiration policies Limitation on privileges and access, on-boarding and off-boarding n Human Behavior Clicking on links with unknown origins Bringing in personal device into workplace and plugging into company network Rogue employee n Physical Access and Devices Physical security of Data Centers Securing company user devices, including mobile, which may have customer data n Application Code the focus of SSA Cross Site Scripting, SQL Injection, Path traversal, misconfigurations, many others Security-conscious SDLC, roles and activities Bugs vs. design defects 4

5 Gartner Shifts Security Focus to Applications Top 10 Strategic Technology Trends for 2015 report: Security-aware application design, dynamic and static application security testing, and runtime application self-protection combined with active contextaware and adaptive access controls are all needed in today's dangerous digital world. This will lead to new models of building security directly into applications. Perimeters and firewalls are no longer enough; every app needs to be selfaware and self-protecting. n Gartner Symposium 5

6 Typical Application Vulnerabilities Broke Authentication and Session Management Ø Included in OWASP Top 10 Ø Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. Ø Scenario: Insider or external attacker gains access to the passwords stored locally. User passwords are not properly encrypted, exposing them to the attacker. Ø Scenario: Application s timeouts aren t set properly. User uses a public computer to access site. Instead of selecting logout the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and accesses user s session and data. 6

7 Typical Application Vulnerabilities Insecure Direct Object Reference Ø Included in OWASP Top 10 Ø An authorized attacker simply changes a parameter value in the request (filename, key, guid, ID, etc.) that directly refers to a system object which the user isn t authorized to access. The system doesn t properly validate the request parameters and doesn t validate authorizations to access the data before sending it back to the user Ø Scenario: An attacker is able to manipulate the file name or path of a file to a file they do not have permission to access. The file is owned by a different customer of the application. The vulnerability enables the attacker to access data in the file of a different customer. 7

8 Typical Application Vulnerabilities SQL Injection Ø A top industry application vulnerability for over 10 years Ø Attack is able to access data in the database by sending SQL commands into the database through application interface. These command can access, modify or delete the data in the database. Ø Scenario: Attacker exploits this vulnerability in an applications that stores PII information. The attacker sends in the SQL commands which cause the application to expose customer or their clients PII data or alter/delete other data in the database 8

9 Most Frequent Application Vulnerabilities Source WhiteHat security report

10 Answer: Software Security Assurance (SSA) Program Enterprise Architecture team can perform stewardship and governance of SSA program, providing it with organizational context: Training Policies and Compliance Strategy and Metrics Secure Architecture Security Standards and Requirements Maintain Security Policies, Standards, Guidelines adopting Industry standards and best practices such as Microsoft SDL, OWASP, etc. Maintain Security Training Curriculum (both online and in-person) specific to SDLC roles: Developers, DBAs, Architects and Security Champions, QA, Product Managers and Scrum Masters Work with Development and PMO to incorporate SSA into Agile Development Process Perform Security reviews of applications Provide reviewer, advisor, and auditor resources Vulnerability Management Environment Hardening Penetration Testing Governance Deployment Construction Verification Code Review Security Testing Architectural Analysis Dedicated Application Security Architects responsible for SSA tools and governance Keep and report on SSA KPIs Maintain security assessment repository 10

11 Risk-based Approach to Application Security Management Application Security Risk Management Asset Inventory Business Impact Assessment Vulnerability Prioritization Enrollment into SSA Status and Progress Measurement Create an application profile template Build an inventory of applications Describe each application Classify applications Determine business impact Prioritize assets Perform Threat Analysis Perform Static and Dynamic Code scanning Perform Security Reviews of highest risk applications Perform external pen and prod tests Enroll high risk applications into SSA program: Identify Security Champions Train in Security the entire team Incorporating Security into SDLC Prioritize vulnerabilities and create remediation Budget for Utilize resources effectively plans to identify and Training, mitigate Tools and risk periodic tests Track progress against remediation plan Perform periodic Security Reviews, Code Scanning and Vulnerability Prioritization

12 Portfolio Risk Assessment Framework (Business & Security) Context Identify Risks Analyze Risks Evaluate Risk Accept Risks Treat Risks Industry and Strategic Context Organizational Context Develop risk management structure and risk criteria What can happen? How can it happen? Determine existing controls Determine likelihood Determine impact Establish Business risk profile Compare against criteria Set risk priorities and tolerances Are we accepting the risk? If yes, then treat/ mitigate risk Identify mitigation options Evaluate mitigating options Prepare/define treatment plans Implement/execute treatment plans Monitoring and Reviews through Assessments Application & Data Context Identify Risks Analyze Risks Evaluate Risk Accept Risks Treat Risks Current Application Portfolio context (Customer) Data context Determine application and data risk evaluation criteria (Threat models and Attack patterns) What can happen? How can it happen? Determine existing application controls and underlying IT general controls Determine likelihood Determine impact Establish Application risk profile for each application Compare against criteria (threat models and attack patterns) Set data and software risk priorities and tolerances Are we accepting the risk? If yes, then treat/ mitigate risk Identify mitigation options Evaluate mitigating options Prepare/define treatment plans Implement/execute treatment plans Business Risk Management Software & Data Risk Assessment 12

13 Application Security Testing Strategy Catalogue Application Assets Evaluate Application Risk RISK = F (Probability X Expected Loss ) Rank Applications Applications are evaluated to determine their risk Based on the risk, different security work flows could apply. Including a combination of Dynamic and Static Analysis techniques. LOW MEDIUM HIGH CRITICAL Pre Prod Scan Annual Prod Test Code Scan on Builds Pre Prod Scan Manual Pen test Annual Prod Test Dev Code Scanning Code Scan on Builds QA Dynamic Scan Pre Prod Scan Manual Pen test Bi-Annual Prod Test Dev Code Scanning Code Scan on Builds QA Dynamic Scan Pre Prod Scan Manual Pen test External Security Test Quarterly Prod Test 13

14 Security Roles and Tools in Dev Teams 14

15 Security Champions n Part time role, filled by Architects or Sr. Developers from the product team n Receive more in-depth security training to become local Security expert n Responsible for reviewing product requirements from Security view point and identifying Security requirements n Responsible for coordinating and tracking security issues for the product and communication with EA SSA team n May perform Threat analysis, Security code scanning and triaging scanned issues 15

16 Security Training n Training is foundation of SSA and aligns with agile goal of contribution from every team member All members of a software development team must receive appropriate training to stay informed about security basics and recent trends in security and privacy. This includes Developers, DBAs, Architects and Security Champions, QA, Product Managers and Scrum Masters n Annual training goals: Software development team members in technical roles must attend at least one unique security training class each year or 4 hours of online/seminar training Development is required to complete online Pluralsight security training EA team will maintain Recommended Security Training Curriculum Online and in-person security classes for Security Champions n Some training sites:

17 Example of Security Training Curriculum Course/Module Name OWASP Top 10 Web Application Security Risks for ASP.NET Hack Yourself First: How to go on the Cyber-Offense Hours Target audience in order of relevance 8 Development, QA, Design, PM 9 QA, Design, Development, PM Level Medium Medium Evaluation notes Recommended as base course for Development. With web concentration of this course we recommend additional modules Basic course from the position of penetration test. Highly recommended Microsoft MTA: Security Fundamentals 5 PM, Design, QA Basic Describes basic security concepts with mostly network, than app security. Prepare for Microsoft Security fundamentals MCP exam Web Security and the OWASP Top 10: The Big Picture What's New in the OWASP Top 10 for Design, PM, QA, Development Basic Foundation course on base concepts of application security. 1 Development, Design, QA Basic Short very recent (2014) course with information on latest changes in app security Introduction to Cryptography in.net 2 Development, Design Advanced Developing and Deploying SQL Server ISV Applications. Modules Security, Testing Enterprise Library Security and Cryptography Application Blocks CompTIA Security+. Modules - Incident Response, User Education, Social Engineering, PKI, Cryptography 1 Development, Design, QA Medium Recommended course for Axcess developers 1 Development Medium While this module is not actively used in Axcess there are many relevant points 2 PMO, PM Medium Describes security processes WCF Design concepts. Module Security 1.5 Development, Design Advanced Required course for Axcess developers SQL Server Fundamentals. Modules Security 1, 2 2 Development, Design, DBA Medium SQL Security 17

18 Security Review Process n 1. Kick-off meeting. The dates for the in-person Security Review are agreed upon. The Dev team sends to the Review Team architecture documentation about the product ZIP d source code or read-only access to the source repository n 2. Step 2: (approx. Week 2) Review Team sends Product team a customized Security questionnaire Product team sends answers to Review Team Call between Review team and Product team in order to review answers and plan visit n 3. Step 3: (approx. Week 2-3) Static and Dynamic code scanning Review team performs Static code vulnerability scan of the source code. Product team gives external authenticated access to their application Test or Staging environment to the Review team. Review team performs Dynamic code vulnerability scan on the environment above. n 4 Step 4: (approx. Week 4) In person review of the product Demo of the latest product release Review of the architecture and important quality attributes Identification of threats and attack vectors Deep dive into potential vulnerabilities found during code scanning and inspections Recap of confirmed vulnerabilities and remediation recommendation with the team Review of Software Security Assurance process that they may want to adopt n 5. Step 5: (approx. Week 5) Report The Review team writes a report identifying the main threats identified and the remediation strategy Product team reviews the report and creates remediation plan for each high and medium risk vulnerability n 6. Step 6: Review Remediation Plan 18

19 Application Security Testing n Static code analysis Static Application Security Testing (SAST) White Box Testing, Inside Out n Dynamic Application Security Testing (DAST) Black Box, Outside In n Interactive Application Security Testing (IAST) Gray Box, combines static and dynamic testing

20 Vulnerability Remediation and Tracking Process n Create internal tracking record describing vulnerability with some required detail information. This document is sensitive and distribution should be limited and controlled. n Mitigation and remediation process is triggered by multiple points in incident response plan and executed separately for each vulnerability identified internally or externally. n Dev team provides remediation approach, dates for vulnerabilities or deferral dates in format specified by EA and infrastructure security. n Dev team report completion of remediation and provide verifiable prove. n EA tracks status of the remediation and updates executive Security dashboard 20

21 SSA Safe Harbor Principles SSA will adhere to Safe Harbor principles in conducting Software Assurance Program to minimize risk of legal exposure due to Security incidents. Those principles are: n Establish Security Policies, Standards and Guidelines n Establish Communication plan n Establish Training plan for all involved personnel n Audit and Monitor compliance 21

22 SSA ROADMAP

23 Capability Maturity Model 23

24 Veracode AppSec Maturity Model Source: 24

25 Example of SSA Capability Maturity Roadmap Capability Year 1 Year 2 Year 3 Product risk assessment including security and privacy 1 ad-hoc 2 reactive 3 proactive Attack surface reduction 1 ad-hoc 2 reactive 3 proactive Threat modeling 1 ad-hoc 2 reactive 3 proactive Approved tools and components 2 reactive, catalog 3 proactive 4 measured Fuzz testing 1 ad-hoc 2 reactive 3 proactive Release certification None 1 ad-hoc 2 reactive Including OP applications 2 reactive 3 - proactive 4 - measured Not-weighted average

26 Example of SSA Capability Maturity Roadmap (continued) Capability Year 2 Year 3 Year 4 Core Security Training 4 measured 5 - optimizing 5 optimizing Annual Security Review 4 measured 5 optimizing 5 optimizing Security Champions 4 measured 5 optimizing 5 optimizing Security Design Requirements validation Static code security review 2- reactive, catch up with existing 2 reactive, selfservice 3 defined, proactive 4 proactive, validated, measured Dynamic product scanning 2 - reactive 3- proactive, prerelease Incident response 2 reactive, RCA 3 defined, policy driven SSA Program planning 3 proactive 4 measured, predictable 4 - measured, controlled 5 optimized, automated 4 measured, controlled 4 measured, controlled 5 - optimizing 26

27 Questions? 27

28 Appendix 28

29 CODE SCANNING TOOLS

30 The Waterfall Approach Requirements Design STATIC ANALYSIS (Dev) AppScan Source Code & Unit Test DYNAMIC ANALYSIS (QA) AppScan Standard AppScan Enterprise Integration PENETRATION TEST (Security) AppScan Standard Manual Testing System Test

31 The Agile Approach AppScan Source (Filtering on High Confidence) Daily Review SPRINT 2-3 weeks AppScan Source AppScan Enterprise/ Standard Product Backlog Sprint Backlog Iteration Product Shipping PENETRATION TEST (Security) AppScan Standard Manual Testing

32 The Agile-Fall Approach Requirements Design AppScan Source AppScan Enterprise/ Standard Integration DYNAMIC ANALYSIS (QA) AppScan Standard AppScan Enterprise System Test PENETRATION TEST (Security) AppScan Standard Manual Testing

33 Manual Static Code Analysis n Manual code testing Proven Expensive, difficult, hard to cover all flows, no guarantee Coverage is critical for security single failure fails system To scale - Automated to automated unit tests n Code review Humans can generalize beyond rules Human time is expensive Not consistent between iterations/releases To scale - Automated to static code analysis

34 Automated Static Code Analysis n Strong points of static code analysis: Scales better Can detect vulnerabilities proactively Can focus on a few key properties with big payoffs Can reuse security specifications across programs Eliminate categories of error vs single error Encourage better development practices n Domains: Inference (program understanding, bug-finding) n Appropriate for legacy code Enforcement (proving absence of bugs) n Most useful when building new systems

35 Static Analysis Security Work Flows AUTO Publish Assessments Build Server AppScan Source For Automation Scan (Auto) Build Team Integration with Build Process (Ant, Make, Maven, TFS, Jenkins, CLI) AppScan Enterprise Server Administration (Source/Reporting) Enterprise Reporting AppScan Enterprise DB AppScan Source DB User Administration Create Shared configuration Files Create Shared filters (Security Policy) Open Published Assessments Publish Assessments Security Team AppScan Source For Analysis Conduct Scans Markup Management Resolve lost sinks Identify lost sources Create custom rules Review triage & assessments Reports & dashboards Managers AppScan Enterprise Reporting View enterprise level metrics, trending and compliance reports (Security Policy) Developers AppScan Source For Remediation For Development Assessment Data (Bundles) Open Defects Scan for High Confidence Findings using Security Policy (configuration files and filters) Lead Developer Champion ** One Champion per Development team AppScan Source For Analysis Conduct Scans Scan (full coverage) Onboard Applications Triage scan results Conduct Scans Source Code & Dependencies 35

36 Dynamic Analysis Security Work Flows Web Application(s) Conduct Scans AppScan Standard Desktop Client Triage findings & Results Verification Conduct Scans Run on-demand or Scheduled Scans Headless & Automated Scans Enterprise Reporting Dynamic Analysis Scanners Scan results AppScan Enterprise Server AppScan Enterprise DB User Administration Conduct Scans Run on-demand or Scheduled Scans Review Results Manage Issues Scan results QA Teams AppScan Enterprise Dynamic User Configure & Conduct Scans, manage issues, review findings Application Test Policy Dynamic Analysis Scanners Security Team Publish AppScan Standard Results AppScan Standard & AppScan Enterprise Dynamic User Conduct Scans, ASE Administration, Create enterprise level metrics, trending and compliance reports Complete Full Coverage Test Policy Manual Pen Test Publish manual findings (CSV file) Application Management Managers Dashboards & Reports AppScan Enterprise Reporting View enterprise level metrics, Application Management and compliance reports Manage Issues Review Results Run Quick Scans Development Teams AppScan Enterprise Dynamic User Run Quick Scans, manage issues, review findings Limited / Input Control Test Policy

37 Example of Risk Assessment Analysis Business Risk Analysis: Product Threat Analysis: 1. Product Name 2. Business Importance Ranking 3. Is Internet Accessible 4. Revenue or # of customers 5. Assets to be protected 6. Business Goals 7. Data Center 8. High Availability solution 9. Backup solution 10. Disaster Recovery solution 11. Do Dev/Test environment contain PII data? 12. PII data encrypted? 13. Has Intellectual Property? 14. Business Risk Ranking 1. Security Attack Vector/Method 2. Threat Actor 3. Event type (CIA) 4. Asset at risk 5. What is Impacted 6. Likelihood of event 7. Severity of Impact 8. Threat Severity 9. Monitoring Process 10. Mitigations 11. Gaps 12. Remediation Plan 37

38 SSA Activities for Each Enrolled Product/Dev Team n All steps require active involvement of product leadership n Assign Team Security Champions Security champion roles should be filled by SMEs from the project team. Responsible for the negotiation, acceptance, and tracking of security and privacy requirements and maintaining clear lines of communication with SSA governance Establish communication and training plan n Conduct Security Training for team and additional training for Champion n Perform Product Business Risk Assessment n Catalog software dependencies, especially Open Source n Run static code analysis scan, triage found issues n Run dynamic code analysis scan, triage found issues n Perform Security Risk Assessment &Threat Modeling (incl. IT Ops). Identify risks w/ mitigations. As a result, create backlog of Security stories, Security bugs & IT Ops gaps n Document results in Security Assessment document n Budget for annual penetration test, training, tools and other SSA activities n Create Incident Response Plan (review it with Legal) 38

39 Security Activities for Each Product Release At Release planning: n Perform Security Threat Surface analysis and plan its reduction: Review and prioritize security backlog, create new stories if needed Review other requirements for security impact Review and prioritize security bugs n QA creates test plans and updates automation scripts to test Security stories & bugs For each Sprint: n Incorporate security standards and guidelines into code reviews n Review security threat vectors n Perform static code analysis n Identify and prioritize security bugs At the end of Release (during Hardening Sprint): n Perform Dynamic security analysis and Fuzz Testing by QA n Conduct and submit security Assessment Survey by security champion n Perform Final Release Security Review (including IT Operations) and certify the Release n Update Security Assessment document and SSA governance repository n Perform external penetration test (at least annually) 39

40 Microsoft Security Development Lifecycle Framework n The Security Development Lifecycle (SDL) is a security assurance process that is focused on software product development. n As a company-wide initiative and a mandatory policy since 2004, the SDL has played a critical role in embedding security and privacy in software and culture at Microsoft. n Combining a holistic and practical approach, the SDL aims to reduce the number and severity of vulnerabilities in software. n The SDL introduces security and privacy throughout all phases of the development process. n The Microsoft SDL is based on three core concepts education, continuous process improvement, and accountability. n Microsoft publish SDL best practices at 40

41 Best industry practices - Microsoft SDL n Team has reviewed best industry practices, consulted with internal and external experts n Microsoft SDL program was selected as battle-tested industry best practice model for TAA Software Security Assurance 41