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.

1. JavaOne 2013
Secure Engineering Practices
for Java
Tim Ellison, IBM United Kingdom Ltd.
CON 3615
© 2013 IBM Corporation

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

3. 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
tim_ellison@uk.ibm.com
3
© 2013 IBM Corporation

4. The goal of
Secure Engineering 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 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

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

7. The market for software 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 View of Enterprise Security Incidents in 2012
http://www.ibm.com/services/us/iss/xforce/trendreports/
© 2013 IBM Corporation

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

10. Secure Engineering Goals
1.ofProvide security
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
The 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)
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 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
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 and Threat 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 Threat Model – 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 security exclusively 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 Promote Secure 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
 A significant 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
 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
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
 All releases 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
in Depth
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 is the 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 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

26. © 2013 IBM Corporation

27. Photo attributions
 Chart 7
– MRI = Jan Ainali
– ATM = DaviSements
– Car = Kevin Rodriguez Ortiz
 Chart 16
– Coder = Matthew (WMF)
 Chart 20
– Writer = greg.turner
© 2013 IBM Corporation