Upload
chris-bailey
View
1.080
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Developing programs that are inherently immune to attack requires sound software engineering practices. This session looks at the overall software engineering lifecycle and the critical points at which software security is a specific consideration. From the requirements for third-party suppliers to in-house development, your process must offer a level of confidence that the software functions as intended and is free of vulnerabilities. The presentation shows how using threat models, code pattern analysis tooling, targeted reviews, and more enhances Java security.
Citation preview
© 2013 IBM Corporation
JavaOne 2013
Secure Engineering Practices for Java
CON 3615
Tim Ellison, IBM United Kingdom Ltd.
© 2013 IBM Corporation
Important Disclaimers
THE INFORMATION CONTAINED 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
About me
Based in 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
3
© 2013 IBM Corporation
Software Assurance is not the same as Security Controls
The goal of
Secure Engineering Practicesis to achieve a high level of
Software Assurance
© 2013 IBM Corporation
Security Controls
The mechanisms by 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
Software Assurance
How confident are 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
The market for software and computing services is evolvingGovernments 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
IBM X-Force View of Enterprise Security Incidents in 2012
http://www.ibm.com/services/us/iss/xforce/trendreports/
© 2013 IBM Corporation
Measuring the assurance of 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
Secure Engineering Goals
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.
Provide security out of the box
Proactively respond to new threats and risks
1.
2.
DeploymentLifecycle
Development Processand Lifecycle
Development Supply Chain
Achieving a high confidence in software security assurance requires attention throughout the full software lifecycle
© 2013 IBM Corporation
Software Assurance ActivitiesThe tools 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)
The relevant risks and threats
ArchitectureReview
& SecurityRequirements
SecuritySource
CodeScan
SecureCoding
BinaryAnalysis
Code integritymechanisms
SecurityEvaluation
Incident Handling
Use Case, Abuse Case and Fault Analysis
Source and Object Code Control
DeploymentLifecycle
Development Processand Lifecycle
Development Supply Chain
Security Reviewof Open Source
Manual Code
Review
Change Mgmt
Operational SecurityControls
SecuritySystem Test
Pre-Production Assurance (Pen Testing)
Scanning
Monitoring& Analytics
Threat Analysis &Mitigation Planning
Third Party SW Contract Terms
SecureBuild
SecurityEvaluation
© 2013 IBM Corporation
Adopting Secure Development Practices
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
DeploymentLifecycle
Development Processand Lifecycle
Development Supply Chain
Tools
Practices
SecurityReqmts
SecureCoding
Security Document
Security Testing
Incidentresponse
Education & Awareness
Project Planning
Skills
Knowledge
Risk Assess &
Threat Model
© 2013 IBM Corporation
Risk Assessment and Threat Modeling Essential Practice
1.Decide what risks are important to the software being built
1.Investigate threats related those risks
1.Create and adopt a mitigation plan to avoid / correct the issues
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.
PlanMitigations
Identify Risks
Analyze Threats
© 2013 IBM Corporation14
The Stride Threat Model – as an exampleSpoofing
identityAn example of identity spoofing is illegally accessing and then using another user's authentication information, such as username and password.
Tampering with data
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 Non-
repudiation
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
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.
Elevation of privilege
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 Corporation15
Anti-patterns: Addressing security exclusively through tests
Design Code / Build
Test Package / Deploy
MaintainReqmts
Design team
Programming team
Test team
Prod Mgmt team
Design CodeReqmts
Security System Test
Code Scan
Testing tools find ~50% of the known types of vulnerabilities
Without overt actions the code will contain vulnerabilities
Remediation “loops” may add two to four months to a project depending on the complexity of the issues discovered
© 2013 IBM Corporation16
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
© 2013 IBM Corporation17
Design Code / Build
Test Package / Deploy
MaintainReqmts
Design team
Programming team
Test team
Prod Mgmt team
Design CodeReqmts
Security System Test
Code Scan
Testing tools find ~50% of the known types of vulnerabilities
Consistent guidance on Security Risks, Threats & Vulnerabilities
Code may contain vulnerabilities
SecurityAdvice
Shared Goals Promote Secure Coding
© 2013 IBM Corporation18
Secure Coding A significant proportion of escaped vulnerabilities are
traced to coding errors
Developers need to be familiar with the secure codingguidelines, 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
lead to an exploitable vulnerability?– Remediation cost: How expensive is it to remediate existing code to comply
with the standard?
© 2013 IBM Corporation19
Security Testing Numerous studies show the cost of finding and fixing vulnerabilities rises exponentially through the
development lifecycle
Use threat 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
Static analysis– Does the code adhere to the coding guidelines?– Tools and formal code inspections
Dynamic testing– SQL injection– Fuzzing– Penetration testing
1x 6x15x
100x
design coding verification release
cost
© 2013 IBM Corporation20
Security Documentation All releases should be secure by design in their default configurationAll releases should be secure by design in their default configuration
High quality documentation about how to use a system securely is equally importantHigh quality documentation about how to use a system securely is equally important
Users need clear guidelines about the security impact to modifying configurationsUsers need clear guidelines about the security impact to modifying configurations
– Inform users about secure deployment, and balancing usability with securityInform users about secure deployment, and balancing usability with security– Security should be addressed as a specific topic, not spread throughout the Security should be addressed as a specific topic, not spread throughout the
documentationdocumentation
Explain the impact of configurations that increase the attack surface of the system, e.g.Explain the impact of configurations that increase the attack surface of the system, e.g.– Backwards compatibilityBackwards compatibility– Choice of communications protocolsChoice of communications protocols– Guest and demo accountsGuest and demo accounts
Provide examples and templates for hardening the system in specific scenariosProvide examples and templates for hardening the system in specific scenarios
Use threat modeling conclusions to inform users about best practicesUse threat modeling conclusions to inform users about best practices
© 2013 IBM Corporation
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-basedhardware level
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
Education and Environment
Software assurance requires positive action maintained throughout the full system lifecycle
Ensure development team has the same knowledge and perspective that adversaries might use.
DeploymentLifecycle
Development Processand Lifecycle
Development Supply Chain
Tools
Practices
Risk Assess &
Threat Modeling
SecurityReqmts
SecureCoding
Security Document
Security Testing
Incidentresponse
Education & Awareness
Project Planning
Skills
Knowledge
© 2013 IBM Corporation
Programming team
Support team
Design team
Test team
D e fe n s e s
SecurityAdvice
Threats
CommonWeaknesses
Security Controls
Assets
Users
User Stories
Risks
VulnerabilityHistory
Actors
Roles
PermissionsExploits
Attacks
Defensein Depth Security
Perimeter Malware
Languages
Platforms Tools
Black hat
White hat
Expert Knowledge
© 2013 IBM Corporation
Programming team
Support team
Design team
Test team
Awareness and Education
All job roles need an understanding of the concepts and the implications of Security in Development
Project Planning Project/Release Managers need to include Secure Engineering in Project Planning activities
Risk Assessment and Threat Modeling
Architects and Designers need to review the security characteristics of existing software and document a Threat Model for new software
Security Requirements
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 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
Management team
Secure Engineering is the responsibility of the entire development organization
© 2013 IBM Corporation
Summary
Security Controls and 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
© 2013 IBM Corporation
Photo attributions
Chart 7– MRI = Jan Ainali– ATM = DaviSements– Car = Kevin Rodriguez Ortiz
Chart 16– Coder = Matthew (WMF)
Chart 20– Writer = greg.turner