Web Application Security - PowerPoint PPT Presentation

About This Presentation
Title:

Web Application Security

Description:

Security: Definitions, Scope, Key Concepts. Prepared by Michael Hayes. Prepared ... CISAFE materials on Risk Assessment available on the CISAFE intranet site. ... – PowerPoint PPT presentation

Number of Views:62
Avg rating:3.0/5.0
Slides: 32
Provided by: mha7158
Category:

less

Transcript and Presenter's Notes

Title: Web Application Security


1
Web Application Security
  • Addressing Security Throughout the System
    Development Lifecycle

2
Sharing Lessons Learned
  • A project nearing completion where security is of
    primary concern for the project
  • Sensitive information population
  • Important that it not be treated as a
    afterthought, but be integrated throughout the
    lifecycle
  • Approach results have been validated by 3rd
    parties

3
Proactively Manage for Security
  • Many projects do not explicitly deal with
    security throughout the lifecycle
  • Security applied as an afterthought will likely
    be brittle, not take all factors of security and
    actors into account
  • May focus simply on perimeter management, e.g.,
    firewalling

Takeaway start elaborating system security
requirements and approach early
4
Security is a Process, Not a One-Time
Implementation
  • Think of implementing secure systems as an
    ongoing exercise in
  • Maintaining an inventory of assets (targets)
  • Identifying and classifying risks (cover later
    in attack trees)
  • Defining and implementing a series of strategies
    to mitigate those risks
  • Monitoring the effectiveness of those strategies
  • Staying current on existing and new threats to
    web applications
  • Being prepared to respond to breaches
  • Implementing secure systems always revolves
    around a series of tradeoffs
  • No system is perfectly secure or risk free.

5
  • Security Definitions, Scope, Key Concepts

6
Scope and Definitions
  • What is Security?
  • Authentication
  • How do we know actors are who they claim to be?
  • Users, Applications / system components, External
    systems
  • How do users know your system is what it claims
    to be?
  • Authorization
  • How do we know what behavior is allowed of an
    actor?
  • How is that enforced?
  • Confidentiality
  • How do we guarantee information / functionality
    is shared only with those who should see it?
  • Integrity
  • How is the information protected from tampering?
  • How do we prove it?
  • Non-Repudiation
  • How can we show that particular events are tied
    to an actor's behavior?
  • Additional areas
  • Availability / Redundancy / Resiliency
  • Usability

7
Actors
  • Hackers are not the only concern
  • End Users
  • Data entry
  • Power users
  • Administrators
  • Other applications
  • Application developers
  • Production support
  • Development staff
  • System Administrators Infrastructure Components
  • OS / App/Web Server / DBA
  • Monitoring
  • Backup
  • LDAP
  • Auditors
  • Are some of these trusted roles?

8
Key Concepts
  • Defense in depth
  • Security is frequently a "weakest link" element
    of a system
  • Multiple layers of mitigations will enhance your
    system's security (but may not be effective
    against all types of attackers)
  • Obscurity / secrecy is not security
  • Assume attackers have knowledge of your system
  • Enforce separation of roles
  • Roles / applications should run with least
    privilege
  • Security is an ongoing process
  • Technology is essential, but not the complete
    answer
  • Business owners must take responsibility for
    their information, weigh alternatives, monitor
    success criteria

9
  • Security in the Systems Development Lifecycle

10
Initiation Phase
Project Initiation
Solution Development Delivery
Support
Planning
  • Activities
  • Start to define risks and mitigations as early as
    this phase
  • Build an inventory of assets
  • Educate business owners on scope of security,
    mitigations that may be evaluated

11
How Much Effort to Expend on Security?
  • Right-size the security approach for the project
  • Factors in assessing how significant the security
    investment must be
  • Person rated
  • Mission critical
  • Restricted Information
  • Regulatory guidelines
  • Exposure to the public
  • Internal Information
  • Exposure to municipal employees
  • Dependent processes, systems
  • Back-end administrative
  • Public / non-sensitive data
  • Few / no dependent processes, systems
  • Security risks will drive the level and type of
    security-related activities during the project.

12
Planning Phase
Project Initiation
Solution Development Delivery
Support
Planning
  • Activities
  • Review workplan standards
  • Security checkpoints / confirmations in the
    lifecycle
  • Common exploits
  • Cross-site scripting
  • Un-validated input
  • Other OWASP Top 10 issues
  • Coding standards
  • Start building Attack Trees
  • Artifacts
  • High Level Workplan
  • Draft Attack Trees
  • Draft Scope of Work for 3rd Parties

13
Attack Trees
  • About Attack Trees
  • Developed by Schneier to analyze various attack
    paths to targets in information systems
  • Example Open a Safe
  • Different dimensions can be expressed using
    different variables
  • Skills / knowledge required
  • Cost
  • Ease
  • Actors
  • Provides a formal method for evaluating threats
    to assets, and can focus expenditures on most
    likely attacks.

14
Attack Trees
  • Open Safe example
  • Shows various attack paths, dependencies
  • Can track multiple variables

From Attack Trees, Bruce Schneier, Dr. Dobbs
Journal, December 1999
15
Attack Trees
  • Same attack tree, different variable
  • Cost, ease, outsiders/insiders, trusted roles

From Attack Trees, Bruce Schneier, Dr. Dobbs
Journal, December 1999
16
Project Initiation
Solution Development Delivery
Support
Planning
  • Analysis
  • Design
  • Development
  • Testing
  • Implementation

17
Solution Development Delivery Phases
Solution Development Delivery
Support
Project Initiation
Planning
Implementation
Analysis
Design
Development
Testing
  • Activities
  • Define business, security and technical
    requirements.
  • Any regulatory requirements, industry standards
    and best practices.
  • Risk assessment - opportunities for monetary
    loss, loss of productivity, public embarrassment.
  • Covers the data / functionality included in a
    system, how it gets there, how it is processed
    stored, specifies as risk associated with
    confidentiality breaches, tampering, etc.
  • CISAFE materials on Risk Assessment available on
    the CISAFE intranet site.
  • Based on what you know in requirements gathering,
    you would reassess the security tasks defined in
    your workplan and resource requirements from the
    Planning phase.
  • Continue elaborating Attack Trees
  • Risk assessment can add targets paths to your
    attack trees

18
Analysis Phase Artifacts
  • Artifacts
  • Risk Assessment draft
  • Detailed Requirements
  • Information Security Policy
  • Information classifications
  • Specific requirements for handling information of
    various classifications
  • Roles associated with the system, with data
    functions accessible to each

19
Information Security Policy Document
  • Example requirements in an InfoSec doc
  • Communications between end-user machines and web
    servers must be encrypted
  • Stored end-user passwords must be hashed rather
    than cleartext
  • A completed transaction must have a hash digest
    created and stored in XYZ external system to
    ensure the integrity of the transaction details.

20
Systems Development Lifecycle
Solution Development Delivery
Support
Project Initiation
Planning
Implementation
Analysis
Design
Development
Testing
  • Activities
  • Map out process/information flows
  • Detail how information enters the system, how it
    travels between components, where it is cleartext
    vs. encrypted / hashed.
  • Include flows between tiers in the system
  • Web / App / Database
  • Across clusters
  • To external systems
  • To backup / disaster recovery sites
  • Where is sensitive information sent or stored in
    cleartext, and who has access to information in
    this state?
  • When sensitive information is encrypted, what
    actors have the ability to decrypt the
    information?
  • Can roles be segregated to mitigate tampering
    opportunities?

21
Design Phase Activities (2)
  • Activities, continued
  • Where to Apply Mitigations
  • Very strong security technology may divert
    attacks to more brittle defenses elsewhere
  • Strong door, lock, window bar example
  • Strong password example
  • Password strength, rotation, etc can improve
    security
  • Overly strict, with different usernames/passwords,
    physical access to an office, how many users
    post usernames/passwords on post-it notes?
  • Attack Trees can be used to identify where to
    invest in mitigation strategies

22
Design Phase Activities (3)
  • Activities, continued
  • 3rd party review
  • This is a good checkpoint for a peer within the
    City, Q/A vendor or 3rd party security specialist
    to review the approach with the project team and
    business owner.
  • Review
  • have any additional security requirements arisen
    as part of the design process and any prototyping
    efforts?
  • Is planned security still right-sized for the
    system?
  • Continue to monitor risks/mitigations defined in
    earlier phases.
  • Based on design findings, you would reassess the
    security tasks defined in your workplan and
    resource requirements from the Planning phase.

23
  • Artifacts
  • Detailed Design document
  • Activity diagrams showing important functions
    (authentication, signatures, transactions)
  • Should explicitly state how the approach
    satisfies the security requirements.
  • Technical Blueprint
  • Information/Process Flow diagram

24
Development Phase Activities
Solution Development Delivery
Support
Project Initiation
Planning
Implementation
Analysis
Design
Development
Testing
  • Activities
  • Code reviews to ensure secure coding practices
    are used
  • Block Cross Site Scripting
  • Validate input
  • Error handling
  • More detailed information at www.owasp.org
  • Early / regular builds
  • Provides opportunities for testing security
    implementation
  • Scans
  • give developers access to scanning tools (they
    should be aware of IDS issues)
  • Do early scans if possible to identify potential
    issues before code freeze

25
Testing Phase Activities
Solution Development Delivery
Support
Project Initiation
Planning
Implementation
Analysis
Design
Development
Testing
  • Activities
  • Test planning
  • Design test based on risk areas
  • Test risk areas early and do right amount of
    testing for risk level
  • Consider a 3rd party review
  • Involve security professionals to validate
    implementation.

26
Scanning and Penetration Testing
  • Recommendations
  • Make sure your test environments are hardened in
    the same fashion as your production environments.
  • Host and Application Scanning
  • DOI can run scans against applications and host
    systems
  • 3rd party testing advisable for systems with high
    risk profiles or sensitive assets
  • Depending on the risk profile of the system, you
    may consider scanning all elements of the system
    ecosystem
  • Messaging / External systems
  • LDAP
  • Backup
  • Monitoring
  • Storage

27
Test Phase Artifacts
  • Artifacts
  • Code review minutes/findings
  • Test results responses
  • Elaborated Attack Trees
  • As-built design documentation

28
Systems Development Lifecycle
Solution Development Delivery
Support
Project Initiation
Planning
Implementation
Analysis
Design
Development
Testing
  • Activities
  • Deployment
  • Configuration management
  • Changes are prioritized, migrate through a series
    of environments tests prior to release
  • Backout plans are in place
  • Applications or key libraries can be signed
  • Separation of roles
  • Developers should not have access to production
    environments
  • Artifacts
  • Deployment plans
  • Runbook

29
A Note on Training
  • Training
  • Manual user processes are a big risk.
  • Make sure the proper training/communication is in
    place so that users treat their passwords
    securely and use the application with security
    risks in mind.

30

Project Initiation
Solution Development Delivery
Support
Planning
  • Activities
  • Production Operations
  • Configuration Management
  • Backup and Restore
  • Monitoring
  • Intrusion detection
  • Incident response
  • Auditing Confirmation
  • This is the responsibility of the business owner
  • Artifacts
  • Runbook
  • Regular activities (reviewing alerts, patching,
    reviewing logs)
  • Contact lists / escalation procedures
  • Monitoring
  • Roles Responsibilities
  • Audit logs
  • Decommissioning / Disposal

31
Further Reading
  • References
Write a Comment
User Comments (0)
About PowerShow.com