Transcript Developing Secure Software

Developing Secure
Software
Bob Alcorn, Blackboard Inc.
© Blackboard, Inc. All rights reserved.
About Forward-Looking Statements
»
We may make statements regarding our product
development and service offering initiatives,
including the content of future product upgrades,
updates or functionality in development. While
such statements represent our current intentions,
they may be modified, delayed or abandoned
without prior notice and there is no assurance that
such offering, upgrades, updates or functionality
will become available unless and until they have
been made generally available to our customers.
Session Outline
Security Overview
» Blackboard Academic Suite™ Security
Infrastructure
» Integrating Security Analysis into the
Development Lifecycle
» Some Vulnerabilities
»
Oh, <bleep/>…
»
»
»
»
A bug comes in from the field, demonstrating that code fails to check a
permission, and allows a user to delete large swaths of data…
A client reports that failure validate input exposes the ability for a user
to view the contents of any file on the system…
Investigation of client performance issues reveals that code performs
an expensive operation, but doesn’t handle multiple, repeated
requests, resulting in system response crashing…
…How do you proactively address these issues before you get the
“oh, <bleep/>” client call?
General Security Principles
»
Authentication
»
»
Authorization
»
»
What a user can see
Non-repudiation
»
»
What a user can do
Confidentiality
»
»
Who a user is
Did a user really perform an action
Availability
»
The system is ready for user activity
Authentication
»
»
Verifying users’ identities
The “factors” in authentication…
What a user “is”
» What a user “has”
» What a user “knows”
»
»
One vs. Multi-Factor Authentication
»
Blackboard as one-factor authentication:
»
»
Knows a username/password combination
ATM Card as two-factor authentication:
Has the card AND
» Knows the PIN
»
Authorization
Once authenticated, verifying what a user can do
» Mandatory Access Control
»
»
»
Determined by system or administrator policy
Discretionary Access Control
»
Determined by the data owner
Authorization – RBAC
Role-based access control
» Form of mandatory access control
» Blackboard uses “Contextual” RBAC for most
operations
»
»
Role to use dependent on data being accessed; users
can have multiple, even contradictory, roles that are
selected based on which data is being accessed
Authorization – Discretionary Access Control
»
»
Access defined by the data owner
Access Control Lists
»
ACL is a collection of Access Control Entries
Principal
» Privilege
»
Non-Repudiation
»
The ability to definitively state that a particular
transaction has or has not occurred
»
»
Logging/Auditing
Signatures
Why Model Security?
»
“I already apply all those principles in my
design…”
Bugs in your code…
» Bugs in Bb code…
» Bugs in infrastructure code…
»
Security in the Development Cycle
»
Security Analysis in Development is a Risk
Mitigation Strategy
You will not find all the bugs…
» You will not see all the vulnerabilities…
» Your design will have errors of omission and oversight
»
Security Modeling
Techniques to evaluate an application’s overall
security or assess the impact of a specific threat
» Objectively identify vulnerabilities and address
countermeasures
» Integrated steps to take in the development
process
»
Security Modeling – The Process
»
Define threats
»
»
»
Assess the Impact
»
»
Consider the data stored in the system, and how it can be misused
Consider the architecture of the system, and the opportunities it
affords malicious users
You’ve found a vulnerability… what happens if someone actually
finds it? How badly would you or your users be affected?
Implement a Countermeasure
»
Mitigate the risk to the best of your ability – code a preventative
action, limit the exposure
Defining the Threats
»
»
Decompose your application to ask questions about how
each use case or application component could go awry
STRIDE
»
»
»
»
»
»
»
Spoofing Identity
Tampering with Data
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Unlike DREAD, STRIDE is not for “scoring” threats, just for
classification in general threat modeling
Assessing Vulnerabilities
»
DREAD aims to quantify a threat
»
Assign a value between 1 and 10 and use the mean
»
Damage Potential
»
»
Reproducibility
»
»
0 – Extremely sophisticated skills required; 10 – anybody with a browser
Affected Users
»
»
0 – Almost impossible to reproduce; 10 – can reproduce at any time
Exploitability
»
»
0 – no damage; 10 – complete system damage
0 – No users; 10 – All users (or beyond… think VA data leak)
Discoverability
»
0 – Requires source code; 9 – details of exploit are in public domain; 10 – it’s in easily
discoverable data in the application itself.
Assessing Vulnerabilities
»
Microsoft Threat Modeling
»
»
»
»
»
»
Identify objectives
Decompose application
Identify threats
Identify vulnerabilities
…repeat
Relies on specific terminology
»
»
»
»
»
Asset – resource of value
Threat – Undesired event, such as a data leak
Vulnerability – A specific code or configuration weakness that enables an exploit
Exploit – Attack that utilizes one or more vulnerabilities to realize a threat
Countermeasure – Attempt to reduce probability of attack and impact of a threat
Assessing Vulnerabilities
»
Components work together or independently
»
»
Process is iterative
»
»
»
Full threat model will use components of the others, such as
DREAD to prioritize the identified threats
A full picture of the application cannot be generated all at once
Vulnerabilities can be found at any level of the application
For more information: OWASP
»
Open Web Application Security Project
OWASP Top-Ten List
»
»
»
»
»
Unvalidated Input
Broken Access Control
Broken Authentication and
Session Management
Cross-Site Scripting
Buffer Overflow
»
»
»
»
»
Injection Flaws
Improper Error Handling
Insecure Storage
Application Denial of
Service
Insecure Configuration
Management
Not all necessarily apply at all times/layers of
the application…
Unvalidated Input
Client provided data is not properly validated for
boundaries, format, etc.
» Approaches:
»
Validate inputs before allowing business processing
» Do not rely on client-side validation
» Ensure correct error handling
»
Broken Session Management
The system does not properly track sessions, or
authentication isn’t properly enforced
» Approaches
»
»
Within the Building Block itself, treat this as
Blackboard’s problem, unless you are creating a
custom scheme (as in Web Service authentication)
Cross-Site Scripting (XSS)
A user can enter JavaScript that hijacks another
user’s browser session
» Approaches:
»
Do not allow markup (e.g., always render as plain text)
» Validate/scrub input
»
»
blackboard.util.XSSUtil
Injection Flaws
»
A variant of unvalidated input: a script takes
request parameters and uses them directly to
construct a command passed to another process
»
»
Typically realized as SQL Injection – parameters such
as column names or where clause fragments are
explicitly used in statement construction
Approaches
»
»
»
Validate input
Always use symbolic values
If building statements, always use prepared statements
Improper Error Handling
Incomplete error handling which allows
inappropriate data to bubble to an end user
» Approaches
»
No unhandled exceptions
» Use a webapp error handling policy
»
Denial of Service
A transaction can be abused or overloaded in
such a way as to render the system unusable
» Approaches
»
Performance engineering during development
» Error handling
»
Others on the Top Ten
Buffer Overflows
» Insecure Configuration Management
» Insecure Storage
»
»
… still important to consider, but less prevalent for
the Building Blocks developer
…but wait! There’s More!
»
»
»
»
»
»
Unnecessary and Malicious Code
Broken Thread Safety and Concurrent
Programming
Unauthorized Information Gathering
Accountability Problems and Weak Logging
Data Corruption
Broken Caching, Pooling, and Reuse
Looking Ahead
»
»
Apply threat modeling to the application development cycle
During requirements and design, understand the risks and threats
Use a method to evaluate the impact and prioritize; ideally looking at each
vulnerability against each asset/threat
» Identify critical transactions and risks
» Know the countermeasures
»
»
»
Awareness leads to coding practices that eliminate most vulnerabilities – e.g.,
unvalidated input or code-injection flaws
Other tools to help
XSSUtil – to scrub for potentially harmful markup
» Access Control infrastructure to determine trust (e.g., some users are allowed
to enter markup)
»
Questions?