Wikis > Software-Defined Security Services > January 25, 2016 – Meeting Notes

Opening discussion on Goals, Terminology, Definition

MichaelE (Co-Chair):

  • Goal is to continue developing use cases from last week
  • Suggested that “a network is a network” – ie the term doesn’t exclude any particular context (private, public, hybrid, on-premises, local, global)
  • Emphasized: we need to understand what problem(s) we’re trying to solve


  • Suggested we return to and review the original problem statement
  • Proposed: we make the use cases workload-specific
  • “Workload” definition: a workload is anything that carries information


  • Agrees with terminology just stated; emphasizes clear definitions
  • Proposes using the WG’s Wiki – clarify definitions and terminology there, making that the “book of record”

– ThomS – agrees

– JohnB – agrees as well, but cautions us to maintain relevance to our specific use cases – rather than try to shoot for global, all-encompassing definitions

Use Cases Discussion

Will presumably address such things as: virtual and physical entities and environments; control and data plane; policies; orchestration; enforcement

1) Jim Noble/Chris: Dynamically capture packets from ToR bare metal switches (vSwitches)

2) Michael Elmore: Networks are becoming app aware – at what point do they become data aware? Need to tag data (ADAPT?) [tags can be applied at any point in ILC] – avoid data aggregation/inference

3) Michael Elmore: Encryption – is good but blinds defenders [how to protect confidentiality?]

4) ThomS: How do we assess/measure the ability of elements (eg a workload – and services comprised of multiple workloads) on the network to protect the CIA (“The Security Triad” of confidentiality, integrity, and availability) of the services they are delivering

5) Name/title TBD: Automate security response [clearly needs further detail, definition]

6) Name/title TBD: Predictive [ditto!]

7) ThomS: Request is for a capability that provides a Common language to define declaratives and policy that can be consumed up and down the stack, physically and virtually (so, sub-objects inherit capabilities of object) [JimN: Tosca – should we leverage their “standard” in this regard – possibly? Needs further review and assessment]. [Nick: Remember Working Groups don’t need to (really shouldn’t) dictate the HOW but rather the WHAT, but that also isn’t meant to be unduly limiting].

8) John Burns: Would like to be able to instantiate an “Internet-facing workload” in a software-defined data center. Today, like many, he operates a physically separate area of the network – separate switches, dedicated top and bottom firewalls, separate racks, servers/ADCs, data telemetry systems, etc – for Internet-facing workloads. Much of that is driven by security concerns about accidentally bypassing controls if things are placed too close together, or if physical things are shared by logically separated environments. Would like the security fabric to deliver the comfort that a virtually isolated environment is just as secure as a physically isolated one. In his view, that means having the ability to validate that connectivity and “service chaining” is constructed as intended and has not been altered/bypassed, and the ability to attest to that fact in a manner that would satisfy regulators who are used to requesting physical isolation. [ThomS: Flesh this out further… Involves discussing risk further… In fact, there’s much here that could be blown out further – and several uses cases could likely come out of this (JNoble agrees) – eg service chaining alone – JBurns: needs to have someone/one’s take on the job of expanding this] (inherited trust)

9) ThomS: Should also specify what needs to be “characteristic of a use case” ie What needs to be baked into each use case? Look at it from perspective of a regulator/auditor (for those working in regulatory industries) – ie develop a set of “use case standards” that include this sort of thing – perhaps along with Definitions, Terminology at the “top” of our document – Nick: Be careful of limiting the scope of the use cases by taking this approach too far… or of allowing scope creep

10) Name TBD: Messaging bus implementation [meaning?]

11)) JimN: NOT A USE CASE, BUT RATHER A COMMENTARY: (ThomS: Looking at the workload will cover this concern/item) Don’t look at SD”N”, but rather at SD”X” — everything should be software defined – ThomS: Remember that everything that touches the network is in scope

12) ThomS: A good summary of #8 and 11: Policy should be bound to the workload — VM, Container, App, Service, microservices

13) Noble/Elmore: {aspirational} Write security policy in one place [declarative language] and deploy everywhere [see #7] – So, write policy once, apply in multiple places – through the network – which would therefore have to be able to enforce that workload’s policy – JimN/MikeE will work to potentially blow this out into multiple use cases – JimN (eg) security policies should have automated timeout periods (rather than last forever as they often do)

14) {reasonable} Provide capabilities for #12 and apply not only on virtual (like Nuage) and do it to the physical network