Published on February 10, 2014
1 robertGrupe, CISSP, CSSLP, PE, PMP tags :|: secure application development, appsec, SDLC © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security NON-TECHNICAL WEB APPSEC: WHAT COMES BEFORE PEN TESTING
Implementing web application security process before vulnerability PEN testing. If your app contains data that can be sold on the black market, incurring legal penalties, then you should be concerned with preventing internal user malicious or accidental misuse (that technical vulnerability assessment tools would not find). © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Description
• The Problem: PEN Testing AppSec isn‟t enough • Standard AppSec approaches aren‟t quick or easy • Prerequisites • Select an ISMS framework • Create your legal & regulatory critical data matrix • Create a Threat Agent and Mis-Use Library • Establish your standard security requirements list • Identify your security test cases • Design Phase • UI critical data work-flow-diagramming • Critical data storage and communications diagramming • Threat Assessment with Business Team • QA Test Case Scripts • User Acceptance Testing • Secure administration and mis-use UI testing © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Agenda Quick Start Solution: Foundational Non-Coding AppSec
© Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security THE PROBLEM: APPLICATION DATA ATTACKS
• 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 Red7 :|: Information Security US Data Breach Costs per person/record 2013 Cost of Data Breach Study: Global Analysis, Ponemon Institute © Copyright 2014-02 Robert Grupe. All rights reserved.
• 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. China) ) • Commonalities • 75% are considered opportunistic attacks • 78% of initial intrusions rated as low difficulty • 66% took months or more to discover * Source: Verizon 2013 Data Breach Investigations Report © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Critical Data Breaches Analysis
• Most organization: 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 • 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 © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security AppSec Failing
• 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 © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Minimizing Data Exposure
• 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 enisa European Network and Information Security Agency Risk Management: Implementation principles and Inventories for Risk Management/Risk Assessment methods and tools June 2006. sec 3.1.1 © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security enisa Security more people than tech
Coding $80 94X savings Build $240 31X savings Test $960 7X savings Production $7,600 • 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‟ * Source: IBM Global Business Services industry standards © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Costs of Delayed Vulnerability Detection Cost to Fix Defects
© Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security FULL APPSEC CHALLENGES: IMPLEMENTATION ISN‟T QUICK OR EASY
• Open Web Application Security Project (OWASP) • OWASP Top 10 • Threat Modeling • Risk Management • Assessment Tools • OWASP SAMM (Software Assurance Maturity Model) • ~12 month implementation • Additional staffing and skills © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Complete Web AppSec Complexity
• Risk Management Process Threat Modeling uses tools and process that are not obvious to non-security staff • But needs application subject matter experts (SME‟s) to develop • Is time consuming, requiring a security analyst who usually would prefer to be doing pen testing • So it usually doesn‟t get done © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Hard to Engage Staff
• Business Executives Don‟t Understand Summaries • Heat maps - debates over ratings and probabilities • Large charts with many points • Not viewed as a strategic priority • Overhead cost • Probabilities are subjective • CEO isn‟t going to be impressed after a breach to hear that we didn‟t fix a vulnerability because a committee thought it‟s probability low • Better is that based on $X budget, we prioritized to fix as many issues as possible • Rate and priority just by severity if exploited and cost to fix (complexity in hours) © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Difficult to Communication with Business Management
The add technical layers based on funded capabilities © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security QUICK START SOLUTION: FOUNDATIONAL NON-CODING APPSEC
• Leverages non-coding application team members • Product Managers / Business Analysts, UI Designers, Testers © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Web Appsec Foundational
AppSec Program Management © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security PREREQUISITE FOUNDATIONS
• Defining the Security Requirements Library • ITIL Service Definition, Service Management, and Continual Service Improvement Model © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security AppSec Program Management
• Organize your security policies in industry recognized sections • ISO27002:2013 & Related Standards • ISO/IEC 27034 – Application Security (being drafted)- http://www.iso27001security.com/html/27034.html • ISO 27799 - ISO27k for healthcare industry • ISO/IEC 27011 - for telecomms industry • ISO/IEC TR 27015 - for financial services • Others • ITSEC, DITSCAP, TCSEC, ITBPM (DE), ISMS of Japan, ISMS of Korea, ISCS of Korea, COBIT © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Foundational: Select Your ISMS Standard (Information security management system)
• Section 9: Access control • 9.1 Business requirements of access control: policy and procedures • 9.2 User access management: • The allocation of access rights to users should be controlled from initial user registration through to removal of access rights when no longer required, including special restrictions for privileged access rights and the management of passwords ( “secret authentication information”) plus regular reviews and updates of access rights. • 9.3 User responsibilities: • Users should be made aware of their responsibilities towards maintaining effective access controls e.g. choosing strong passwords and keeping them confidential. • 9.4 System and application access control: • Information access should be restricted in accordance with the access control policy e.g. through secure log-on, password management, control over privileged utilities and restricted access to program source code. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security ISO27002:2013 AppSec Considerations 1/4
• Section 10: Cryptography • 10.1 Cryptographic controls: There should be a policy on the use of encryption, plus cryptographic authentication and integrity controls such as digital signatures and message authentication codes, and cryptographic key management. • Section 12: Operations management • 12.1 Operational procedures and responsibilities IT operating responsibilities and procedures should be documented. Changes to IT facilities and systems should be controlled. Capacity and performance should be managed. Development, test and operational systems should be separated. • 12.2 Protection from malware: Use of signed code certificates, anti-virus, application firewalling with IDS. User awareness. • 12.3 Backup: Appropriate backups should be taken and retained in accordance with a backup policy. • 12.4 Logging and monitoring: System user and administrator/operator activities, exceptions, faults and information security events should be logged and protected. Clocks should be synchronized. • 12.5 Control of operational software: Software installation on operational systems should be controlled (including application development frameworks) • 12.6 Technical vulnerability management: Technical vulnerabilities should be patched, and there should be rules in place governing software installation by users. • 12.7 Information systems audit considerations: IT audits should be planned and controlled to minimize adverse effects on production systems, or inappropriate data access. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security ISO27002:2013 AppSec Considerations 2/4
• Section 13 Communications security • 13.1 Network security management: Networks and network services should be secured, for example by segregation. • 13.2 Information transfer: There should be policies, procedures and agreements (e.g. non-disclosure agreements) concerning information transfer to/from third parties, including electronic messaging. • Section 14: System acquisition, development and maintenance • 14.1 Security requirements of information systems: Security control requirements should be analyzed and specified, including web applications and transactions. • 14.2 Security in development and support processes: Rules governing secure software/systems development should be defined as policy. Changes to systems (both applications and operating systems) should be controlled. Software packages should ideally not be modified, and secure system engineering principles should be followed. The development environment should be secured, and outsourced development should be controlled. System security should be tested and acceptance criteria defined to include security aspects. • 14.3 Test data: Test data should be carefully selected/generated and controlled. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security ISO27002:2013 AppSec Considerations 3/4
• Section 15: Supplier relationships • 15.1 Information security in supplier relationships: There should be policies, procedures, awareness etc. to protect the organization‟s information that is accessible to IT outsourcers and other external suppliers throughout the supply chain, agreed within the contracts or agreements. • 15.2 Supplier service delivery management: Service delivery by external suppliers should be monitored, and reviewed/audited against the contracts/agreements. Service changes should be controlled. [Exactly the same point applies to services delivered by internal suppliers, by the way!] • Section 16: Information security incident management • 16.1 Management of information security incidents and improvements: There should be responsibilities and procedures to manage (report, assess, respond to and learn from) information security events, incidents and weaknesses consistently and effectively, and to collect forensic evidence. • Section 17: Information security aspects of business continuity management • 17.1 Information security continuity: The continuity of information security should be planned, implemented and reviewed as an integral part of the organization‟s business continuity management systems. • 17.2 Redundancies: IT facilities should have sufficient redundancy to satisfy availability requirements. • Section 18: Compliance • 18.1 Compliance with legal and contractual requirements: The organization must identify and document its obligations to external authorities and other third parties in relation to information security, including intellectual property, [business] records, privacy/personally identifiable information and cryptography. • 18.2 Information security reviews: The organization‟s information security arrangements should be independently reviewed (audited) and reported to management. Managers should also routinely review employees‟ and systems‟ compliance with security policies, procedures etc. and initiate corrective actions where necessary. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security ISO27002:2013 AppSec Considerations 4/4
• 70% similarities between compliance regulations & security frameworks • HIPAA, NIST, SOX, FISMA, PCI, COBIT, etc. • Common sections in standards (not all in each, but overlapping): • user management, access authorizations, incident management, operations management, security operations • Current regulation effective date • Known future updates and expected dates © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Legal & Compliance Critical Data Matrix
• Legitimate Users • External: End Users/Customers • Internal: Operations • • • • Call center staff Customer support supervisor Administrator Support Manager • Partners • Client Operations users • Developers • Threat Agents • Script Kiddies: experimenting and bragging • Hacktivists: political activists looking to get attention (PR) and disrupt • Private investigators: for media, attorneys, suspicious spouses, etc. • Business competitors • Government agents • Foreign intelligence agents • Cybercriminals • Blackmail company • Identity theft information for resell to be used for fraud • People using other‟s credentials for services and Prescriptions • Ordering supplies and billing to healthcare companies © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Agents & Mis-Use Cases From application owners and SME users
• ISMS Section categorization and numbering • Legal & Regulatory Requirements (state, national, international: based on users and data) • • • • • Personal Data Privacy Personal Health Information (PHI) Financial transactions and information (finance & public traded) Reference number, date, text Non-Compliance & breach penalties (for risk assessment prioritization) • Controls from Industry Best Practices (minimum acceptance criteria) • • • • • NIST SP 800 publications (SP 800-118 Password Management, etc.) OWASP: web applications HI-TRUST: US Healthcare PCI DSS: Finance Etc. • Critical Data Dictionary • Data Elements that have regulatory protection requirements • Description / Definition (name, date-of-birth, member ID?, etc.) • Specifying regulation reference © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Application Security Requirements Library
• Test Case Drafts • Test cases numbering from Security Requirements Library • For traceability mapping • Boundary testing • E.g. Password policies • Weak password, repeat password, very long, sql injection, etc. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Security Tests Library
© Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security DESIGN PHASE
© Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security AppSec Design Phase
• Who: Application SME • Input • Reference: AppSec Critical Data Dictionary • Legitimate Application Users (Actors/Agents) • External Customers • Internal Operations & Support • What: • Identify all current and anticipated new screens with critical data elements input or display • Output: • User flow diagrams (screens/prints when critical data I/O) • • • • • Registration and preferences updates Different tasks Help Password/credentials rests Etc. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Critical Data User Flow Diagramming
• Who: Application Architect • Input • Reference: AppSec Critical Data Dictionary • What: • Identify all critical data-at-rest application storage and transformations • Identify all application I/O communications • Identify all data-at-rest and data-in-motion security protections • Output: • Critical Data I/O and transformation flow diagrams • Within application • With other applications/service • Encryption key management services and processes © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Critical Data Communications Diagramming
• Who • Application Team: product manager (alt. business owner & business analyst), architects, developers, testers, SME users, support) • AppSec SME‟s: Compliance, Architect • Input • AppSec Critical Data Dictionary • Threat Agents Library • Security Requirements Library • Application Critical Data Flow Diagrams (User & Application) • Security Test Cases Library • Output • Application specific Security Test Cases • (validate requirements with threat agents and mis-use cases) • Differences between testing environments (Dev, QA, Alpha, Beta) © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Threat Assessment
• Who • Application Technical Team: Architect, Developers, Testers, Release Management • AppSec: Compliance, Architect, Coding, networking, PEN Testing • Product Manager (alt. business owner/business analyst) • Project Manager • Input • Application specific Security Test Cases • Output • Design or Test Case changes • Project scope/effort changes (prioritization/authorization) © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Design Review
© Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security TESTING PHASE
• Security Usability Tester • Critical Data Security Test Cases • Malicious & Appropriate User Roles • Automation using Selenium • Security Analyst • Application and system vulnerability / PEN testing • Passive & Active Attacks • Tools: OWASP Zed Attack Proxy, etc. © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Testing Phase
Red7 :|: Information Security CODA © Copyright 2014-02 Robert Grupe. All rights reserved.
• • • • Improves application security (proactive vs reactionary) Reduces costs of fixing security issues Leverages existing application team improved analysis & tests Provides critical data mapping for incident response © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security AppSec Beyond PEN Testing
• This Presentation & Further Resources • www.red7managementsolutions.com • Questions, suggestions, & requests • Robert Grupe, CISSP, CSSLP, PE, PMP • firstname.lastname@example.org • +1.314.278.7901 © Copyright 2014-02 Robert Grupe. All rights reserved. Red7 :|: Information Security Finis
Vendor Application Security Testing ... More than half of all breaches come through ... in your running web applications before cyber criminals ...
Be it pen-testing or code ... in Java clear the file before start writing ... start with web application development for a Java Selenium ...
Pen-testing is not everything that ... An advantage of doing appsec full time is the ability to develop real solutions ... Re: Evaluating Pen Testers ...
This article will show you how Cross-site Scripting attacks work and how you can ... Close your doors shut before ... Pen-Testing Tools; Web ...
... and an assortment of information security roles including leading AppSec ... with the Boston Security ... and web services pen testing ...
He leads the small yet exquisite pen-test company called Cure53 and pesters peaceful attendees on various 5th tier conferences with his hastily assembled ...
As for how to reach them the first rule in dealing with management is to come to ... pen-testing and ... in testing new software before ...
A key must be selected before using a ... There are many theories about how the word "cipher" may have come to ... Historical pen and paper ciphers ...
Advertising Programmes Business Solutions +Google About Google Google.com © 2015 - Privacy - Terms. Search; Images; Maps; Play; YouTube; ... Web History ...