Addressing Security Across Vertical Market Segments - PowerPoint PPT Presentation

1 / 32
About This Presentation
Title:

Addressing Security Across Vertical Market Segments

Description:

We Use Network Vulnerability Scanners. We Have Firewalls in Place ... Black box (web app scanners) Strengths. Technical vulnerabilities. Scale and cost. Manual Testing ... – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 33
Provided by: danny93
Category:

less

Transcript and Presenter's Notes

Title: Addressing Security Across Vertical Market Segments


1
Addressing Security Across Vertical Market
Segments
  • Danny Allan
  • Strategic Research Analyst
  • Watchfire Corporation

2
Agenda
  • Security across Verticals
  • Differences Commonalities
  • Regulatory Matrices
  • Enterprise Risk Management
  • People
  • Process
  • Technology
  • Sample ERM Model
  • Summary

3
Security Across Verticals
  • Key differences
  • Regulatory Bodies, regulations, standards
    guidelines
  • Secure development lifecycle adoption
  • Commonalities across verticals
  • Security is expected and assumed
  • Consumers
  • Governing bodies
  • Executives

4
The Myth Our Site Is Safe
We Have Firewalls in Place
We Audit It Once a Quarter with Pen Testers
We Use Network Vulnerability Scanners
5
The Reality Security and Spending Are Unbalanced
of Attacks
of Dollars
10
75
90
25
Sources Gartner, Watchfire
6
Our World
Info Security Landscape
Web Applications
Antivirus Protection
Encryption (SSL)
Firewalls / Advanced Routers
Backend Server
Application Servers
Firewall
Databases
Web Servers
7
Security Spending Survey
  • Survey of 172 Fortune 1000 Security Executives
  • Top Security Projects for 2006
  • Web Application Security 15 listed it has 1
  • Status of Web Application Projects
  • 40 started
  • 35 near term
  • Change in spending from 2005-2006
  • 75 spend more
  • 20 spend the same

InfoPro
8
Wait a second
  • Application deployments are highly time
    critical
  • Application deployments are often late
  • Application deployments are often over-budget
  • Wont this add time, cost and resources?

9
Basic Premise
  • Implementing security saves time, money and
    resources
  • What do the following have in common?
  • PDA
  • Mobile phone
  • Printer
  • Web server
  • Do you see a trend?
  • Today web application
  • Tomorrow web service
  • Next week Web 2.0 AJAX
  • Next year Web 10.0 NLGT

10
Regulatory Matrix - Accessibility
Regulation / Guideline All FinSrv Ins Gov Pharma Health
Americans with Disabilities Act
Section 508 of the Rehabilitation Act
W3C Web Content Accessibility Guidelines
UK Disability Discrimination Act
11
Regulatory Matrix Anti-Money Laundering
Regulation / Guideline All FinSrv Ins Gov Pharma Health
Bank Secrecy Act
Office of Foreign Asset Control Regulations
USA PATRIOT Act
National Intelligence Reform Terrorism Prevention Act of 2004
12
Regulatory Matrix Privacy Security
Regulation / Guideline All FinSrv Ins Gov Pharma Health
California Assembly Bill 1950
California Financial Information Privacy Act
California Security Breach Information Act
Childrens Online Privacy Protection Act
Gramm-Leach-Bliley Act
Health Insurance Portability Accountability Act
Privacy Act of 1974
Safe Harbor
Section 208 of the E-Government Act of 2002
13
Regulatory Matrix Security
Regulation / Guideline All FinSrv Ins Gov Pharma Health
21 CRF Part 11
Computer Security Act
DCID 6/3
DoD Directives
Federal Information Security Management Act
ISO 17799
National Industrial Security Program Operating Manual
North American Electric Reliability Council
PCI Data Security Standard
14
Regulatory Matrix Security International
Regulation / Guideline All FinSrv Ins Gov Pharma Health
AU Privacy Act
CA Personal Information Protection and Electronic Documents Act
EU Data Privacy Directive
EU Directive on Privacy and Electronic Communications
UK Companies Act 2004
UK Data Protection Act
15
Regulatory Matrices - Summation
  • Understanding the regulations an organization
    falls under is a difficult (and moving) target
  • Some stakeholders will require compliance
  • All stakeholders will expect security
  • Lets get started
  • Implementation of a security program
  • Metrics measurement
  • Mapping against regulations, standards
    guidelines
  • Security category
  • Cause
  • Outcome

16
Enterprise Risk Management
People
Process
Technology
17
People
People
Process
Technology
  • Developer training
  • Security features ? secure programming
  • Security principles
  • Application threat classification

18
Security Principles
People
Process
Technology
  • Use least privilege
  • Defense in depth
  • Dont trust user input
  • Check at the gate
  • Fail securely
  • Secure the weakest link
  • Create secure defaults
  • Reduce your attack surface

19
Application Threat Classification
People
Process
Technology
  1. Authentication
  2. Authorization
  3. Client-side attacks
  4. Command execution
  5. Information disclosure
  6. Logical attacks

20
Threat Modeling
People
Process
Technology
  • Structured approach to identifying, quantifying
    and addressing threats
  • Allows security personnel to communicate
    potential risks and prioritize remediation
    efforts in a tangible form

21
Threat Modeling Activities
People
Process
Technology
Input Step Output
Business requirements Security policies Compliance requirements Identify security objectives Key security objectives
Deployment diagrams Use cases Functional specifications Create an application overview Whiteboard-style diagram Key scenarios Roles Technologies AppSec mechanisms
Deployment diagrams Use cases Functional specifications Data flow diagrams Decompose your application Trust boundaries Entry points Exit points Data flows
Common Threats Identify, document and rate threats Threat List
Common Vulnerabilities Identify vulnerabilities Vulnerability List
22
Enterprise Risk Mgmt Process
People
Process
Technology
  • Structured approach to designing, building and
    delivering web applications
  • Allows an organization to measure and communicate
    trustworthy computing in a tangible form

23
Definitions
People
Process
Technology
  • Process a series of actions directed toward a
    specific aim
  • Tangible capable of being given a physical
    existence

24
Security as a Quality Vector
People
Process
Technology
  • Maps well to Software Development Lifecycle model

Dont think Think
Security Quality
XSS w/ HTML quote encapsulation Output Encoding
Blind SQL injection White listing input Parameterized queries
Security issues Secure coding techniques
25
Automated Manual Testing
People
Process
Technology
  • Automated Testing
  • White box (static code analysis)
  • Black box (web app scanners)
  • Strengths
  • Technical vulnerabilities
  • Scale and cost
  • Manual Testing
  • Strengths
  • Logical vulnerabilities
  • Human intelligence

26
Phase Requirements
People
Process
Technology
  • Entry Criteria
  • Business requirements/objectives
  • Constraints assumptions
  • Project plans
  • High level architecture
  • Activities
  • Engage Security Expert
  • Determine Predictive Threat Index
  • Determine if application is a candidate for SDL
    process
  • Identify key compliance objectives
  • Define secure integration with external systems
  • Define application security test process
    deliverables
  • Adjust project plan to include security resources
  • Contract needed resources
  • Review test process/strategy
  • Review project plan budget
  • Deliverables
  • Security Expert/Consultant assigned
  • Preliminary security requirements defined
  • Security test strategy
  • Security integrated into the development process
  • Predictive Threat Index (Asset Value, Attack
    Surface)
  • Tools
  • Security consultant
  • Design Review Checklist
  • Roles and Responsibilities Matrix
  • Predictive Threat Index calculator
  • Security Knowledge Portal
  • Exit
  • Test strategy approved
  • Project plan approved

27
Phase Design
People
Process
Technology
  • Entry Criteria
  • Security requirements
  • Functional requirements
  • Use cases
  • Project plan budget
  • Activities
  • Identify components responsible for security
    functions
  • Identify secure design techniques
  • Document attack surface
  • Create threat model
  • Review/modify security requirements
  • Identify components for Secure Code Review
  • Define security test requirements
  • Determine authorization requirements model
  • Update Security Master Test Plan
  • Update test schedule and budget
  • Deliverables
  • Minimized application attack surface
  • Application security test roles
  • Threat model
  • Security requirements in well defined components
  • Test plans application security
  • Certified components identified
  • Tools
  • Threat Model Checklist
  • Threat Model
  • Platform dependent coding checklist
  • Certified Components
  • Exit
  • Baseline established for requirements, test
    schedule and test budget

28
Phase Implementation
People
Process
Technology
  • Entry Criteria
  • Threat model
  • Master test plan
  • Security test plans
  • Use cases/roles
  • Activities
  • Code
  • Certified components
  • Security development/coding guidelines
  • Test / Verify
  • Security Code Review
  • Static code analyzer
  • Deliverables
  • Working application
  • Tools
  • Static Code Analyzer
  • Certified Components
  • Security Development Guidelines
  • Exit
  • Code verified using code review
  • Code verified using static code analysis tool

29
Phase Integrate / Release
People
Process
Technology
  • Entry Criteria
  • Build from source code repository
  • Test documents
  • Unit integration test results (no severity 1
    defects)
  • Activities
  • Integrate
  • Formal Secure Code Review
  • Automated Application Assessment
  • Final Security Review
  • Review of all bugs for possible security
    vulnerabilities
  • Review threat model for possible late developing
    threats
  • Manual penetration testing
  • Deliverables
  • Problems, defects, enhancements logged
  • Detailed test results
  • Validated requirements
  • Updated test results in centralized location
  • Certification
  • Tools
  • Secure Code Review
  • Automated security tool
  • Manual Penetration Test
  • Final Review Checklist
  • Exit
  • No high severity security defects

30
(No Transcript)
31
Summary
  • Security across the verticals requires
  • Executive buy-in
  • A tangible SDLC process
  • Metrics measurement
  • Security cooperation and guidance
  • Application developer buy-in

32
Thanks
  • Questions?
  • Danny Allan
  • Office 781.547.7833
  • Dannya_at_watchfire.com
  • www.watchfire.com/securityzone
Write a Comment
User Comments (0)
About PowerShow.com