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 Seattle
– 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
Boston
• 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
1

2. Agenda
• Security Engineering overview
• Six key Security Engineering Activities
• How to adopt these activities incrementally
to maximize your security ROI
• Conclusion
Security Engineering: What it is and what it entails
• Integrating security into your lifecycle
– Upfront security design, secure coding practices, and testing for security must all
be an integral part of your application development processes
• Identifying your objectives
– Understanding early what the security objectives are for your application
– Will play a critical role in shaping threat modeling, code reviews, and testing
• Knowing your threats
– Analyzing your application in a structured and systematic way to recognize its
threats and vulnerabilities
• Using an iterative approach
– Some activities should be performed multiple times during the development
process in order to maximize application security
2

3. Security Engineering: What it is and what it entails
Threats, Vulnerabilities, Attacks & Countermeasures
• 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.
3

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.
4

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?
5

6. Identifying Security Objectives - Approach
• Roles Matrix
Objects
User Permission Object Object Object
Subjects creation modification creation removal read
Admin x x
Content
Creator x x x
Reader x
Anonymous x
• Derive from functional requirements
Original Requirement Derived Security Objectives
Administrator must be able to add users C – Protect user names and permissions from disclosure to a non- administrator
and change user permissions through an I – Restrict non-administrator from adding users and changing user permissions
administrator interface.
A – Application is available so that the administrator is able to add users and change
user permissions
Each application server must be able to A – Application server is available for users
serve 1000 concurrent users.
Registered users must be able to C – Protect registered user credentials and other sensitive information from non-
purchase books from the web user- administrators and non-registered users
interface 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
6

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.
7

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.
8

9. Threat Modeling – Activity Summary Table
Input Step Output
 Business requirements Step 1: I  Key security objectives
 Security policies identify security objectives
 Compliance requirements
 Deployment diagrams Step 2:  Whiteboard-style diagram with
 Use cases Create an application overview end-to-end deployment scenario
 Functional specifications  Key scenarios
 Roles
 Technologies
 Application security mechanisms
 Deployment diagrams Step 3:  Trust boundaries
 Use cases Decompose your application  Entry points
 Functional specifications  Exit points
 Data flow diagrams  Data flows
 Common threats Step 4:  Threat list
Identify threats
 Common vulnerabilities Step 5:  Vulnerability list
Identify vulnerabilities
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
9

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
tiers.
10

11. Activity #5: Performing Security Code Reviews & Testing
• Code Review
– 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
Conducting the Code Review
Methodology
1. Identify Code Review Iterative Process
Objectives
Inputs
• Design documentation
• Architecture diagram
• Data flows
2. Perform • Usage scenarios
Preliminary • Inspection questions
Scan
Outputs
• Inspection questions
4. Review for 3. Review for • Prioritized list of problems to fix in
Unique Issues Common Issues the code
11

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
12

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
13

14. Conducting Attacks
Dependency Attacks Design Attacks
• block access to libraries • try common default and test account names
• manipulate registry values and passwords
• force application to use corrupt files (write • expose unprotected test APIs
protected, inaccessible, data errors...) and • connect to all ports
file names • fake the source of data
• replace files that the application reads from, • exploit loop conditions
writes to, creates and executes
• use alternate routes to accomplish the
• force application to operate in stressed same task
memory/disk space/network availability
• force the system to reset values
conditions
Implementation Attacks
User Interface Attacks • time of check and time of use
• overflow input buffers
• create files with the same name as files
• examine all command line switches and protected with a higher classification
input options
• force all error messages
• explore escape characters, character sets
• look for temporary files and screen their
and commands
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
14

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 Patching and updating your server software is a critical first step.
Updates
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 Auditing is one of your most important tools for identifying intruders, attacks in progress, and
Logging evidence of attacks that have occurred. Configure auditing for your server. Event and system
logs also help you to troubleshoot security problems.
Files and Secure all files and directories with restricted permissions that only allow access to necessary
Directories 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.
15

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
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
Software Security eLearning:
– Creating Secure Code
– How to Break Software Security
– Fundamentals of Application Security
– Introduction to Threat Modeling
– Intro to Cryptography
16

17. Try eLearning for free
http://elearning.securityinnovation.com
Free eLearning Course for Attending
Introduction to the SDL
SDL for Management
Introduction to Threat Modeling
“Security Engineering Explained” Whitepaper
jtaylor@securityinnovation.com
17