Building world-class security response and secure development processes

Transcription

1

2 Building world-class security response and secure development processes David Jorm, Senior Manager of Product Security, IIX

3 Outline Introduction SDN attack surface Recent OpenDaylight vulnerabilities Defensive technologies Security response best practices Secure engineering best practices OpenDaylight security: current status OpenDaylight security: vision

4 Introduction Software 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 (beautiful place, shame about the timezone)

5 SDN Attack Surface

6 SDN Attack Surface Traditional networks conflate the control and data planes on a physical device Software-defined 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 segregation of the control plane network from the production data plane network Security disadvantage: the SDN controller's ability to control an entire network makes it a very high value target

7 SDN Attack Surface

8 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 attacker 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 presentation

9 SDN Attack Surface

10 Recent OpenDaylight Vulnerabilities

11 Netconf XXE (CVE ) Netconf (and restconf) API processes user-supplied XML By default, Java XML parsers do not disable external entity processing This led to a textbook XXE vulnerability Example of vulnerable code, with the patch applied: controller/opendaylight/netconf/netconfutil/src/main/java/org/opendaylight/controller/netconf/util/xml/xmlutil.java

12 Netconf XXE (CVE )

13 Topology spoofing via host tracking (CVE ) Most SDN controllers include host tracking, allowing hosts to migrate between different physical locations in the network Host tracking is based on monitoring of Packet-In messages, and does not require any validation, authentication, or authorization to identify the host An attacker can impersonate a host and make the SDN controller believe it has migrated to a physical network location controlled by the attacker Data plane access is sufficient for exploitation, so long as the attacker knows the MAC address of the target host Not patched in ODL l2switch Paper:

14 DoS in ONOS packet deserializer (CVE ) 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 exceptions when handling malformed, truncated, or maliciously-crafted packets The exceptions were not caught and handled properly The top-level I/O thread exception handler would then disconnect the relevant switch Proves that attacks from the data plane are possible!

15 Defensive Technologies

16 Topoguard The same research team that reported the topology spoofing flaw developed topoguard to mitigate it Doesn't add authn/authz, but instead verifies the conditions of host migrations A legitimate host migration would involve a Port Down signal before the host migration finishes. The host would also be unreachable at its old physical network location after the migration is complete. Currently tightly coupled to the Floodlight controller

17 Security-mode ONOS A new feature in the ONOS Cardinal release Effectively a mandatory access control (MAC) implementation for ONOS applications Applications can be constrained by a policy dictating which actions they are permitted to perform A vulnerability in an ONOS application could not be exploited to perform actions that are not permitted by security-mode ONOS. This is similar to the protection SELinux provides for applications running on Linux systems. Could this approach be a good model for OpenDaylight?

18 Proposed Controller Shield Project

19 Security Response Best Practices

20 Open Source Security Response All information public Not just source code: bug trackers, mailing lists, etc. Security requires the opposite approach information must be kept private until 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

21 Open Source Security Response Dedicated mechanism for reporting 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 documentation of the issue in an advisory, including references to patch commits (advantage of open source)

22 Open Source Security Response

23 Proprietary Security Response

24 Secure Engineering Best Practices

25 Open Source Secure Engineering No well established best practices Few good examples in the open source world. Proprietary software currently does a much better job, for example Microsoft's SDLC. OpenStack is one good example Separate VMT and OSSG organizations

26 Open Source Secure Engineering

27 Open Source Secure Engineering Secure development guidelines (relies on developers to implement) Developer training (expensive and difficult 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 static analysis

28 OpenDaylight security: current status

29 OpenDaylight Security Response Security reporting mechanism Dedicated team with a private mailing list and documented process for handling issues Security advisories page: Advisories sent to mailing lists

30 OpenDaylight Security Response

31 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 time resource to be feasible Vulnerabilities in dependencies are sometimes handled when they are reported to the security response team

32 OpenDaylight Secure Engineering Great analysis performed in May 2014: Unfortunately quite dated now, and not much progress has been made implementing the recommendations It's a lot of work to implement things, and who has time? Enter the OpenDaylight summer internship program!

33 OpenDaylight Secure Engineering Intern Project

34 OpenDaylight Secure Engineering Intern Project Establish automated QE/CI jobs to catch security issues and regressions. This will involve integrating the findsecbugs tool into Gerrit/Jenkins. Establish automated QE/CI jobs to catch known-vulnerable dependencies. This will involve integrating tools such as dependency-check and victims into Gerrit/Jenkins. Document a threat model for OpenDaylight Improve documentation to capture security best practices at installation and configuration time

35 OpenDaylight security: vision

36 OpenDaylight Security Vision - Reactive High performing security response team X Equipped to handle vulnerabilities in dependencies Able to co-ordinate disclosure and patches for issues across the community development team and affected vendors of OpenDaylight distributions or products Geographically distributed and able to quickly respond in all timezones

37 OpenDaylight Security Vision - Proactive Documentation of best practices, threat model, etc. X Remove default credentials X Security hardening features applying a sandbox or MAC to the environment Automated checks for known-vulnerable dependencies Automated static analysis checks X Security training for developers: considering donating javapentesting.com course content to the community

38 Questions?