This webcast (now in PDF version) will present six security engineering activities that can be leveraged to refine and extend their existing life cycle activities.
1 Six Key Security Engineering Activities Jason Taylor CTO Security Innovation About Security Innovation • Application and Data Security Experts – 10+ years of research on security vulnerabilities – Hundreds of assessments on world’s most dominant software, applications and development environments – Solutions for all phases of SDLC: secure design, development, testing and deployment • Products, Services & Training – Training/eLearning on secure coding, security testing, etc. – Application Security Assessment (black and white box) – Encryption for secure data transfer and communications Boston Seattle
Transcript
1
Six Key Security
Engineering Activities
Jason Taylor
CTO
Security Innovation
About Security Innovation
• Application and Data Security Experts – 10+ years of research on security vulnerabilities
– Hundreds of assessments on world’s most dominant
software, applications and development environments
– Solutions for all phases of SDLC:
secure design, development, testing and deployment
• Products, Services & Training
– Training/eLearning on secure coding, security testing, etc.
– Application Security Assessment (black and white box)
– Encryption for secure data transfer and communications
• Threat – Undesired event or potential occurrence
– May or may not be malicious in nature
– Might damage or compromise an asset or objective
• Vulnerability – Weakness in some aspect or feature of a system that makes an exploit possible
– Can exist at the network, host, or application level
• Attack (or exploit) – An action taken that uses one or more vulnerabilities to realize a threat
– Could be someone following through on a threat or exploiting a vulnerability
• Countermeasures – Address vulnerabilities to reduce the probability of attacks or impacts of threats
– Do not directly address threats but address the factors that define the threats
– Range from improving application design, or improving your code, to improving an operational practice.
4
Six Key Security Activities
• Identify Security Objectives to ensure security considerations in later phases
• Apply Security Design Guidelines to reduce your application’s attack surface
• Conduct Security Architecture and Design Reviews to identify security problems that can have multiplier effect in later phases
• Create Threat Models that identify threats, attacks, vulnerabilities and countermeasures
• Perform Security Code Reviews and Penetration Testing to uncover specific vulnerabilities
• Conduct Security Deployment Reviews to ensure configuration and deployment problems are discovered before app is in production
Activity #1: Identifying Security Objectives
• Defined at beginning of development process
• Identify goals and constraints that affect the confidentiality, integrity, and availability of your data and application
• Are used to:
– Filter the set of Design Guidelines that are applicable
– Guide Threat Modeling
– Scope and guide Architecture and Design reviews
– Help set Code Review objectives
– Guide security Test Planning and Execution
– Guide Deployment Reviews
if you don’t know what the objectives are for your application then it is
difficult to be successful with any other security activity.
5
Identifying Security Objectives: Discovery Process
• Discovery Process
– an iterative process that is initially driven by an examination of the application’s requirements and usage scenarios.
– by the end of the requirements and analysis phase you should have a first set of objectives that are not yet tied to design or implementation details
– during design phase additional objectives will surface that are specific to the application architecture and design
– during implementation phase you may discover a few additional objectives based upon specific technology or implementation choices that have an impact on overall application security
– Each evolution of the security objectives will impact other security activities.
The threat model, architecture and design review guidelines, and general code
review guidelines should be revisited when your security objectives change.
Identifying Security Objectives: Questions to Ask
Objective Category Questions to ask
Tangible assets to protect Are there user accounts and passwords to protect?
Is there confidential user information (such as credit card numbers)
that needs to be protected?
Is there sensitive intellectual property that needs to be protected?
Can this system be used as a conduit to access other corporate
assets that need to be protected?
Intangible assets to protect Are there corporate values that could be compromised by an attack
on this system?
Is there potential for an attack that may be embarrassing, although
not otherwise damaging?
Compliance requirements Are there corporate security policies that must be adhered to?
Is there security legislation you must comply with?
Is there privacy legislation you must comply with?
Are there standards you must adhere to?
Are there constraints forced upon you by your deployment
environment?
Quality of service requirements Are there specific availability requirements you must meet?
Are there specific performance requirements you must meet?
6
Identifying Security Objectives - Approach
• Roles Matrix
• Derive from functional requirements
Objects
Subjects
User
creation
Permission
modification
Object
creation
Object
removal
Object
read
Admin x x
Content
Creator x x x
Reader x
Anonymous x
Original Requirement Derived Security Objectives
Administrator must be able to add users
and change user permissions through an
administrator interface.
C – Protect user names and permissions from disclosure to a non- administrator
I – Restrict non-administrator from adding users and changing user permissions
A – Application is available so that the administrator is able to add users and change
user permissions Each application server must be able to
serve 1000 concurrent users.
A – Application server is available for users
Registered users must be able to
purchase books from the web user-
interface
C – Protect registered user credentials and other sensitive information from non-
administrators and non-registered users
I – Restrict non-registered user from purchasing books from the Web user-interface
I – Restrict registered users from obtaining books for the wrong price
A – Web user interface is available for registered users to purchase books
Activity #2: Apply Security Design Guidelines
• Represent proven practices evolved over time to reduce risk
• Reduce your risk by addressing common vulnerabilities, allowing you to focus on the unique aspects of your design
• Each guideline must meet the following qualifications
– Actionable. Associated with a vulnerability that can be mitigated through the guideline
– Relevant. Associated with a vulnerability that is known to effect real applications
– Impactful. Represent key engineering decisions that will have wide-ranging impact
• Guidelines are categorized into a security frame
– Describes the areas in which poor design can lead to security vulnerabilities
– Allows the inclusion of additional guidelines or the refinement of existing guidelines based on newly discovered vulnerabilities
7
Activity #2: Applying Security Design Guidelines
Design guidelines are organized by the common application vulnerability categories contained in the Security Frame
Vulnerability Category Potential Problem Due to Bad Design
Input / Data Validation Insertion of malicious strings in UI or public APIs. These attacks
include command execution, cross - site scripting (XSS), SQL
injection, and buffer overflow. Results can range from
information disclosure to elevation of privilege and arbitrary code
execution.
Authentication Identity spoofing, password cracking, elevation of privileges, and
unauthorized access.
Authorization Access to confidential or restricted data, data tampering, and
execution of unauthorized operations.
Configuration Management Unauthorized access to administration interfaces, ability to
update configuration data, and unauthorized access to user
accounts and account profiles.
Sensitive Data Confidential information disclosure and data tampering.
Cryptography Access to confidential data or account credentials, or both.
Exception Management Denial of service and disclosure of sensitive system-level details.
Auditing and Logging Failure to spot the signs of intrusion, inability to prove a user's
actions, and difficulties in problem diagnosis.
Design Guidelines – Best Practices
Category Guidelines
Input / Data Validation Do not trust input; consider centralized input validation. Do not rely on client-side
validation. Be careful with canonicalization issues. Constrain, reject, and sanitize
input. Validate for type, length, format, and range.
Authentication Use strong passwords. Support password expiration periods and account
disablement. Do not store credentials (use one-way hashes with salt). Encrypt
communication channels to protect authentication tokens.
Authorization Use least privileged accounts. Consider authorization granularity. Enforce
separation of privileges. Restrict user access to system-level resources.
Configuration Management Use least privileged process and service accounts. Do not store credentials in
clear text. Use strong authentication and authorization on administration
interfaces. Do not use the Local Security Authority (LSA). Secure the
communication channel for remote administration.
Sensitive Data Avoid storing secrets. Encrypt sensitive data over the wire. Secure the
communication channel. Provide strong access controls for sensitive data stores.
Cryptography Do not develop your own. Use proven and tested platform features. Keep
unencrypted data close to the algorithm. Use the right algorithm and key size.
Avoid key management (use DPAPI). Cycle your keys periodically. Store keys in
a restricted location.
Exception Management Use structured exception handling. Do not reveal sensitive application
implementation details. Do not log private data such as passwords. Consider a
centralized exception management framework.
Auditing and Logging Identify malicious behavior. Know what good traffic looks like. Audit and log
activity through all of the application tiers. Secure access to log files. Back up and
regularly analyze log files.
8
Activity #3: Threat Modeling
• Identify threats, attacks, and vulnerabilities that are relevant for your application
• Determine countermeasures to mitigate vulnerabilities
• Perform in the architecture and design phase, as soon as:
– You understand your security objectives
– You understand you application architecture
• Update and improve iteratively:
– When your security objectives change
– When your design changes
– During implementation, testing and deployment
Threat Modeling – Activity Overview
• progressively refine your threat model by repeatedly performing steps 2 through 5.
You can add more detail as you move through your application development
lifecycle and discover more about your application design.
9
Threat Modeling – Activity Summary Table
Input Step Output
Business requirements
Security policies
Compliance requirements
Step 1: I
identify security objectives
Key security objectives
Deployment diagrams
Use cases
Functional specifications
Step 2:
Create an application overview
Whiteboard-style diagram with
end-to-end deployment scenario
Key scenarios
Roles
Technologies
Application security mechanisms
Deployment diagrams
Use cases
Functional specifications
Data flow diagrams
Step 3:
Decompose your application
Trust boundaries
Entry points
Exit points
Data flows
Common threats Step 4:
Identify threats
Threat list
Common vulnerabilities Step 5:
Identify vulnerabilities
Vulnerability list
Activity #4: Perform Architecture & Design Review
• Goals:
– Analyze application architecture and design from a security perspective
– Expose the high-risk design decisions that have been made
• Don’t rely solely on the use of design documentation
– Use a combination of design documents, architecture experts and discussion to achieve the best results
10
Architecture & Design Review – Techniques
• Use a question driven approach to expose the highest risk design decision
• Use the security frame to dive into areas that reveal common mistakes
• 3 pronged approach
– Deployment and infrastructure. Review the design of your application in relation to the target deployment environment and the associated security policies.
– Security frame. Review approach to critical areas in your application: authentication, authorization, input / data validation, exception management, and other areas
– Tier-by-tier analysis. Walk through the logical tiers of your application, and evaluate security choices within your presentation, business, and data access layers
Architecture & Design Review – Checklists
• Checklists represent areas where mistakes are most often made
• Evolve your checklists to include custom checks based your application’s architecture
• Example input and data validation checklist:
Check Description
All entry points and trust boundaries are identified by the design.
Input validation is applied whenever input is received from outside the current trust boundary.
The design assumes that user input is malicious.
Centralized input validation is used where appropriate.
The input validation strategy that the application adopted is modular and consistent.
The validation approach is to constrain, reject, and then sanitize input.
(Looking for known, valid, and safe input is much easier than looking for known malicious or dangerous
input.)
Data is validated for type, length, format, and range.
The design addresses potential canonicalization issues.
Input file names and file paths are avoided where possible.
The design addresses potential SQL injection issues.
The design addresses potential cross-site scripting issues.
The design does not rely on client-side validation.
The design applies defense in depth to the input validation strategy by providing input validation across
– Critical leverage point to reduce the number of implementation errors
– Can be performed on every check-in, every build, or some other interval that works for your development process
– One of the most impactful steps you can take toward more secure code
– While design bugs are the most expensive to fix, implementation bugs are the most common
• Security Testing
– Functional test techniques cannot uncover security bugs
– Designed to understand what is the application NOT supposed to do
– Specific attacks should be applied to uncover vulnerabilities
1. Identify Code Review
Objectives Iterative Process
Inputs • Design documentation
• Architecture diagram
• Data flows
• Usage scenarios
• Inspection questions
Outputs • Inspection questions
• Prioritized list of problems to fix in
the code
2. Perform Preliminary
Scan
3. Review for Common Issues
4. Review for Unique Issues
Conducting the Code Review Methodology
12
Goals of the Code Review
• Create/Update a list of inspection questions
– what problems are possible in the technology
• e.g. should you be looking for buffer overflows?
– what problems are possible due to the design?
• are there threat mitigations already in place?
• Identify vulnerabilities
– where in the code
– under what conditions
• Document a fix
– how can the vulnerability be resolved
Code Review Techniques
• Control Flow Analysis
– Step through logical conditions in the code
– Look at a function and determines each branch condition.
• loops, switch statements, if statements and try/catch blocks, etc
– Understand the conditions under which each block will be executed
• Data Flow Analysis
– Trace data from the points of input to the points of output
– For each input location determine how much you trust the source of input
• When in doubt you should give it no trust.
– Trace the flow of data to each possible output noting along the way any attempts at data validation
13
Common Hotspots
• SQL Injection
– Look for un-trusted input that can modify the semantics of a SQL query
• Cross-Site Scripting
– Look for user input echoed back as web content
• Data Access
– Look for plain-text data base connection strings and authentication to the database
• Input and Data Validation
– Look for client-side input validation, black-list techniques
• Authentication
– Look for weak passwords, credentials sent in clear-text, long or semi-random sessions
Security Testing
• Be sure to leverage your Threat Model for more focused and effective testing
• Many flaws are caused by environment interaction
– what if a resource is not available?
– will we page that to disk? If so, when?
• Many flaws are only discoverable after analyzing an applications environment
– discover sensitive information by sniffing the network
– uncover temporary files
• Use automated tooling for low-hanging fruit
• Use proven manual testing techniques for elusive bugs
14
Conducting Attacks
Dependency Attacks • block access to libraries
• manipulate registry values
• force application to use corrupt files (write
protected, inaccessible, data errors...) and
file names
• replace files that the application reads from,
writes to, creates and executes
• force application to operate in stressed
memory/disk space/network availability
conditions
User Interface Attacks • overflow input buffers
• examine all command line switches and
input options
• explore escape characters, character sets
and commands
Design Attacks • try common default and test account names
and passwords
• expose unprotected test APIs
• connect to all ports
• fake the source of data
• exploit loop conditions
• use alternate routes to accomplish the
same task
• force the system to reset values
Implementation Attacks • time of check and time of use
• create files with the same name as files
protected with a higher classification
• force all error messages
• look for temporary files and screen their
contents for sensitive information
Activity #6: Deployment Review
• Helps to ensure that application security is not compromised by poor configuration of the network or host.
– even the most securely designed and implemented application can be compromised by an error during deployment
• Covers configuration of both the network and the host
15
Deployment Review: Techniques
• Use server security categories
– Use Server Security Categories to help make deployment reviews for security systematic and repeatable
• Break down your deployment review
– You can use the categories to break down your application deployment for further analysis and to help identify vulnerabilities.
• Review systematically.
– By using categories, you can systematically go through the deployment review process from start to finish or pick a particular category for further analysis
Server Security Categories
Category Practices
Patches and Updates
Patching and updating your server software is a critical first step.
Accounts Accounts allow authenticated users to access a computer. These accounts must be audited. Configure accounts with least privilege to help prevent elevation of privilege. Remove any accounts that you do not need. Help to prevent brute force and dictionary attacks by using strong password policies, and then use auditing and alerts to detect logon failures.
Auditing and Logging
Auditing is one of your most important tools for identifying intruders, attacks in progress, and evidence of attacks that have occurred. Configure auditing for your server. Event and system logs also help you to troubleshoot security problems.
Files and Directories
Secure all files and directories with restricted permissions that only allow access to necessary services and accounts. Use auditing to allow you to detect when suspicious or unauthorized activity occurs.
Ports Services that run on the server listen to specific ports so that they can respond to incoming requests. Audit the ports on your server regularly to ensure that a service that is not secured or that is unnecessary is not active on your server.
Protocols Avoid using protocols that are inherently insecure. If you cannot avoid using these protocols, take the appropriate measures to provide secure authentication and communication.
Registry Many security-related settings are stored in the registry. As a result, you must secure the registry. You can do this by applying restricted Windows access control lists (ACLs) and by blocking remote registry administration.
Services If the service is necessary, secure and maintain the service. Consider monitoring any service to ensure availability. If your service software is not secure, but you need the service, try to find a secure alternative.
Shares Remove all unnecessary file shares. Secure any remaining shares with restricted permissions.
16
How Security Innovation can Help
• Source Software Development Services
– SDLC Process review
– Design & Requirements Review
– Code Review
– Security Testing
• eKnowledge products
– Software and information security eLearning
– Secure Development Knowledgebase and Guidance System
• Data Encryption
– Fastest, most secure cryptography available on the market
eKnowledge Solutions for Secure Development &
Code Review
Software Security eLearning:
– Creating Secure Code
– How to Break Software Security
– Fundamentals of Application Security
– Introduction to Threat Modeling
– Intro to Cryptography
TeamMentor: Secure Development Guidance System
– Out of the box secure development standards and best practices (maps to several compliance reqt’s)
– How-to’s, how not-to’s, code snippets, attacks, checklists
– Targeted, on-demand, context specific application security training
– Dedicated section for software security engineering
17
Try eLearning for free
http://elearning.securityinnovation.com
Free eLearning Course for Attending Introduction to the SDL
