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