JavaOne2013: Secure Engineering Practices for Java

© 2013 IBM Corporation

JavaOne 2013

Secure Engineering Practices for Java

CON 3615

Tim Ellison, IBM United Kingdom Ltd.


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


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

[email protected]

3


Software Assurance is not the same as Security Controls

The goal of

Secure Engineering Practicesis to achieve a high level of

Software Assurance


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

http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf



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




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.


IBM X-Force View of Enterprise Security Incidents in 2012

http://www.ibm.com/services/us/iss/xforce/trendreports/




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.


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


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



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


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



Tools

Practices

SecurityReqmts

SecureCoding

Security Document

Security Testing

Incidentresponse

Education & Awareness

Project Planning

Skills

Knowledge

Risk Assess &

Threat Model


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




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


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


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


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?


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


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


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

e-mail

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


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



Tools

Practices

Risk Assess &

Threat Modeling

SecurityReqmts

SecureCoding

Security Document

Security Testing

Incidentresponse

Education & Awareness

Project Planning

Skills

Knowledge


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


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


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.


Photo attributions

Chart 7– MRI = Jan Ainali– ATM = DaviSements– Car = Kevin Rodriguez Ortiz

Chart 16– Coder = Matthew (WMF)

Chart 20– Writer = greg.turner

JavaOne2013: Secure Engineering Practices for Java

Technology

Transcript of JavaOne2013: Secure Engineering Practices for Java