1. 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
2. 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
3. ⢠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
4. Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
THE PROBLEM:
APPLICATION DATA ATTACKS
5. ⢠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.
6. ⢠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
7. ⢠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
8. ⢠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
9. ⢠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
10. 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
11. Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
FULL APPSEC CHALLENGES:
IMPLEMENTATION ISNâT
QUICK OR EASY
12. ⢠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
13. ⢠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
14. ⢠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
15. 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
16. ⢠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
17. AppSec Program Management
Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
PREREQUISITE
FOUNDATIONS
18. ⢠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
19. ⢠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)
20. ⢠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
21. ⢠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
22. ⢠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
23. ⢠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
24. ⢠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
25. ⢠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
26. ⢠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
27. ⢠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
28. Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
DESIGN PHASE
29. Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
AppSec Design Phase
30. ⢠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
31. ⢠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
32. ⢠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
33. ⢠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
34. Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
TESTING PHASE
35. ⢠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
36. Red7 :|: Information Security
CODA
Š Copyright 2014-02 Robert Grupe. All rights reserved.
37. â˘
â˘
â˘
â˘
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
38. ⢠This Presentation & Further Resources
⢠www.red7managementsolutions.com
⢠Questions, suggestions, & requests
⢠Robert Grupe, CISSP, CSSLP, PE, PMP
⢠robert.grupe@red7managementsolutions.com
⢠+1.314.278.7901
Š Copyright 2014-02 Robert Grupe. All rights reserved.
Red7 :|: Information Security
Finis
Hinweis der Redaktion
BioRobert Grupe is an experienced international business leader with a background in engineering, sales, marketing, PR, and product support in the software, digital marketing, health care, electro-optic and aerospace industries. From Fortune 100 to start-up companies, Robert has worked for industry leaders including Boeing, McAfee, Text 100 PR, and Express Scripts. Management experience includes working with and leading local, as well as internationally distributed, teams while implementing best practices to maximum organizational and market performance. Robert is a registered Certified Information Security Professional (CISSP), Certified Secure Software Lifecycle Professional (CSSLP), Professional Engineer (PE), and Product Management Professional (PMP).