• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Application Security Program
 

Application Security Program

on

  • 1,054 views

 

Statistics

Views

Total Views
1,054
Views on SlideShare
1,053
Embed Views
1

Actions

Likes
0
Downloads
36
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Application Security Program Application Security Program Presentation Transcript

  • Establishing an Enterprise Application Security Program Tony Canike, CISSP, GCIH Manager, Application Security, The Vanguard Group [email_address] 610-503-6525
  • What today’s talk is about
    • What is an Application Security program?
    • The need for an Application Security program in your organization
    • Detailed look at the components of an Application Security program
    • Roadmap to establish your own Application Security program
      • This talk presumes the existence of network, server, physical, and organizational security efforts.
  • Setting the Stage
    • In my organization…
      • Application Security is an IT function
      • Information Security is a business function
        • Close cooperation and some overlap
      • Mix of purchased and in-house developed business applications
        • Many business applications developed in-house
  • What is an Application Security Program?
    • Def. 1: An integrated approach to Application Security in your organization
      • Not scattershot
      • Not tools with shiny red buttons
    • Def. 2: A corporate initiative to define, promote, assure, and measure the security of critical business applications.
    • So what does that really mean…
  • People, Process, and Technology all aligned to ensure secure business applications.
    • People
    • Policy
    • Standards
    • Awareness
    • Training
    • Roles
    • Priority
    • Expert Assistance
    • Technology
    • Standard Controls
    • Input Validation
    • Tools
    • Process
    • SDLC
    • App Inventory
    • Standard Requirements
    • Risk Management
    • Risk Rating
    • Reviews
    • Governance
  • Application Security: Part of the Big Picture
    • Conceptual Information Security Dashboard
    Intrusion Detection Vendors & Partners Computing Infrastructure Network & Telecom Infra Physical Security Business Processes Data Security Business Applications Compliance Business Continuity Incident Response Fraud Prevention Simplified example only. A complete dashboard could have 20-30 indicators.
  • Benefits of an Application Security program
    • Knowledge to…
      • keep the C-suite informed
      • communicate areas of opportunity
      • develop high-level action plans
      • assist the application development teams
      • optimally allocate resources and funds
      • protect client and corporate assets
  • Why do you need an Application Security program?
    • What are your big application security issues, anyway?
      • Can you back up recommendations with data?
      • Can you justify expenditures?
    • Security is more then securing the network perimeter…
      • … do you have data to support that?
      • Your network security colleagues have numbers, you need numbers too.
    • Use Data, Metrics, Numbers, Facts
      • Data-driven decision making
      • Really know what is working and what is not
      • Motivate actions
    • Suggestions for metrics collection throughout presentation
  • Knowledge in multiple dimensions
    • Training and Awareness
      • Are IT Staff trained and aware of security issues?
    • SDLC Maturity and Compliance
      • Is security baked-in to your Software Development Life Cycle?
      • Are you following your SDLC?
    • Reference Architectures and Standard Controls Provided?
    • Security Assessment Coverage of the Application Space
      • Are you doing enough assessments? Frequently enough?
      • Anything you don’t know you don’t know?
    • Application Risks and Vulnerabilities
      • When are security problems found? During Code? Test? Prod?
      • Are you mitigating risks in a timely fashion?
    Leading Indicator Leading Indicator Post Indicator
  • How much security do we need?
  • Components of an Application Security program
    • People
    • Policy
    • Standards
    • Awareness
    • Training
    • Roles
    • Priority
    • Expert Assistance
    • Technology
    • Standard Controls
    • Input Validation
    • Tools
    • Process
    • SDLC
    • App Inventory
    • Standard Requirements
    • Risk Management
    • Risk Rating
    • Reviews
    • Governance
  • People: Policies and Standards
    • Information Security Policies
    • IT Architecture Standards
      • Reference application architectures (w/security)
      • Standard security controls identified
    • SDLC Defined
    • Standard Application Security Requirements
    • Use reviews to govern and enforce
    • Dashboard Indicators, Metrics
  • People: Awareness and Training
    • Awareness of policies and standards
      • Information Security
      • Corporate intranet or newsletter articles
      • Web-based training
    • Training
      • Security architects
      • Managers
      • Technical leads
      • Developers
      • Testers
      • Etc…
    • Dashboard Indicators, Metrics
  • People: Define Specialized Roles
    • Security Architects
      • Understand standard application controls and how to implement them
      • Directly supporting application development
      • Setting enterprise-wide standard security architecture
    • Application Security Assessment Team
      • Small, quasi-independent team
      • Assess architectures and test for vulnerabilities
    • Access Management Team
      • Business group grants access to business applications
        • Keeper of the keys (literally and figuratively)
        • Not developers, not users, not system admins
  • People: Prioritize Security
    • Time to market, business functionality, and cost all compete with security concerns.
    • Executive attention
      • One suggestion: IT VP’s present their security metrics/dashboard to an executive committee quarterly
    • Report security vulnerabilities as defects
      • Defect-elimination mentality already engrained?
        • If so, leverage it.
        • If not,…
  • People: Expert Assistance
    • Security experts are available to application development teams
      • Security Architects
      • Central team to maintain standard security controls
        • Eval, purchase, development, support of technical controls
      • Access management team
      • Information Security
      • Product Vendor resources
      • Consultants as necessary
  • Components of an Application Security Program
    • People
    • Policy
    • Standards
    • Awareness
    • Training
    • Roles
    • Priority
    • Expert Assistance
    • Technology
    • Standard Controls
    • Input Validation
    • Tools
    • Process
    • SDLC
    • App Inventory
    • Standard Requirements
    • Risk Management
    • Risk Rating
    • Reviews
    • Governance
  • Process: Software Development Life Cycle
    • Integrate security steps into your SDLC
      • Will take a few iterations to mature.
    • Baked-in, not bolted-on
      • End-game penetration test is not sufficient
    • Find security issues early
      • Much easier, cheaper to fix
    • Measure compliance
      • Self-reporting
      • Audit a sampling
    • Voice of Practitioners
      • Are the processes working?
    • Dashboard Indicators, Metrics
  • Process: Application Development Life Cycle Track Security Metrics Track and Manage Defects and Risks Security Requirements Input Validation Access Control Security Architecture Review Design & Code Review Unit & Integration Test Vulnerability Test System Test Pre-Elev Risk Review Application Categorization Categorize Define Requirements Build Controls Verify Controls Risk Management Governance Review Governance Review Elevation Test Analysis, Design & Implementation Requirements Business Arch & Planning
  • Process: Inventory and Categorize your Applications
    • List all your business applications, the business owner, and the IT owner (might be hard)
    • Categorize applications w.r.t. criticality of security
      • Potential Business Impact
      • Quick Technical Assessment – surface area, complexity, data classification
      • Ref. NIST 800-64 and FIPS 199
    • Use categorization to prioritize security attention and assessments.
    • Assessments Performed? How recently?
    • Dashboard Indicators, Metrics
  • Process: Standard Security Requirements
    • Define Security Requirements Standards for your business applications.
      • Which controls are necessary
      • When are they necessary (applicability)
      • Why are they necessary (e.g. SEC, SOX, etc.)
        • Easy to use reference for requirements teams
      • Standard method to implement each control
        • Provide reference on how to implement
      • Requirements for requirements
        • E.g. The need to specify functional business requirements for access control
  • Process: Security Assessments of Applications
    • Choose types of assessments that fit your organization.
      • Security Architecture/Design Reviews
      • Security Code Reviews
      • Application Vulnerability Tests
      • Risk Acceptance Review
      • External Penetration Test of Production Applications
    • White Box Philosophy – look inside the application
      • Use all the advantages you have
        • Past reviews, design documents, code, logs, interviews, etc.
      • Attackers have advantages you don’t, don’t tie your hands.
    • Part of your SDLC
      • Define which reviews when, by whom, and how in your SDLC
    • Don’t underestimate the amount of work necessary for communication, scheduling, report writing, logistics
  • Security Architecture/Design Review
    • Architecture/Design time assessment of an application and its security controls
    • Component interface and connection driven
      • Enumerate through the interfaces and connections considering threats, vulnerabilities, and risks
      • STRIDE
    • Identify non-standard, home-brewed or missing security controls
    • Issue a report
      • Identify vulnerabilities to mitigate or fix
      • Identify issues for follow-up
  • Security Code Review
    • Focus on code relevant to security
    • Utilize experts
      • Consider consulting firms with specialized techniques.
    • Specialized Tools
      • Have a technique to wade through 5 million lines of code
    • Define Scope and Purpose
      • Project Manager: “ since you are reviewing my code, I can skip all my code reviews, ok?” Not so fast…
      • You are not reviewing the code for the application team – they are still on the hook for code quality.
  • Application Vulnerability Test
    • Hands-on testing of application around System Test time
      • “ Port 80” types of attacks
    • Goal is to find most of the problems early and get them fixed.
      • Not trying to prove a point, not playing capture-the-flag
    • Use a small dedicated team supported by consultants
    • Educate and collaborate with development teams
    • Use all advantages you have – white box
      • Logs, source code, business knowledge, prior assessments
    • Define purpose – are you going to validate that the application meets all of its security requirements?
      • Probably not. Make that clear up-front.
    • Define scope – which components are being tested?
      • Use the architecture diagram
  • Process: Information Security Risk Management
    • Document your risk rating process
      • Common risk rating method and scale
      • Consider business impact and likelihood/DREAD factors
      • Rationale for a particular risk rating known and documented
    • Common taxonomy
      • Categorize and count – perhaps 10 categories
    • Weed out false positives early – reduce noise
      • Draft, Review, Revise
    • Apply to all IT-owned InfoSec Risks from all sources
      • Consultants, IT Security Assessments, InfoSec Assessments, Internal Audit (if possible), Corporate Risk Management, etc.
      • Develop/Adapt process through consensus
      • Calibrate!
  • Example Job Aid – Likelihood Factors WHO? Mitigating Controls Skill Level All Internet Customers System Admins Direct Access One Control Two Controls Three or more Unintentional No special skills Technical Very Technical Attractive? Very Attractive Somewhat Attractive Not Attractive Well Known? Public Internal Proprietary Theoretical IT Employees CORP Inc CORP Inc LIKEL IHOOD HIGH LOW Illustrative example only.
  • Process: Information Security Risk Management (cont.)
    • Common Repository for tracking
      • Assessments
      • Risks/Vulnerabilities
      • Mitigation Actions and Status
    • Common report formats
      • Differing formats from different assessment teams (internal, consultants, audit) confuses everyone
    • Common summary reports
      • Open risk counts, severity, category, owners, time-to-close, …
      • Train management on how to read summary reports
    • Dashboard Indicators, Metrics
  • Process: Risk Review and Acceptance
    • Review known security risks and mitigation status prior to production elevation.
    • Business owners key participants
      • Need to understand and accept (or not) outstanding risks prior to elevation
      • No surprises…
    • Dashboard Indicators, Metrics
  • Process: Other tests and assessments….
    • Of course, utilize the gamut of security assessments, including
      • Internet Penetration Tests
      • Network and vulnerability scans
      • Server security scans
    • Up to you to define the boundary of “Application Security” for your organization.
      • Cooperate, avoid fiefdoms
  • Process: Governance Team Reviews
    • IT-wide governance team of practitioners reviews summaries of security assessments and tests
      • Were the risks rated properly?
      • Was the assessment or test complete?
      • Is the responsible individual taking responsibility and fixing the issues?
      • What are the common themes and trends?
      • What improvements to people-process-technology can be implemented?
  • Components of an Application Security Program
    • People
    • Policy
    • Standards
    • Awareness
    • Training
    • Roles
    • Priority
    • Expert Assistance
    • Technology
    • Standard Controls
    • Input Validation
    • Tools
    • Process
    • SDLC
    • App Inventory
    • Standard Requirements
    • Risk Management
    • Risk Rating
    • Reviews
    • Governance
  • Technology: Standard Controls
    • Provide standard technical controls to your application development teams.
      • Determine needs and prioritize
      • Consider authentication, access control, certificate management, cryptography, accountability, logging, detection, ...
        • Reuse opportunity
      • Don’t let app teams “roll their own” or reinvent the wheel.
    • Central shared security controls team?
      • Handle eval, purchase, integrate, build, test, support
      • Support application teams
    • Provide reference architectures with integrated security controls
    • Dashboard Indicators, Metrics
  • Technology: Standard Controls (cont.)
    • Do your standard security controls cover all your application architectures?
      • LAN/Desktop login
      • Web (Internet, intranet, J2EE, .NET, LAMP, etc.)
      • Thick desktop clients
      • Application Service Providers/Partners – SSO
      • UI tier, Business logic tier, data tier
      • Web Services
  • Technology: Input Validation
    • Is each application developer building their own input validation code?
    • Or do you have a standard mechanism?
      • Is there a standard signature/architecture/API and a reuse library that developers can contribute to?
      • For all your application models?
    • Do requirements/use cases/UI specifications document necessary allowed values for each input field?
  • Technology: Security Tools
    • Tools
      • Developers
      • System Testers
      • Security Assessors/Testers
  • People, Process, and Technology all aligned to ensure secure applications.
    • People
    • Policy
    • Standards
    • Awareness
    • Training
    • Roles
    • Priority
    • Expert Assistance
    • Technology
    • Standard Controls
    • Input Validation
    • Tools
    • Process
    • SDLC
    • App Inventory
    • Standard Requirements
    • Risk Management
    • Risk Rating
    • Reviews
    • Governance
  • That’s a long list…
    • Implementing all these components of an Application Security program is a tall order
    • Adapt to your needs
      • In-house development
      • Purchased applications
      • Outsourced applications
    • In-house SDLC vs. outsourcing requirements and contract language
  • Roadmap to your own Application Security Program
    • Assess Current State – what are your organizational and process deficiencies?
      • Info Sec and Internal Audit will help you here!
    • Develop and sell your vision
      • It’s a integrated program
      • Identify and educate your stakeholders
    • Have a roadmap and a project plan – 2-4 year effort
  • Where to start?
    • Awareness and Training
      • 2-hour course: $100-200/seat
      • Seeing the look on the IT VPs’ faces when they get SQL Injection: Priceless
    • Policies and Standards
    • Application Assessments and Reviews
      • Get some data
      • Strive to be consistent and uniform
    • Support Development Teams
  • Questions?
  • More Information
    • ISF Standard of Good Practice
      • ISF has a strong Business Impact assessment process (membership required)
    • NIST Security Considerations in the Information System Development Life Cycle (800-64)
    • OWASP Guide
    • Howard and LeBlanc Writing Secure Code