Web Application Security: Beyond PEN Testing

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).



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


Agenda Quick Start Solution:
Foundational Non-Coding AppSec



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


US Data Breach Costs
per person/record

2013 Cost of Data Breach Study: Global Analysis, Ponemon Institute

• 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


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



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



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


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


Costs of Delayed Vulnerability Detection
Cost to Fix Defects



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



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



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)


Difficult to Communication with Business
Management

The add technical layers based on funded capabilities



QUICK START SOLUTION:
FOUNDATIONAL
NON-CODING APPSEC

• Leverages non-coding application team members
• Product Managers / Business Analysts, UI Designers, Testers


Web Appsec Foundational

AppSec Program Management



PREREQUISITE
FOUNDATIONS

• Defining the Security

Requirements Library

• ITIL Service Definition,

Service Management, and
Continual Service
Improvement Model



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



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.


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.




• 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.



• 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.




• 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



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


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


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.



Security Tests Library



DESIGN PHASE



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.



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



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)



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)



Design Review



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.



Testing Phase


CODA


•
•
•
•

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


AppSec Beyond PEN Testing

• This Presentation & Further Resources
• www.red7managementsolutions.com
• Questions, suggestions, & requests
• Robert Grupe, CISSP, CSSLP, PE, PMP
• robert.grupe@red7managementsolutions.com
• +1.314.278.7901



Finis

Web Application Security: Beyond PEN Testing

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to Web Application Security: Beyond PEN Testing (20)

Recently uploaded (20)

Web Application Security: Beyond PEN Testing

Editor's Notes