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 X 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

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

Questions? #ODSummit