Building world-class security response and secure development - - PowerPoint PPT Presentation

Building world-class security response and secure development processes

David Jorm, Senior Manager of Product Security, IIX

#ODSummit

Outline

• Introductjon
• SDN atuack surface
• Recent OpenDaylight vulnerabilitjes
• Defensive technologies
• Security response best practjces
• Secure engineering best practjces
• OpenDaylight security: current status
• OpenDaylight security: vision

#ODSummit

Introduction

• Sofuware engineer for 15 years, climatology domain
• Last 5 years focusing on security, mainly Java
• Led Red Hat's Java middleware security team
• Currently manager of product security for IIX, and a founding member of the ODL security

response team

• Based in Brisbane, Australia (beautjful place, shame about the tjmezone)

#ODSummit

SDN Attack Surface

#ODSummit

SDN Attack Surface

• Traditjonal networks confmate the control and data planes on a physical device
• Sofuware-defjned networks factor the control plane out to a SDN controller
• The controller uses a protocol such as OpenFlow to control switches, which are now only

responsible for handling the data plane

• Security advantage: easy segregatjon of the control plane network from the productjon

data plane network

• Security disadvantage: the SDN controller's ability to control an entjre network makes it a

very high value target

#ODSummit

SDN Attack Surface

#ODSummit

SDN Attack Surface

• SDN controllers are also exposed via the data plane
• When an OpenFlow switch encounters a packet that does not match any forwarding rules,

it passes this packet to the controller for advice

• As a result, it is possible for an atuacker who is only able to send data through a switch to

exploit a vulnerability on the controller

• We will see a real-life example later in the presentatjon

#ODSummit

SDN Attack Surface

#ODSummit

Recent OpenDaylight Vulnerabilities

#ODSummit

Netconf XXE (CVE-2014-5035)

• Netconf (and restconf) API processes user-supplied XML
• By default, Java XML parsers do not disable external entjty processing
• This led to a textbook XXE vulnerability
• Example of vulnerable code, with the patch applied:

controller/opendaylight/netconf/netconf- utjl/src/main/java/org/opendaylight/controller/netconf/utjl/xml/XmlUtjl.java

#ODSummit

Netconf XXE (CVE-2014-5035)

#ODSummit

Topology spoofing via host tracking (CVE-2015-1610)

• Most SDN controllers include host tracking, allowing hosts to migrate between difgerent

physical locatjons in the network

• Host tracking is based on monitoring of Packet-In messages, and does not require any

validatjon, authentjcatjon, or authorizatjon to identjfy the host

• An atuacker can impersonate a host and make the SDN controller believe it has migrated to

a physical network locatjon controlled by the atuacker

• Data plane access is suffjcient for exploitatjon, so long as the atuacker knows the MAC

address of the target host

• Not patched in ODL l2switch
• Paper: htup://www.internetsociety.org/sites/default/fjles/10_4_2.pdf

#ODSummit

DoS in ONOS packet deserializer (CVE-2015-1166)

• When an OpenFlow switch encounters a packet that does not match any forwarding rules,

it passes this packet to the controller for advice

• It was found that the packet deserializers in ONOS would throw exceptjons when handling

malformed, truncated, or maliciously-crafued packets

• The exceptjons were not caught and handled properly
• The top-level I/O thread exceptjon handler would then disconnect the relevant switch
• Proves that atuacks from the data plane are possible!

#ODSummit

Defensive T echnologies

#ODSummit

Topoguard

• The same research team that reported the topology spoofjng fmaw developed topoguard

to mitjgate it

• Doesn't add authn/authz, but instead verifjes the conditjons of host migratjons
• A legitjmate host migratjon would involve a Port Down signal before the host migratjon
• fjnishes. The host would also be unreachable at its old physical network locatjon afuer the

migratjon is complete.

• Currently tjghtly coupled to the Floodlight controller

#ODSummit

Security-mode ONOS

• A new feature in the ONOS Cardinal release
• Efgectjvely a mandatory access control (MAC) implementatjon for ONOS applicatjons
• Applicatjons can be constrained by a policy dictatjng which actjons they are permitued to

perform

• A vulnerability in an ONOS applicatjon could not be exploited to perform actjons that are

not permitued by security-mode ONOS. This is similar to the protectjon SELinux provides for applicatjons running on Linux systems.

• Could this approach be a good model for OpenDaylight?

#ODSummit

Proposed Controller Shield Project

#ODSummit

Security Response Best Practices

#ODSummit

Open Source Security Response

• All informatjon public
• Not just source code: bug trackers, mailing lists, etc.
• Security requires the opposite approach – informatjon must be kept private untjl patches

are available

• How do you handle this in the context of an open source project?
• Good models: ASF, major OSS vendors like Red Hat and SuSE

#ODSummit

Open Source Security Response

• Dedicated mechanism for reportjng security issues, separate to normal bugs
• Dedicated team with a documented process for responding to these reports
• Ability to quick build a patch asynchronous to normal release schedules
• Clear documentatjon of the issue in an advisory, including references to patch commits

(advantage of open source)

#ODSummit

Open Source Security Response

#ODSummit

Proprietary Security Response

#ODSummit

Secure Engineering Best Practices

#ODSummit

Open Source Secure Engineering

• No well established best practjces
• Few good examples in the open source world. Proprietary sofuware currently does a much

betuer job, for example Microsofu's SDLC.

• OpenStack is one good example
• Separate VMT and OSSG organizatjons

#ODSummit

Open Source Secure Engineering

#ODSummit

Open Source Secure Engineering

• Secure development guidelines (relies on developers to implement)
• Developer training (expensive and diffjcult to roll out in a virtual environment with many

contributors)

• Automated QE/CI jobs to catch known-vulnerable dependencies
• Automated QE/Ci jobs to catch security issues and enforce standards, e.g. via statjc

analysis

#ODSummit

OpenDaylight security: current status

#ODSummit

OpenDaylight Security Response

• Security reportjng mechanism
• Dedicated team with a private mailing list and documented process for handling issues
• Security advisories page: htups://wiki.opendaylight.org/view/Security_Advisories
• Advisories sent to mailing lists

#ODSummit

OpenDaylight Security Response

#ODSummit

OpenDaylight Security Response

• Scope currently limited to OpenDaylight code, not dependencies
• Handling dependencies would involve capturing a manifest, and tracking all relevant

upstreams

• Based on my experience, this would require one full tjme resource to be feasible
• Vulnerabilitjes in dependencies are sometjmes handled when they are reported to the

security response team

#ODSummit

OpenDaylight Secure Engineering

• Great analysis performed in May 2014:

htups://wiki.opendaylight.org/view/CrossProject:OpenDaylight_Security_Analysis

• Unfortunately quite dated now, and not much progress has been made implementjng the

recommendatjons

• It's a lot of work to implement things, and who has tjme?
• Enter the OpenDaylight summer internship program!

#ODSummit

OpenDaylight Secure Engineering – Intern Project

#ODSummit

OpenDaylight Secure Engineering – Intern Project

Establish automated QE/CI jobs to catch security issues and regressions. This will involve integratjng the fjndsecbugs tool into Gerrit/Jenkins. Establish automated QE/CI jobs to catch known-vulnerable dependencies. This will involve integratjng tools such as dependency-check and victjms into Gerrit/Jenkins. Document a threat model for OpenDaylight Improve documentatjon to capture security best practjces at installatjon and confjguratjon tjme

#ODSummit

✔ ✔ ✔ ✔ ✔

OpenDaylight security: vision

#ODSummit

OpenDaylight Security Vision - Reactive

High performing security response team Equipped to handle vulnerabilitjes in dependencies Able to co-ordinate disclosure and patches for issues across the community development team and afgected vendors of OpenDaylight distributjons or products Geographically distributed and able to quickly respond in all tjmezones

#ODSummit

✔ X ✔ ✔

OpenDaylight Security Vision - Proactive

Documentatjon of best practjces, threat model, etc. Remove default credentjals Security hardening features applying a sandbox or MAC to the environment Automated checks for known-vulnerable dependencies Automated statjc analysis checks Security training for developers: considering donatjng javapentestjng.com course content to the community

#ODSummit

X ✔ X X ✔ ✔

Questions?

#ODSummit