Downloaded 53 times
Uploaded byChris Bailey
JavaOne2013: Secure Engineering Practices for Java
This document summarizes a presentation on secure engineering practices for Java given at JavaOne 2013. It discusses the importance of software assurance over just security controls. It emphasizes that achieving a high level of software assurance requires attention to security throughout the development lifecycle, including risk assessment, secure coding practices, security testing, documentation, and incident response. The presentation recommends that development teams understand security risks and threats in order to build secure software.
More Related Content
Similar to JavaOne2013: Secure Engineering Practices for Java
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
JavaOne2013: Secure Engineering Practices for Java
- 1. JavaOne 2013 Secure EngineeringPractices for Java Tim Ellison, IBM United Kingdom Ltd. CON 3615 © 2013 IBM Corporation
- 2. Important Disclaimers THE INFORMATIONCONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILST EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. ALL PERFORMANCE DATA INCLUDED IN THIS PRESENTATION HAVE BEEN GATHERED IN A CONTROLLED ENVIRONMENT. YOUR OWN TEST RESULTS MAY VARY BASED ON HARDWARE, SOFTWARE OR INFRASTRUCTURE DIFFERENCES. ALL DATA INCLUDED IN THIS PRESENTATION ARE MEANT TO BE USED ONLY AS A GUIDE. IN ADDITION, THE INFORMATION CONTAINED IN THIS PRESENTATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM, WITHOUT NOTICE. IBM AND ITS AFFILIATED COMPANIES SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF: - CREATING ANY WARRANT OR REPRESENTATION FROM IBM, ITS AFFILIATED COMPANIES OR ITS OR THEIR SUPPLIERS AND/OR LICENSORS 2 © 2013 IBM Corporation
- 3. About me Basedin the Java Technology Centre, Hursley UK Working on various runtime technologies for >20 years Experience of open source communities Currently focused on class library design and delivery Overall technical lead for IBM Java 8 SE tim_ellison@uk.ibm.com 3 © 2013 IBM Corporation
- 4. The goal of SecureEngineering Practices is to achieve a high level of Software Assurance Software Assurance is not the same as Security Controls © 2013 IBM Corporation
- 5. Security Controls The mechanismsby which security is established and maintained across the people, data, applications, infrastructure of the system. Security controls, the management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. National Information Assurance (IA) Glossary http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf © 2013 IBM Corporation
- 6. Software Assurance How confidentare we that the entire system comprising people, data, applications, and infrastructure is secure? Software Assurance, a statement of the “level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at anytime during its lifecycle, and that the software functions in the intended manner.” National Information Assurance (IA) Glossary http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf © 2013 IBM Corporation
- 7. The market forsoftware and computing services is evolving Governments and Enterprise customers are adopting procurement requirements that give preference to software and computing services having “high assurance characteristics” over other commercial, off-the-shelf products and services. Many critical business and control systems require a high level of software assurance. © 2013 IBM Corporation
- 8. IBM X-Force Viewof Enterprise Security Incidents in 2012 http://www.ibm.com/services/us/iss/xforce/trendreports/ © 2013 IBM Corporation
- 9. Measuring the assuranceof software and computing services The requirements are evolving… – Meets recognized security standards – Public history of security bulletins & press reports – Passes security tests, including scanning source, automated security testing and penetration testing – Provides evidence that good software engineering practices were applied throughout the development lifecycle Unfortunately, there are no over-arching standards. © 2013 IBM Corporation
- 10. Secure Engineering Goals 1.ofProvidesecurity out the box 2. Proactively respond to new threats and risks Ensure products and solutions provide a reasonable and adequate level of security at time of release, and they maintain and improve security from release to release. Act in a timely fashion for any report of vulnerability in an existing release, and proactively address any new threat that may apply. Achieving a high confidence in software security assurance requires attention throughout the full software lifecycle Development Supply Chain Development Process and Lifecycle Deployment Lifecycle © 2013 IBM Corporation
- 11. Software Assurance Activities Thetools and practices needed within a given project depend upon What is being built (component, product, solution, service or enterprise workload) Where it is expected to be used (closed workgroup, intranet, internet, cloud or critical infrastructure) Operational The relevant risks and threats Code integrity Manual Code Review Security Review of Open Source Architecture Review & Security Requirements Threat Analysis & Mitigation Planning Development Supply Chain Third Party SW Contract Terms Secure Coding Security Source Code Scan Secure Build Security Security Evaluation Evaluation Security System Test Binary Analysis Development Process and Lifecycle Use Case, Abuse Case and Fault Analysis Security Controls mechanisms Source and Object Code Control Pre-Production Assurance (Pen Testing) Monitoring & Analytics Change Mgmt Scanning Deployment Lifecycle Incident Handling © 2013 IBM Corporation
- 12. Adopting Secure DevelopmentPractices Group specific activities that support secure engineering into a set of practices Focusing on development process – Similar can be done for supply chain, deployment, etc Development Supply Chain Tools Practices Risk Assess & Threat Model Development Process and Lifecycle Security Reqmts Secure Coding Security Testing Project Planning Security Document Deployment Lifecycle Incident response Skills Knowledge Education & Awareness © 2013 IBM Corporation
- 13. Risk Assessment andThreat Modeling Essential Practice The goal of this practice is to identify potential risks or attacks against software product or solutions as it will be deployed and to make decisions about how to address these risks during development. 1.Decide what risks are important to the Identify Risks 1.Investigate threats related Analyze Threats software being built those risks 1.Create and adopt a mitigation plan to Plan Mitigations avoid / correct the issues © 2013 IBM Corporation
- 14. The Stride ThreatModel – as an example Spoofing identity Tampering with data An example of identity spoofing is illegally accessing and then using another user's authentication information, such as username and password. Data tampering involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet. Repudiation and Nonrepudiation Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—e.g., a user performs an illegal operation in a system that lacks the ability to trace operations. Non-repudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the receipt as evidence that the user received the package. Information disclosure Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers. Denial of service Elevation of privilege 14 Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability. In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed. http://msdn.microsoft.com/en-us/library/ee823878%28v=cs.20%29.aspx © 2013 IBM Corporation
- 15. Anti-patterns: Addressing securityexclusively through tests Reqmts Without overt actions the code will contain vulnerabilities Code Design Testing tools find ~50% of the known types of vulnerabilities Prod Mgmt team Design team Reqmts Design Remediation “loops” may add two to four months to a project depending on the complexity of the issues discovered 15 Programming team Code / Build Code Scan Test team Test Package / Deploy Maintain Security System Test © 2013 IBM Corporation
- 16. Secure Design Practices Understand the security requirements for the system early Identify risks during design and prototyping and address them Adopt established best practices for recognized risks (patterns), Attack surface reduction, principle of least privilege, defense in depth, security by default, ... Document and describe the assurances you have about the system Developers iterate towards a functional system based on a secure architecture 16 © 2013 IBM Corporation
- 17. Shared Goals PromoteSecure Coding Consistent guidance on Security Risks, Threats & Vulnerabilities Security Advice Reqmts Code may contain vulnerabilities Code Design Testing tools find ~50% of the known types of vulnerabilities Prod Mgmt team Design team Reqmts Design Programming team Code / Build Code Scan 17 Test team Test Package / Deploy Maintain Security System Test © 2013 IBM Corporation
- 18. Secure Coding Asignificant proportion of escaped vulnerabilities are traced to coding errors Developers need to be familiar with the secure coding guidelines, MITRE top 25, etc. Understand the concepts of trusted and untrusted code, tainted data, sensitive data, etc – The team and the application must handle them explicitly – Java 8 annotations can help with classifying constraints and metadata about variables Prioritize departures from the coding standard by failure mode, effects, and criticality – Severity: How serious are the consequences of the error? – Likelihood: How likely is it that a flaw introduced by violating the rule could 18 lead to an exploitable vulnerability? – Remediation cost: How expensive is it to remediate existing code to comply with the standard? © 2013 IBM Corporation
- 19. Security Testing Usethreat modelling to target security testing based on risk – Prioritize testing with manual and tools based scenarios • Breach of access rules • Bad actor • Effect of malformed data • Out of process operations 100x Static analysis – Does the code adhere to the coding guidelines? – Tools and formal code inspections Dynamic testing – SQL injection – Fuzzing – Penetration testing 19 15x 1x design 6x coding verification release © 2013 IBM Corporation cost Numerous studies show the cost of finding and fixing vulnerabilities rises exponentially through the development lifecycle
- 20. Security Documentation Allreleases should be secure by design in their default configuration High quality documentation about how to use a system securely is equally important Users need clear guidelines about the security impact to modifying configurations – Inform users about secure deployment, and balancing usability with security – Security should be addressed as a specific topic, not spread throughout the documentation Explain the impact of configurations that increase the attack surface of the system, e.g. – Backwards compatibility – Choice of communications protocols – Guest and demo accounts Provide examples and templates for hardening the system in specific scenarios Use threat modeling conclusions to inform users about best practices 20 © 2013 IBM Corporation
- 21. Security Incident Response Expect security incidents even after following careful secure engineering practices Incident response policy and plan – Establishing communications internally and externally – Be prepared for any eventuality, but focus on expected attacks attrition web-based hardware level e-mail improper usage loss / theft Establish robust means of detecting and verifying incidents – logging, audits, external reports, validation checks, ... Create guidelines for prioritizing incidents – Functional impact to the business – Information impact to confidentiality, integrity and availability of business data – Recoverability from incident occurrence Learn lessons from incidents – Ensure the organization improves based on the history of security incidents © 2013 IBM Corporation
- 22. Education and Environment Software assurance requires positive action maintained throughout the full system lifecycle Development Supply Chain Tools Practices Risk Assess & Threat Modeling Development Process and Lifecycle Security Reqmts Secure Coding Security Testing Project Planning Security Document Deployment Lifecycle Incident response Skills Knowledge Education & Awareness Ensure development team has the same knowledge and perspective that adversaries might use. © 2013 IBM Corporation
- 23. Security Advice Expert Knowledge Actors Risks Assets Design team Programming team Threats Permissions Exploits Platforms Attacks Tools User Stories Common Weaknesses Defense inDepth Test team Users Roles Support team D e fe n s e s Vulnerability History Security Perimeter White hat Languages Security Controls Malware Black hat © 2013 IBM Corporation
- 24. Secure Engineering isthe responsibility of the entire development All job roles need an understanding of the concepts Awareness and organization Education Project Planning Architects and Designers need to ensure that best practices for session handling, information protection, etc. are included in Design Specifications, Use Cases and Security Test Plans Secure Coding Test team Architects and Designers need to review the security characteristics of existing software and document a Threat Model for new software Security Requirements Design team Project/Release Managers need to include Secure Engineering in Project Planning activities Risk Assessment and Threat Modeling Management team and the implications of Security in Development Developers need to ensure that coding and configuration techniques are appropriate Security Testing Test Teams need to learn about security testing and perform Security Testing using AppScan, with appropriate test plan and policy Security Documentation Information Developers need to ensure that all offerings include appropriate Security Documentation Security Incident Response Support Teams must participate in Security Incident Response Process Programming team Support team © 2013 IBM Corporation
- 25. Summary Security Controlsand Software Assurance are both critical to enterprise users Continued evidence of vulnerabilities in software has changed the focus from security controls and defenses to controlling the risk of security incidents. To build secure software, development teams need to understand risks throughout the development lifecycle. There are risks related to weaknesses in design, coding and integration, as well as, in use cases and abuse cases related to deployment models for critical business processes and workloads. Development Teams need to grow skills in analyzing risks and threats and use the available tools. © 2013 IBM Corporation
- 26. © 2013 IBMCorporation
- 27. Photo attributions Chart7 – MRI = Jan Ainali – ATM = DaviSements – Car = Kevin Rodriguez Ortiz Chart 16 – Coder = Matthew (WMF) Chart 20 – Writer = greg.turner © 2013 IBM Corporation