Software security engineering
•Download as PPT, PDF•
1 like•918 views
Approaches To Application Security, Roadmap, Security Requirements
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Software security engineering
Similar to Software security engineering (20)
More from AHM Pervej Kabir
More from AHM Pervej Kabir (16)
Recently uploaded
Recently uploaded (20)
Software security engineering
- 1. 1
- 2. 2 Agenda 1. Approaches To Application Security 2. Software Security Roadmap (CMM, S-SDLCs) 3. Software Security Activities And Artifacts Security Requirements and Abuse Cases Threat Modeling Secure Design Guidelines Secure Coding Standards and Reviews Security Tests Secure Configuration and Deployment 1. Metrics and Measurements 2. Business Cases
- 3. 3 Approaches To Application Security
- 4. 4 The “Know But Ignore” Approach: Do Not Act
- 5. 5 Tactical View: Finding Vulnerabilities AutomatedAutomated VulnerabilityVulnerability ScanningScanning AutomatedAutomated Static CodeStatic Code AnalysisAnalysis ManualManual PenetrationPenetration TestingTesting ManualManual CodeCode ReviewReview
- 6. 6 Strategic View: Manage Software Risks
- 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
- 9. 9 Software Security Roadmap 1. Assess the maturity of the organization software security development processes, people and tools 2. Define the software security process: security enhanced SDLCs, frameworks and checkpoints 3. Implement software security activities 1. Security Requirements 2. Secure Design and Threat Modeling 3. Secure Coding Guidelines and Security Code Review 4. Security Testing 5. Secure Deployment 4. Collect metrics and measurements 5. Create business cases and set objectives
- 10. 10 Security-enhanced lifecycle process (S-SDLC) models: MS-SDL , CLASP
- 11. 11 Building Security In the Waterfall SDLC Threat Modeling Secure Requirements Secure Code Reviews Security Testing
- 12. 12 Periodic Security Sprints Build Security in Agile SDLC Threat Model Stakeholder Security Stories Application Security Assurance Review Periodic Security Sprints { 12
- 13. 13 Security Requirements and Abuse Cases
- 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.
- 16. 16 Security Requirements Derivation Through Use and Misuse Cases Source: OWASP Testing Guide Vs 3 Introduction
- 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
- 19. 19 System Modeling: Data Flow Diagrams Source: Threat Modeling Dr James Walden
- 21. 21 Threat Modeling in the SDLC
- 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
- 24. 24 Secure Coding Standards and Secure Code Reviews
- 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.
- 32. 32 Testing Tools Categorization and Examples Vulnerability Scanning ISS, Foundscan, Nessus, Nikto Fault Injection Testing (Black Box Testing) Webinspect, Appscan, Hailstorm, Paros, Peach Binary Analysis IDA Pro, @stake SmartRisk Source Code Analysis Fortify, Klockworks, Parasoft, Free Tools (e.g. FindBugs) Threat Modeling MS TAM, TRIKE, PTA Technologies Rootkit BackDoor Analysis ootkits.org and rootkit.nl
- 33. 33 Secure Configuration And Deployment
- 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
- 39. 39 Business Case
- 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
Editor's Notes
- 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