7. 7
Holistic View: Software vs. Application
Security
Security applied
by catch and
patches
Security built
into each phase of
the SDLC
Look at root
problem
causes
Look at
external
symptoms
Reactive,
Incident Response,
Compliance
Proactive,
Threat Modeling,
Secure Code Reviews
14. 14
Security Requirements
Encompasses both functional requirements for
security controls and risk mitigation driven
requirements from the abuse case scenarios
Define Security Requirements in Standards
Which controls are required (e.g. authentication,
authorization, encryption etc)
Where should be implemented (e.g. design, source code,
application, server)
Why are required
Compliance and auditing
Mitigation for known threats
How should be implemented and tested
15. 15
Functional and Non Functional Requirements
Functional Requirements:
Define the expected functionality of security controls
Depends on the applicable standards, policies and
regulations
Positive statements
“the application will lockout the user after 6 failed logon
attempts”
“passwords need to be 6 min characters, alphanumeric”
Risk Driven Security Requirements
Address all common vulnerabilities
Can be derived by use (or misuse) cases
Negative statements
The application should not allow of the data being altered or
destroyed
The application should not be compromised or misused for un-
authorized financial transaction by a malicious user.
18. 18
Threat Modeling
Categorizes the threats to the
application, highlights potential
vulnerabilities and identifies
countermeasures to be developed
Use a systematic fact based and
methodical approach:
1. Scope Assessment
Requirements, Use Cases
1. System Modeling
Physical and Logical View, Data Flows, Trust
Boundaries, Entry Points
1. Threat Identification
STRIDE, ASF
1. Threat Vulnerabilities and Attacks
Checklists, Attack Vulnerability Mapping
1. Identification of Countermeasures
Security Controls
1. Threat Prioritization and Risk Ranking
Risk Modeling
23. 23
Security Design Reviews
Objective is promote secure design and identify
of potential flaws before construction phase
Secure Architecture Review Process
Review High Level Design documents and verify that
security controls requirements are documented
Engage with:
Architects
Application Security Experts
Provide guidance on security technology/design
patterns
Identify potential gaps in security controls with threat
modeling
25. 25
Secure Coding Standards/Guidelines
Describe secure coding requirement in terms of:
1. The common vulnerabilities (e.g. OWASP
T10)
2. The issue type (e.g. Application Security
Frame)
3. The security threat or how can be
exploited
4. The in-secure code root cause of the
vulnerability
5. The “How to” find the vulnerability with
black box and white box testing
6. The secure coding
requirement/recommendation
26. 26
Example SQL Injection - Secure coding
requirements
Use SQL parameterized queries, avoid
dynamic SQL generation:
SELECT * FROM users WHERE username=?
JAVA EE use strongly typed “PreparedStatement”
in .NET use “SqlCommand” with “SqlParameters”
Sanitize input, remove special characters:
' " ` ; * % _ =&|*?~<>^()[]{}$nr
Use custom error messages:
No SQL exception information in error messages
27. 27
Secure Code Reviews
Objectives:
Identification of security issues in source code, the type of the
issue, the severity and recommendation on how should be fixed
Can be used to validate secure coding standards
Security assessment before releasing to QA and
production
Methodologies:
Automated Focused Source Code Analysis
Focus is on validation of false positives and auditing of
automated scan results
Manually Focused Secure Code Review
Focus is on identification of security issues as bugs vs. flaws
by categorizing the issues by type of vulnerability introduced
30. 30
Security Testing
Develop security test cases
Positive functional security test cases
Negative test cases (from use and misuse cases)
Common vulnerabilities exposure
Integrate Tests in Developers and Testers
Workflows
Static and Dynamic Testing, Unit Tests
Integrated System Tests and Operational Tests
Analyze and report test data
Defect Management
Root Cause Identification
31. 31
Security Testing Example: XSS
Define Test Case
Test login web page for XSS
Testing Procedure
Type the following strings in input
fields
<script>alert()</script>;
javascript:alert()
+ADw-SCRIPT+AD4-alert();+
Pass: Input validation Error is
through to the user
Fail: an alert dialog box is seen in
the browser window.
34. 34
Secure Deployment And Configuration
Items
Ensure the server configuration is secure
Only essential services, server hardening policies
Protect Access To Application Files/Data
XML files, property files, scripts, databases, directories
Enable Auditing And Logging
Enable all secure auditing and logging, protect logs
Enforce Change Management Controls
Don’t allow configuration changes without oversight
Audit configuration data
Release Securely
Don’t allow releases to ship without a security review
36. 36
Application Security Defect Tracking and
Metrics
Define where and how security metrics is collected
Tracking security defects throughout the SDLC
Report the root causes: requirements, design, code,
application
Report the type of the issues, the severity and whether
has been fixed or no
Metrics
What lifecycle stage are most flaws originating in?
What security mechanisms/controls are we having trouble
implementing?
What security vulnerabilities are we having trouble fixing?
37. 37
Examples of Application Security Metrics
Process Metrics
Is a SDL is used are security
gates enforced?
Is code validated against
security standards?
Security posture of a new
application before delivery
Security Officers Sign Off?
Test For Security
Vulnerabilities Executed?
All high risk issues closed?
Risk assessments completed?
% of developers trained, using
organizational security best
practice technology,
architecture and processes
Management Metrics
% of applications rated
“business-critical” that have
been security tested
% of projects that where
developed with the SDL
% of security issues identified
by lifecycle phase
% of issues whose risk has
been accepted
% of security issues being
fixed
Average time to correct
vulnerabilities
Business impact of critical
security incidents.
38. 38
Security Metrics Goals The Good and The Bad
Good: if goals when are “SMART” that is Specific,
Measurable, Attainable, Realistic, Traceable and
Appropriate
Example: reducing the overall number of vulnerabilities by
30% by fixing all low hanging fruits with source code analysis
during construction
Bad: if the goals justify the means to obtain the goals
40. 40
Business Cases for Your Organization
Tie the metrics to the business cases and support the
project stakeholders agendas:
Developer Leads: show that software can be build more
securely and efficiently
Project Managers: shows that projects are on schedule and
moving on target for the delivery dates and are getting better
during tests
Information Security Officers: provides a level of assurance
that security standard compliance is addressed through the
security review processes within the organization.
Benefits:
Cost savings
Risk measurement and reduction
Compliance reporting
41. 41
Business Cases And Software Security
StrategyBe realistic on what can be achieved
Organization is not yet ready (e.g. mature)
Engineers are not trained in software security
There are no tools available
Adapt the strategy to reality
Build upon your company strenghts
Get stakeholders buy in (CIOs, ISOs, PM, Developers,
Architects)
Set achieveable goals: reduce 30% of vulnerabilities
found through ethical hacking via source code analysys
Perform a gap analysis and proceed with process
improvement cycles:
Tailor to the initiative to the company culture
Be risk management driven
Introduce metrics and prove results
Notas del editor
I plan to start at 2.30 and finish at 3 PM
Parlero degli scenari di incidenti delle risposte a tali incidenti e delle strategie per remdiare nel long term. Parlero anche di come creare “consapevolezza” e della
Software security initiative.
There are bad guys and good guys and some they just looking for work, be careful of responsible disclosure going public with a zero day can go against you. On the other hand also ignoring the vulnerabilities you are suppose to fix is not a very responsbile approach
The most common approach to finding vulnerabilities is to analyze the running application. The two techniques are “vulnerability scanning” (using tools and signature databases) and “penetration testing” (custom testing by experts). However, for many types of problems, analyzing the running application is very time-consuming and inaccurate. SQL injection, for example, is very difficult to find and diagnose in a running application, but can be quickly found by analyzing the source code.
The other approach is to analyze the source code. Like pentesting, this can be done manually (source code review) or with tools (static analysis). Code-based approaches have a reputation for being expensive and time-consuming, but this reputation is unfounded. For many types of issues, using the code is many times faster and more accurate than penetration testing.
The most cost-effective approach to application security is a “combined” or “integrated” approach. The assessor should be encouraged to use the most appropriate tool to find problems in the most cost-effective manner. For example, an assessor may notice a potential vulnerability during a penetration test, automatically scan the code for possible instances of the problem, and then confirm using code review.
Note that the purely automated approaches (scanning and static analysis) are especially ineffective for application security (most experts put the effectiveness of pure scanning or static analysis at less than 20%). This is largely due to the custom nature of applications. Because each one is different, there is no database of signatures the automated tools can use.
Ultimately a mature software security process blends both information risk management and software engineering processes in a software security framework. For example, threat modeling will identify threats and technical impacts during design that are used as a factor along with business impact in the calculation of the overall risk. Ideally, such mature software security process should integrate software security activities in each phase of the SDLC. This also included activities that are performed as part of the operation life-cycle such as patch and incident management as well foundational activities such as metrics and measurements and security training and awareness.
Ideally, for a software security framework to be useful in practice, it needs to apply to the different software development methodologies used by your organization. This might include evolutionary-interactive software life-cycles such as spiral, RUP, XP and Agile besides the traditional waterfall model but also.
In case of RUP and Agile for example this means that such software security best practices need to be iterated as the software evolves and reviewed at each interaction depending on the available artifacts.
Another pre-condition is focusing on software security awareness that is communicating to the project stakeholders what software security entitles to that is when and how security needs to be applied to the application, in better terms explaining the difference between application and software security.Applications vs. software are best described as the Chinese philosophy “yin” and “yang” concepts: opposing and, at the same time, complementary (completing) aspects of any one software development process when seen from different perspectives. For example, from the “when” perspective is applying security after application is already build vs. while the application is being build, from the problem solution perspective is looking at the sympthoms instead of the root causes, from the approach perspective is catch and patch vs. building security throughout the software life cycle and from the risk perspective is reactive response to security incidents via implementation of “band-aid” solutions vs. proactive threat analysis, risk assessment and implementation of countermeasures as necessary.
So you need a road map, start with assessing the maturity of the PPT in place, then definition of the processes to build security into the SDLC and the security activities. Then you cannot manage if you do not measure and risk menagement expecially needs vulnerability metrics for example. Finally you can make the case with your data and set objectives moving forward.
Essential elements: Verification check points, developer’s training and tools.
The aim of the Software Development Lifecycle SDL is to integrate tasks and checkpoints in the software development organization’s processes so that software security can be improved with well defined security reviews and security deliverables. Critical to the effectiveness of the SDL implementation is the ongoing education and training for software developers and the techniques and technologies required for secure development. Figure 2 depicts at high level the phases of the SDL and the software security activities:
Figure 2: MS SDL
The SDL software security activities (the yellow blocks) map to the SDLC (the big arrows) such as:
Definition of security feature requirements during the requirements phase
Security architecture design, best practices and threat modeling during design
Static analysis via automation tools during implementation
Application of coding and testing standards during implementation
Code reviews during implementation
Security focused testing, pen and fuzz testing, during the verification phase
Security servicing and response during operations (post release)
Pro and Cons:
Con: Threat analysis as is done in the MS SDL is very product oriented and static because is build around the Microsoft risk model STRIDE/DREAD. This risk model might work well for a software development shop and for shrink wrapped software development but it will not be suitable for applications developed for organizations that use proprietary risk management models such as financial and banking institutions for example.
Pro: Microsoft products that have adopted the SDL such as SQL Server 2003, Vista and IE6 had significant less security issues then products that did not use it. This is data validated by comparing with the number of vulnerabilities in software versions developed prior to the introduction of the SDL: software developed under the SDL have exhibited over a 50% reduction in vulnerabilities
Pro: The SDL methodology is adequately supported by tools such as threat modeling and source code analysis tools. Some of these tools (e.g. Prefix and Prefast) are part of Microsoft Integrated Development Environment for which a license is needed while others are free (e.g. ACE Torpedo TM). So far SDL is the only security-enhanced lifecycle process model that support threat analysis with a tool.
Pro: MS SDL is very well documented, easily accessible via MSDN web site and very extensive including secure software handbooks for developers, threat and countermeasures guidelines and checklists etc.
Security will need to be baked into each of the development steps as well, but that will not be the primary focus on that particular step. Particularly for the acceptance tests and QA steps.
OWASP believes that clearly articulating an application security requirements guide detailing both high-level and specific requirements is the best way to ensure that a strong, robust yet workable guide can become default in all aspects of application security.
Take LMCO standard and tailor it
Refine: “You will do access control”
Into: This is the access control matrix & this is how it will be enforced.
- we will use netegrity to implement this policy
Adaptation of a proven object-oriented modeling technique, use cases, to capture and analyze security requirements in a simple way.
We define a use case as a specification of a type of complete interaction between a system and one or more actors.
We define an abuse case as a specification of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system.
The graphical example in Figure TBD depicts the derivation of security requirements via use and and misuse cases. The functional scenario consists on the user action: entering username and password and for the application actions: authenticate the user and provide for an error message if validation fails. The misuse case consists on the actions: hacker trying to break authentication by brute forcing the password via a dictionary attack and by guessing the valid username from the error messages. By graphically representing the threats to the user actions (misuses) it is possible to derive the countermeasures as the application actions that mitigate such threats.
Threat modeling implies a view of the architecture in terms of users accessing assets (web servers, data) through protocols crossing trust boundaries.
It is a king of end to end data flow schematic. The notation is not important, rather to be comprehensive enough to identify gaps in controls and countermesures.
Threat is un-authorized access to data, the vulnerability can be leaving the computer un-attended via shared terminal, a SQL injection attack, elevation of privileged from a logged session or simply access to data from the browser that allows you to get to the data.
All the orange ones are vulnerabilities while the green ones are the countermeasures
Data flows diagrams and attack trees (threat definition) and secure requirements (Scope definition) all feed the threat model.
The result is the identification of threats, the risk of such threats and the countermeasures that mitigate such threats.
The threat model is also used for secure code reviews as a why to determine along with secure coding standards that threats are mitigated.
Not trying to reinvent the whole SDLC, just trying to insert a few key activities that will help generate more secure code.
Once you have decided the categorization, that is STRIDE, ASF, MITRE CVE etc you need to document the vulnerability and the type
By describing the security threat you help the developer to understand how an attacker can exploit the vulnerability (real example in plain english)
The software root cause is the an example of offending security defect, the how to should cover both white box and black box depending if the code is already integrated as part of the application, the countermeasure is the code fix, configuration change, design change and the risk rating is the assigned value to the risk of the vulnerability
Find issues
Validate standards
Act as a gateway
There is not such a thing like a fully automated process, false positives need to be validated. A manually focused source code analysis can find more issues than automated validation only
Validation of false positives, tools provide knowledge to the developers and point to root causes. The validation is in terms of relevance, some issues are quality issues
Security testing as part of the testing workflow is still in his infancy
If the requirements (Security) are written down the normal testing process should work.
General testing procedures can be adapted for security tests. Some can be conducted manually some need the help of tools
Discussion? Security flaws are often sensitive. Should they be treated differently
Combine looking for quick wins while setting out a roadmap