Wikis > Software-Defined Security Services

Notice: The views and opinions expressed here are collective derived from the members of this ONUG Working Group and are not the express opinion of any individual or companies. The white paper has gone through final edits; please do not make any changes.

SPRING 2018

ONUG Spring 2018–May 8 & 9 @ UCSF, San Francisco, hosted by Kaiser Permanente 

SDSS Working Group Chairs:

Scott Bradner, Independent
Fred Lima, eBay
Dilip Sundarraj, Juniper
(additional vendor Co-Chair(s) to be added after 1/25 voting)

Secretary:

 

Spring 2018 Meeting Schedule (via WebEx):

Every other Thursday @ 11:30 am ET starting January 25, 2018

Spring 2018 ONUG Workshops:

March 6 & 7, 2018, Sunnyvale, CA

September 2018, NYC (dates and location tbd)

Members (Sponsors to be added as they are confirmed):

Stephen Collins ACG Research
Tavarez Dudley Advocate Insiders
Alex Kurgan AFEX
Ben Mourad Allegis Group
Venkatarao Mokkapati American Express
Rashad Mahmood Khan APECON
Craig Martinson Australia & New Zealand Banking Group (ANZ)
John Mammen Bank of America
Ravi Malhotra BNY Mellon
Neal Secher State Street Bank
Terry McGibbon Barclays
Leo Pang Bloomberg
Pei Qi Bloomberg
Michael Lundberg Booz Allen Hamilton
Raj Mathialagan Booz Allen Hamilton
Jeffrey Schmitz CCP LLC
Dave Larkin Cigna
Andy Iaman Cigna
Matthew LaLumiere Cigna
Christopher Lockery Cigna
Chris Cheu Cigna
Xiaobo Long Citi
Perry Young Citi
Zoran Kostic Columbia University
Kunal Mahajan Columbia University
Vesko Pehlivanov Credit Suisse
Gary Ramah Disney
Josh Archambault DTCC
Jeff Kopko DTCC
Manoj Koshti Ellie Mae
Tony Chong ExxonMobil
Barry Poole FedEx
Corey Allert FedEx
Forrest Bennett FedEx
Grant Bennett Fidelity
Mark Kisner Fidelity
Michael Wynston First Data
James Noble Gaikai
Snehal Patel Gap
George Konapozhil GE
Lisa Huang GE
Thom Schoeffling General Dynamics IT
Hassan Ahmad Google
Ray Georges Early Warning Services
Ted Turner Intuit
Dan Shanahan Intuit
Gani Riasudeen JP Morgan Chase
Kosha Jobanputra KPMG
Pete Kwon Legacy Texas Bank
Pashanth Kumar LinkedIn
Arun T LinkedIn
Russ White LinkedIn
Bruno Dias MaplesFS
Michael Martin McKinsey & Company
Bob Natale MITRE
Rhett Dillingham Moor Insights & Strategy
Graeme Hay Morgan Stanley
Ashutosh Chandra Jha NASDAQ
Steve Lafrentz Principal Financial Group
Brian Peister Protiviti
Shradha Sharma PwC Advisory Services
Ali Sydney Raytheon BBN Technologies
Michael Clark Renaissance Tech Media
Harinder Singh Sainsburys
David Lucey SalesForce
John Hoffman Salesforce
Azharul Mannan Standard Chartered Bank
Phillip Thomaschima Target
Brian Anderson Tegna
Rodger Xu Teranet
Mahesh Desai Tesla Motors
Arpit Rana University @ Buffalo
Sean Wang University of British Columbia
Pai-Nui Chen University of Chinese Academy of Science
Mehrdad Moradi University of Michigan
Rahul Godha Godha University of Wisconsin-Madison
Kurt Wong Vantiv
Vijay Balasubramanian Viacom
Yinfeng Shi Viacom
Randhir Chawda Visa
ZakirHussain Mohideen Visa
Marcelo Silva Visa
Phil Hattwick Wellington Management
John Burns Wells Fargo
Kelley Mak Work-Bench
Zahid Kalwar XL Global Services

Abhinav Modi Avi
Christian Treutler Avi
Swapnil Raut Avi
Kerry Takenaka cPacket Networks
Michael Haugh Gluware
Hakim Abdelkader HPE
Amit Das HPE
Richard Shi Huawei
George Zhao Huawei
Yang Yang Huawei
Linda Dunbar Huawei
Wei Wei Huawei
Jim Guichard Huawei
Benny Huang Huawei
Leo Liu Huawei
Jeff Schmitz Illumio
Mukesh Gupta Illumio
Srinivas Nimmagadda Juniper
Christopher Messina Juniper
Anil Lohiya Juniper
Prakash Seshadri Juniper
Tarun Banka Juniper
Sumeet Singh Juniper
Aniket Daptari Juniper
Jeff Tantsura Nuage
Mostafa Mansour Nuage
Hari Krishnan Nuage
Simon Fiddian Nuage
Nabil Bitar Nuage
Darren Richards Nuage
Hussein Khazaal Nuage
Toshal Dudhwala Nuage
     
Monika Goldberg ShieldX
Manuel Nedbal ShieldX
Daniel Johnson Verizon
Apurva Mehta Versa
Anusha Vaidyanathan Versa
Mark Weiner Versa
Darrell Long Versa
Carlos Shiguedomi ZPE

FALL 2017

ONUG FALL 2017 October 17 & 18 in NYC

Software-Defined Security Services Working Group Meeting Schedule:

June 8 @ 11:30 am ET
June 22 @ 11:30 am ET
July 6 @ 11:30 am ET
July 20 @ 11:30 am ET
August 3 @ 11:30 am ET
August 17 @ 11:30 am ET
August 31 @ 11:30 am ET
September 14 @ 11:30 am ET
September 28 @ 11:30 am ET
October 12 @ 11:30 am ET

Working Group Chair:

Scott Bradner, Independent
Fred Lima, eBay
Vesko Pehlivanov, Credit Suisse

Secretary:

Members: 

Tavarez Dudley Advocate Insiders
Alex Kurgan AFEX
Ben Mourad Allegis Group
Venkatarao Mokkapati American Express
Rashad Mahmood Khan APECON
Craig Martinson Australia & New Zealand Banking Group (ANZ)
John Mammen Bank of America
Ravi Malhotra BNY Mellon
Neal Secher BNY Mellon
Terry McGibbon Barclays
Leo Pang Bloomberg
Pei Qi Bloomberg
Chris Christou Booz Allen Hamilton
Michael Lundberg Booz Allen Hamilton
Raj Mathialagan Booz Allen Hamilton
Jeffrey Schmitz CCP LLC
Dave Larkin Cigna
Andy Iaman Cigna
Matthew LaLumiere Cigna
Christopher Lockery Cigna
Xiaobo Long Citi
Perry Young Citi
Zoran Kostic Columbia University
Gary Ramah Disney
Josh Archambault DTCC
Michael Clark Eli Advisors
Manoj Koshti Ellie Mae
Tony Chong ExxonMobil
Bhavin Jayswal Facebook
Peter Kispert FedEx
Barry Poole FedEx
Corey Allert FedEx
Grant Bennett Fidelity
Michael Wynston First Data
James Noble Gaikai
Snehal Patel Gap
Lisa Huang GE
George Konapozhil GE
Lisa Huang GE
Thom Schoeffling General Dynamics IT
Hassan Ahmad Google
Solomon Tekle Intuit
Ted Turner Intuit
Gani Riasudeen JP Morgan Chase
Pete Kwon Legacy Texas Bank
Pashanth Kumar LinkedIn
Arun T LinkedIn
Michael Martin McKinsey & Company
Arup Chakravarty MetLife
Bob Natale MITRE
Hailu Meng Monsanto
Graeme Hay Morgan Stanley
Gideon Tam MSKCC (Memorial Sloan Kettering Cancer Center)
Ashutosh Chandra Jha NASDAQ
Ashok Patel Owens Corning
Shena Tharnish PNC
Steve Lafrentz Principal Financial Group
Brian Peister Protiviti
Shradha Sharma PwC Advisory Services
Ali Sydney Raytheon BBN Technologies
David Lucey SalesForce
Azharul Mannan Standard Chartered Bank
Brian Anderson Tegna
Mahesh Desai Tesla Motors
Pai-Nui Chen University of Chinese Academy of Science
Mehrdad Moradi University of Michigan
Rahul Godha Godha University of Wisconsin-Madison
Vijay Balasubramanian Viacom
Yinfeng Shi Viacom
Randhir Chawda Visa
ZakirHussain Mohideen Visa
Marcelo Silva Visa
Phil Hattwick Wellington Management
John Burns Wells Fargo
Kelley Mak Work-Bench
Zahid Kalwar XL Global Services
Phil Lynch Westpac

 

Amir Sharif Aporeto
Kerry Takenaka cPacket Networks
Todd Kelly Cradlepoint
Richard Shi Huawei
Ayush Sharma Huawei
George Zhao Huawei
Yang Yang Huawei
Linda Dunbar Huawei
Wei Wei Huawei
Jim Guichard Huawei
Benny Huang Huawei
Leo Liu Huawei
Moloy Chatterjee Juniper
Srinivas Nimmagadda Juniper
Christopher Messina Juniper
Anil Lohiya Juniper
Chinmay Bhawe Juniper
Prakash Seshadri Juniper
Dinesh Naganna Juniper
Tarun Banka Juniper
Sumeet Singh Juniper
Dilip Sundarraj Juniper
Hari Krishnan Nuage
Simon Fiddian Nuage
Nabil Bitar Nuage
Darren Richards Nuage
Hussein Khazaal Nuage
Toshal Dudhwala Nuage
Steven Shalita Pluribus
Marc Woolward vArmour
David Anderson vArmour
Apurva Mehta Versa
Anusha Vaidyanathan Versa
Mark Weiner Versa
Darrell Long Versa
David Klebanov Viptela

SPRING 2017

ONUG SPRING 2017 April 25 & 26 in San Francisco

Software-Defined Security Services Meeting Schedule 

 
Date Time    
 Thursday, January 12 11:00 am-12:00 pm ET Call – CLICK for Meeting Notes  
 Thursday, January 26 11:00 am-12:00 pm ET Call – CLICK for Meeting Notes  
 Thursday, February 9 11:00 am-12:00 pm ET Conference Call  
 Thursday, February 23 11:00 am-12:00 pm ET Conference Call  
 Thursday, March 16 11:00 am-12:00 pm ET Call – CLICK for Meeting Notes  
 Thursday, March 23  11:00 am-12:00 pm ET  Conference Call  
 Thursday, April 6  11:00 am-12:00 pm ET  Conference Call  
     

Working Group Chairs

Scott Bradner, Independent
Fred Lima, eBay
Vesko Pehlivanov, Credit Suisse

Working Group Members 

 

 

 

 

 

 

 

Tavarez Dudley Advocate Insiders
Alex Kurgan AFEX
Ben Mourad Allegis Group
Venkatarao Mokkapati American Express
Rashad Mahmood Khan APECON
Craig Martinson Australia & New Zealand Banking Group (ANZ)
John Mammen Bank of America
Ravi Malhotra BNY Mellon
Neal Secher BNY Mellon
Terry McGibbon Barclays
Leo Pang Bloomberg
Pei Qi Bloomberg
Chris Christou Booz Allen Hamilton
Michael Lundberg Booz Allen Hamilton
Raj Mathialagan Booz Allen Hamilton
Dave Larkin Cigna
Andy Iaman Cigna
Matthew LaLumiere Cigna
Christopher Lockery Cigna
Xiaobo Long Citi
Zoran Kostic Columbia University
Gary Ramah Disney
Josh Archambault DTCC
Michael Clark Eli Advisors
Manoj Koshti Ellie Mae
Tony Chong ExxonMobil
Peter Kispert FedEx
Barry Poole FedEx
Michael Wynston First Data
James Noble Gaikai
Snehal Patel Gap
Lisa Huang GE
George Konapozhil GE
Thom Schoeffling General Dynamics IT
Hassan Ahmad Google
Solomon Tekle Intuit
Ted Turner Intuit
Gani Riasudeen JP Morgan Chase
Pete Kwon Legacy Texas Bank
Pashanth Kumar LinkedIn
Arun T LinkedIn
Michael Martin McKinsey & Company
Arup Chakravarty MetLife
Bob Natale MITRE
Hailu Meng Monsanto
Graeme Hay Morgan Stanley
Gideon Tam MSKCC (Memorial Sloan Kettering Cancer Center)
Ashutosh Chandra Jha NASDAQ
Ashok Patel Owens Corning
Shena Tharnish PNC
Steve Lafrentz Principal Financial Group
Brian Peister Protiviti
Shradha Sharma PwC Advisory Services
Ali Sydney Raytheon BBN Technologies
David Lucey SalesForce
Azharul Mannan Standard Chartered Bank
Brian Anderson Tegna
Mahesh Desai Tesla Motors
Pai-Nui Chen University of Chinese Academy of Science
Mehrdad Moradi University of Michigan
Rahul Godha Godha University of Wisconsin-Madison
Vijay Balasubramanian Viacom
Yinfeng Shi Viacom
Randhir Chawda Visa
ZakirHussain Mohideen Visa
Marcelo Silva Visa
Phil Hattwick Wellington Management
John Burns Wells Fargo
Kelley Mak Work-Bench
Zahid Kalwar XL Global Services
Phil Lynch Westpac

 

Amir Sharif Aporeto
Manish Kumar Cisco
Manoj Kale Cisco
Aaron Linn Cisco
Tina Zhang Cisco
Nagendra Kumar Nainar Cisco
Stacy Brown Cisco
Todd Kelly Cradlepoint
Hakim Abdelkader HPE
Amit Das HPE
Richard Shi Huawei
Ayush Sharma Huawei
George Zhao Huawei
Yang Yang Huawei
Linda Dunbar Huawei
Wei Wei Huawei
Jim Guichard Huawei
Benny Huang Huawei
Mukesh Gupta Illumio
Moloy Chatterjee Juniper
Srinivas Nimmagadda Juniper
Christopher Messina Juniper
Anil Lohiya Juniper
Chinmay Bhawe Juniper
Prakash Seshadri Juniper
Dinesh Naganna Juniper
Tarun Banka Juniper
Sumeet Singh Juniper
Hari Krishnan Nuage
Simon Fiddian Nuage
Nabil Bitar Nuage
Darren Richards Nuage
Hussein Khazaal Nuage
Toshal Dudhwala Nuage
Steven Shalita Pluribus
Marc Woolward vArmour
David Anderson vArmour
Brighten Godfrey Veriflow
Apurva Mehta Versa
Anusha Vaidyanathan Versa
Mark Weiner Versa
Darrell Long Versa
David Klebanov Viptela


FALL 2016

 
       
Working Group Chairmen    
 Mike Elmore – Cigna    
 Adam Forch – FedEx    
     
       
Members      
 Alex Kurgan  AFEX    
 Rashad Mahmood Khan  APECON    
 Sanjai Narain  Applied Communication Sciences    
 Craig Martinson  Australia & New Zealand Banking Group (ANZ)    
 Takman Lau  AXA    
 John Mammen  Bank of America    
 Mengzhu Peng  Bank of America    
 Terry McGibbon  Barclays    
 Leo Pang  Bloomberg    
 Ravi Malhotra  BNY Mellon    
 Neal Secher  BNY Mellon    
Chris Christou  Booz Allen Hamilton    
 Michael Lundberg  Booz Allen Hamilton    
 Dave Larkin  Cigna    
 Andy Iaman  Cigna    
 Matthew LaLumiere  Cigna    
 Christopher Lockery  Cigna    
 Xiaobo Long  Citi    
 Zoran Kostic  Columbia University    
 Vesko Pehlivanov  Credit Suisse    
 Gary Ramah  Disney    
 Josh Archambault  DTCC    
 Michael Clark  Eli Advisors    
 Manoj Koshti  Ellie Mae    
 Peter Kispert  FedEx    
 James Noble  Gaikai    
 Snehal Patel  Gap    
 Thom Schoeffling  General Dynamics IT    
 Solomon Tekle  Intuit    
 Ted Turner  Intuit    
 Gani Riasudeen  JP Morgan Chase    
 Pete Kwon  Legacy Texas Bank    
 Pashanth Kumar  LinkedIn    
 Bob Natale  MITRE    
Hailu Meng  Monsanto    
 Graeme Hay  Morgan Stanley    
 Gideon Tam  MSKCC (Memorial Sloan Kettering Cancer Center)    
 Ashutosh Chandra Jha  NASDAQ    
 Ashok Patel  Owens Corning    
 Steve Lafrentz  Principal Financial Group    
 Shradha Sharma  PwC Advisory Services    
 Ali Sydney  Raytheon BBN Technologies    
 David Lucey  SalesForce    
 Azharul Mannan  Standard Chartered Bank    
 Mahesh Desai  Tesla Motors    
 Chris Parchinski  Unilever    
 Mehrdad Moradi  University of Michigan    
 Rahul Godha  University of Wisconsin-Madison    
 Randhir Chawda  Visa    
 ZakirHussain Mohideen  Visa    
 Fred Lima  Visa    
 Phil Hattwick  Wellington Management    
 John Burns  Wells Fargo    
 Phillip Lynch  Westpac    
 Zahid Kalwar  XL Global Services    
 Mark Vondemkamp  AppViewX    
 Murali Palanisamy  AppViewX    
 Nitish Krishna  AppViewX    
 Josh Saul  Apstra    
 Todd Kelly  Cradlepoint    
 Anita Pandey  Cybera    
 John Gray  HP    
 Je Chiu  HP    
 Nick Harders  HP    
 Hakim Abdelkader  HPE    
 Nabil Bitar  Nuage    
 Hari Krishnan  Nuage    
 Brighten Godfrey  Veriflow    
 Apurva Mehta  Versa    
 Anusha Vaidyanathan  Versa    
 Mark Weiner  Versa    
David Klebanov  Viptela    

Meeting Notes


SPRING 2016

 
       
Working Group Chairmen    
Christofer Hoff – Bank of America    
Mike Elmore – Cigna    
Adam Forch – FedEx    
       
Members      
Sanjai Narain Applied Communication Sciences    
Craig Martinson ANZ    
Vijay Balasubramanian Bank of America    
John Mammen Bank of America    
Mengzhu Peng Bank of America    
Terry McGibbon Barclays    
Ravi Malhotra BNY Mellon Author  
Neal Secher BNY Mellon    
Chris Christou Booz Allen Hamilton    
Michael Lundberg Booz Allen Hamilton    
Dave Larkin Cigna    
Andy Laman Cigna    
Matthew LaLumiere    
Xiaobo Long Citigroup    
Zoran Kostic Columbia University    
Josh Archambault DTCC    
Michael Clark ELI Advisors    
Peter Kispert FedEx    
James Noble Gaikai    
Snehal Patel Gap    
Thom Schoeffling General Dynamics IT    
Ted Turner Intuit    
Pete Kwon Legacy Texas Bank    
Bob Natale MITRE    
Hailu Meng Monsanto    
Graeme Hay Morgan Stanley    
Gideon Tam Memorial Sloan Kettering Cancer Center    
Ashutosh Chandra Jha NASDAQ    
Steve Lafrentz MITRE    
Shradha Sharma PwC Advisory Services    
David Lucey Salesforce    
Mahesh Desai Tesla Motors    
Brighten Godfrey University of Illinois at Urbana-Champaign    
Mehrdad Moradi University of Michigan    
Rahul Godha University of Wisconsin-Madison    
Fred Lima Visa    
Zakir Hussain Mohideen Visa    
Phil Hattwick Wellington Management    
John Burns Wells Fargo    
Nabil Bukhari Brocade    
Hadi Nahari Brocade    
Aziz Abdul Cisco    
Goran Saradzic Cisco    
Gopinath Durairaj Citrix    
Marco Murgia Citrix    
Anita Pandey Cybera    
Sam Mita NEC    
Nabil Bitar Nuage Networks    
Hari Krisnan Nuage Networks    
Colin Ross vArmour    
David Anderson vArmour    
Apurva Mehta Versa Networks    
Anusha Vaidyanathan Versa Networks    
Mark Weiner Versa Networks    

Meeting Notes

January 5, 2016

January 25, 2016

February 2, 2016


FALL 2015

 
       
Working Group Chairmen    
Nick Lippis    
Michael Clark – Exceptional Leaders Intl.    
       
Conference Bridge # ONUG Webex    
       
Members      
Bharat Parray Bank of America    
Vijay Balasubramanian Bank of America    
Mengzhu Peng Bank of America    
Ravi Malhotra BNY Mellon  Author  
Neal Secher BNY Mellon    
Zoran Kostic Columbia University    
Peter Kispert FedEx    
Adam Forch FedEx    
Thom Schoeffling General Dynamics IT    
David White Institute of Tech Tallaght Dublin    
Ted Turner Intuit    
Bob Natale MITRE    
Graeme Hay Morgan Stanley    
Gideon Tam Memorial Sloan Kettering Cancer Center    
Shradha Sharma PwC Advisory Services    
Brighten Godfrey University of Illinois at Urbana-Champaign    
Zakir Hussain Mohideen Visa    
Phil Hattwick Wellington Management    
John Burns Wells Fargo    
Siva Mandalam Appcito    
Ken Cheng Brocade    
Mohit Virendra Brocade    
Varma Bhupatiraju Brocade    
Goran Saradzic Cisco    
Marco Murgia Citrix    
Josh Saul Dispersive Group    
Nic Fragale Dispersive Group    
John Gray HP    
Je Chiu HP    
Nick Harders HP    
Michael Githens Ixia    
Pierre Lynch Ixia    
Spike Curtis Project Calico    
Colin Ross vArmour    

Meeting Recap: August 19, 2015

Main deliverable is to publish a White Paper to be presented at ONUG Fall 2015. The group will define the use case the way participants want to define it, document, publish, and present it at ONUG. The next step would look at top ten requirements – the entire audience at ONUG Fall will vote on highest priority requirements, which will be used for feature verification testing. The third stage works to define what the use case means in terms of interoperability, whether within an ecosystem or between companies. It will depend on particular standards that are important to the Working Group.

Discussion:

Pain points

Intrusion prevention/protection programs

Supply chain

Anonymity services

Logistics:

Designation of Michael Clark as co-chair with Nick Lippis

Ravi Malhotra appointed as Author

Meetings will take place every two weeks with email trails in between, at least until the White Paper draft is done.

 

Meeting Recap: September 2, 2015

Michael Clark chaired meeting on behalf of Nick Lippis

Opening Items:

  • Reviewed SD-Data Center Security Fabric Working Group’s Phase I objective, as noted above in August 19 meeting recap:
    • Main deliverable is to publish a White Paper to be presented at ONUG Fall 2015
    • Therein the group will define the top ten requirements for the Security Fabric, and define, document, publish, and present these at the Fall meeting this November
    • We leveraged the SD-WAN Working Group’s White Paper as an example of what is expected in the final document
  • We then reiterated the Phase II and III objectives:
    • The next step will involve reviewing these requirements, with the entire audience at ONUG Fall 2015 voting on the various requirements’ priorities, which will in turn be used for feature verification testing with Ixia
    • The third stage involves defining what the use cases mean in terms of interoperability, whether within an ecosystem or between companies. It will depend on particular standards that are defined as imperative by the Working Group
  • And noted that we’ve been asked to contribute to the ONUG blog that covers the progress being made by our Working Group by Sept 9 for publication beginning Sept 15 (see Action Items below)
  • We also confirmed Logistics as covered at the last meeting:
    • Ravi Malhotra will serve as “Author” and thus help ensure we keep discussion details, material compilation, and drafting/writing of the White Paper on track
    • Working Group meetings will continue to take place every two weeks with email trails in between, at least until the White Paper draft is done.
  • And we agreed that we would as a group actively contribute to and edit this Wiki as we proceeded toward the November presentation date

Discussion:

  • Framework for Sept 2 session offered:
    1. Need to develop a schedule for drafting, editing, publishing the white paper (determined we needed to answer some other questions regarding definition and scope before we put forward a production schedule)
    2. Scope of white paper: What exactly are we trying to address/redress within today’s (proprietary) enterprise WAN environments?
    3. Context: What are the current prevailing security architecture models in enterprises today?
    4. Requirements brainstorm: What tactical and strategic requirements need to be fulfilled in order to provide enterprises (and vendors) with the guidance required to assist in selection of SDN-Security Fabric Solutions?
    5. What are the implications of the above for service management tools and delivery processes
  • A very animated and high energy group discussion then followed, with the following emerging as highlights and focal points:
    • The question of definition: First need to agree on what exactly we *mean* by “Security Fabric” before we can articulate requirements for an SDN-SF
      • Conversation quickly turned to what the SF might include, from the “what” to the “how”
      • Decided we needed to back up, widen our lens, and first ask:
    • What actually are we trying to address with the SF? What are our current pain points? How do we articulate a problem statement for today? Doing so would potentially involve dealing with the following (in no particular order):
      • Firewall proliferation across enterprise DC’s
      • Constant threat innovation
      • Rapidly expanding business requirements force greater agile capabilities – e.g. BYOD
      • Security mechanisms need to accommodate the new
      • Widespread perception that security serves as an obstacle to business evolution
      • Increasing availability requirements (from 4 9’s to 5 to…?)
      • Transition to Cloud/Hybrid architectures and ability to accommodate transitions involved
      • “Classic” security topology tends to be physically-oriented, but now needs to take a more holistic approach, embracing virtual components, software management – everything
      • Security “wants” to have enterprise visibility, for political, programatic, and financial reasons – “must be” a “first-class citizen”
      • Security management
      • The components of security policy need to reflect the standard triad of systemic security quality – “The Security Triad”: integrity, availability, confidentiality
      • What else?
    • Specific requirement suggestions emerging from this discussion will be contributed by working group members, for now, in the section so-labeled below (scroll down below “Action Items” section). We may decide to establish a separate “Requirements Draft” page as a “child” of this SDDC-SF “parent” page. In general, our overall Wiki structure for this Working Group needs to be mapped out.

Action Items:

  • Send out link to SD-WAN White Paper to the team
  • All members contribute to the ONUG blog that covers the progress being made by our Working Group by Sept 9 for publication beginning Sept 15
    • Guidance:
      • Describe the Working Group via a general overview
        • What is the topic?
        • What are the goals?
        • What happened that made this initiative important to you and prompted you to get involved?
        • What is the value to the user?
        • What output can we expect?
  • All members to contribute their specific requirements suggestions below
  • Need to determine optimal structure for the SDDC-SF Working Group’s Wiki

 

Requirements suggestions from Working Group members:

  1. Requirement suggestion #1
  2. Requirement suggestion #2
  3. Requirement suggestion #3
  4. And so on

Meeting Recap: September 16, 2015

Nick Lippis chaired the meeting

Nick’s 9/16 Pre-Meeting Guidance:

“From a scheduling point of view we need to have version 1 of the security white paper use case completed by Oct 21, so we will not have the time to get everything we want into the paper.  I suggest that we think in terms of versions, so this version for ONUG Fall will be a first cut at the use case with a list of topics to be developed over the winter for ONUG Spring.  We’ll also schedule a few meet ups for the group as well.  But lets focus this afternoon on a scope that we can be successful with that addresses low hanging fruit and we can kick the can down the road for the more detailed aspects of the use case.
 
If we are able to develop a framework with a set of requirements that we can build upon over time, then that would be well received by the ONUG community.  One goal I would like to suggest is this:  What if we put out a statement that says we need a security architecture that allows any workload to be put on the internet securely.  What would this look like?  Or a framework that addresses security concerns/issues of hybrid cloud workload.

Nick’s Opening Comments:

  • Security Group top of mind at ONUG Board level
    • Several things are paramount:
      • what is the new security model for enterprises?
      • realization that the firewall model is now a relic
      • a new model is needed that protects data and enables hybrid/public group
      • what would it take for us to have our servers in the public cloud?
      • so, can we define a framework that would enable this possibility?
      • if so, we’ve effectively defined SDDC-SF
      • also, “the culture of NO” embedded within enterprise security in the face of business enterprises that need to move products and services to market
      • as an industry, trying to move to a software model that provides greater agility, choice, and all good things
        and yet enormous inertia exists in the existing security/compliance/risk community
      • so provide a framework for getting started on the core question above

Group Discussion:

  • Thom – no such thing as “perfect security”
    • always a balancing act
    • default position of “no” is understood
    • requires education of the business
    • need to reach a consensus on what degree of risk is acceptable and so what level of security is needed
    • context is key – SEC regulations, PCI regulations, etc.
  • Neal
    • corporate security departments are handing out outmoded requirements – segmentation, ACL’s, firewalls, etc
    • as with the Network State Working Group, we need to understand what to do with network analytics
      • ie with information in hand – what to do with it in an Open context?
  • Colin – using things like NetFlow, how do you know you’re getting everything you need to make good decisions?
  • Neal – probably that is not for this Working Group to solve
    • rather, our charter – given a policy or piece of info that has been received – how does the framework we’re building allow us to take action
    • can’t solve everything
    • how to establish a DC security fabric?
  • Thom – reiterated that we’re supposed to be focused on the What rather than the How
  • Neal – agrees we’re not trying to devise a solution, but in figuring out what goes into What?
  • Thom – push the “how” to the vendors
    • certain fundamental things needed:
      • really good systems visibility
      • what methods and interfaces needed to acquire those data objects
  • Nick – one CISO example – security bus contains all security objects/events – then bus moves into a correlator/detection engine – which then feeds into an automated response engine – filtering and funneling events that need to be addressed manually by the team – with higher level security skill set focused on the latter
  • Neal – review network state information architecture framework/model – state/collection/correlation/analytics
    • perhaps WE build upon the framework that is already there which have security implications
    • pick up on those security use cases and use them as a foundation for our work?
  • Thom – the second of these is a prerequisite for the first
    • so, look at the data elements that are available and determine what they are telling us
    • ie try to wrap security pieces around this
  • Neal – reviewed the Network State Reference Model – covering performance, security, and topology analytics
    • so, we see that something is happening on some port
    • now, what do we want to do with it? – focus for this group possibly??
  • Thom – take Neal’s implied “how to deal with something” and use it as something that “informs the requirements”
    • ie by combining this set of metrics or data elements, we expect the vendor that this is how that telemetry can be used and what it produces
  • Nick – leverage the network state model – one big assumption is that that framework is in place – and then work out how we would work out requirements for achieving the desired state of security – also build upon the management common controls group’s work
  • Ted – anything we call out here will likely be relevant and related to the performance group’s work
  • Thom/Nick – use ONUG forum for inter-group communications
  • Neal – need to hammer out a detailed goal statement for this group in advance of next meeting

Concluding Remarks:

  • Nick – use forum for stating the most fundamental requirements – doesn’t have to be top 10
    • his vote is to start with hybrid cloud and DC workloads (for both virtual and physical environments, and migrations between the two) – within this context what are you trying to protect – and how do you measure that?
    • are we trying to protect the Security Triad – so, in order to protect confidentiality, we need THIS (encryption, methods and interfaces)
    • -and in order to handle availability, we need THIS – and so on…
    • but not nec handle each of the Triad elements separately but as being systemic and holistic
    • call this out in the beginning:
      • the Triad – becomes the new model of security
      • call it out as foundational
      • and then build a set of security requirements around those

As regards Working Group communications going forward:

  • Agreed that we will use email threads to facilitate ongoing team “conversations,” as the listserv has proved problematic

Thom’s email of 9/30, with a Set of Proposed Definitions and Requirements:

**Below are a dozen or so proposed core requirements for the WG to
discuss.  The definition of a “core requirement” is one that is
generally applicable across the larger problem space being considered. 
In this case, a technology supplier whose product satisfies such
requirements would have an offering with the attributes needed to
deliver secure services.  This initial list is not intended to be
exhaustive, but rather provide the starting point for a foundational set
upon which to extend and later build higher level requirements that
would inherit the security protections afforded by satisfying these needs. 

The assertion being made here is that products delivered to the
marketplace (and therefore, downstream to the ONUG community) cannot
address the security concerns of critical infrastructure and high impact
business environments unless these requirements are met (i.e., they are
considered foundational).  The purpose of starting this email thread is
to throw something on the table to discuss so we can debate this assertion.

————————————————————————
The needs articulated below incorporate the use of specific key words to
establish the force of the requirements as stated.  The key words
“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD
NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in RFC 2119.
[https://www.rfc-editor.org/rfc/rfc2119.txt]

Thomas Proposed Term Definitions

The following definitions are provided to establish baseline meaning and
context for important terms used within individual requirement statements:

*The term “object” shall be defined as an abstract representation of
a tangible or intangible thing — a system, system element,
system-of-systems, data or other resource — having a defined
interaction or access relationship with a subject.

*The term “subject” shall be defined as an abstract representation of
an actor — a human, machine, or other entity operating with intent
— having a defined interaction or access relationship with an object.

* The term “security” or “secure” shall be defined as maintaining the
systemic properties of /confidentiality/, /integrity/, and
/availability/ for an object or object resource within a stated
operational context and access policy.

*The term “network enabled object” shall be defined as a physical or
virtual object having presence on a network within an administrative
domain and under governance of an administrative policy and actions
(e.g., switch, router, sensor, server, appliance, device).

*The term “data element” shall be defined as a named identifier with
associated value and datatype (e.g., integer, float, string, data
structure).

*The term “control function” shall be defined as any method
authorized to invoke an action that alters the operational state of
an object on behalf of an authenticated subject.

Thom’s Proposed Core Requirements:

The definition of core requirements are intended to be generally
applicable to individual products offered by technology suppliers to the
ONUG community, regardless of the product’s role on a network.

1. A network enabled object shall provide for a logically isolated
(from other object functions), out-of-band network interface;
purpose-built to facilitate the secure monitoring and administration
of the object throughout each stage of its lifecycle (i.e.,
deployment, operation, maintenance, retirement).

2. A network enabled object shall provide secure methods and interfaces
for implementing mandatory access controls to facilitate
policy-based subject access to the object and its resources.

3. A network enabled object shall be capable of exposing the full set
of available operational state reporting and administrative control
function elements using a secure method and interface to an
authorized subject.

4. A network enabled object shall limit exposure of elements pertaining
to its operational state and administrative control functions to
only those elements granted to a subject based on the subject’s
authorization profile and use context (e.g., a polymorphic interface
rendering a view/projection of available state and control resources).

5. A network enabled object shall provide secure methods and interfaces
for interrogating (querying) the object’s state by facilitating the
retrieval of a specified set operational data elements on behalf of
an authorized subject.

6. A network enabled object shall provide secure methods and interfaces
for establishing clipping levels, or thresholds, on operational data
elements and defining notification and/or action events to be sent
to cooperating entities (subjects or other objects) when the
object’s operational state results in a transition across a
specified level.  Such notifications and/or action events shall
result in output of one or more log entries to one or more specified
logging destinations, and include as meta-data/header information in
each message:

* a precision timestamp derived from a time source with known
accuracy, reliability and integrity, having resolution of not
less than 1ms and in a format consistent with Internet date/time
formats described by RFC 3339 and ISO 8601;

*a unique (deterministically resolvable) name or identifier of
the source object issuing the log entry (e.g., system, device,
process);

* an event priority level indicating the importance of the event
to the administrative domain’s operational context and policy;

* a human readable event description issued using the preferred
language of the administrative domain;

*an object-specific payload and format containing encoded data
elements/information relevant to the event.  The payload may be
null;

* a message authentication code (MAC) and associated trust chain
attesting to the integrity of the message payload and its
meta-data/header information.

7. A network enabled object shall validate inputs for each mutable
administrative control data element modified by an authorized
subject and enforce input values and ranges based on the access
policy governing the subject.

8. A network enabled object shall provide secure methods and interfaces
to facilitate in-band confidentiality of data in transit (encryption
on the wire/over the air) as the default operational mode.

9. A network enabled object shall provide secure methods and interfaces
to facilitate in-band confidentiality of data at rest (encrypted in
storage) as the default operational mode.

10. A network enabled object shall be capable of secure, unattended
startup (boot) and shutdown without exposing confidential data or
administrative credentials/keys over insecure channels or protocols.

11. A network enabled object shall provide secure programmatic methods
and interfaces to facilitate object monitoring and administrative
control by authorized, cooperating objects.  Programmatic interfaces
should include language bindings for current (2015) versions of:
ANSI C/C++, Java, Ruby, Perl, Python, PHP, and W3C compliant HTML5
with requisite extensions and/or supporting mark up languages.

12. A network enabled object should incorporate quantum-resistant
protocols (e.g., lattice-based cryptography) to mitigate long-term
risks associated with deferred cryptanalysis of intercepted data,
facilitated through emerging quantum technologies (i.e., intercept
now, decrypt later).

Colin’s 10/2 Response – restating his earlier suggestions:

A Software Defined Data Center Security Fabric:
  1. Must be simple to manage and automate.
    • Policy should be able to be implemented via GUI, CLI or API – there should be no restrictions in the capability of policy definition through the API (required to participate in orchestrated SDDC)
  2. Must scale on-demand
    • Policy engine can be integrated with inventory systems to dynamically respond to application scaling operations
  3. Auto-Scaling due to addition of new host assets
    • Must be able to be granular – “per device” or zero trust policy.
  4. We must assume that there is no perimeter security.
  5. Must not care where devices are located
    • Private Cloud, Public Cloud, VMWare, KVM etc…
    • Locality must not matter. Devices should be able to appear/move at will – policy/state etc must follow.
  6. Must to be independant of the whole environment.
    • This includes independance from the physical and/or network architecture/fabric, the workloads that are being protected, the hypervisor type etc.
  7. Must have policies with functional equivalence to NGFW:
    • Fully stateful and application aware analysis of network connections should be supported across the security fabric.
  8. Must provide logging of network communications:
    • Logging of allowed and denied flows
  9. Must provide the ability to identify potentially threat-related communications within the logged communications
    • This could be inherent within the system, or passing information onto other systems to provide
  10. Must provide the capability to immediately implement mitigating controls to prevent attacks (example – critical unpatched vulnerabilities within DC)
  11. Ability to apply higher priority policies (quarantine? NAC?)
  12. Must allow for dpi matching
    • Execute policy at L7 with full statefulness.

Meeting Recap: October 5, 2015

Nick Lippis and Mike Clark co-chaired the meeting

Notes:

  • Nick: Focus our requirements on the data center
  • Thom’s “core” requirements are meant to be foundational
  • In effect, they are prerequisites for Colin’s requirement proposals
  • Colin’s requirements essentially as: what are we asking the fabric to do?
  • Nick: Remember that we need these req’s to be sanctioned by IT/end-user community
  • Standing in for Colin, Marc (also from vArmour) took us through Colin’s list, which is noted above but repeated here for easy reference. Also integrated into the list below in BOLD are the comments from our conversation.
  • A Software Defined Data Center Security Fabric:
    1. Must be simple to manage and automate.
      • Policy should be able to be implemented via GUI, CLI or API – there should be no restrictions in the capability of policy definition through the API (required to participate in orchestrated SDDC)
      • What does simple mean?
      • Need to move beyond the subjective
      • Ensure things are testable and measurable – i.e. Indicate how something can be tested
      • Nick: must have open API into popular orchestrations – this makes it more descriptive – not simple
      • Thom: name the APIs and what orchestration system
      • Nick: and/or make it Open
      • Thom: leverage an RFC if one exists
      • Marc: perhaps RFC won’t do the trick because it’s the lowest common denominator; focus on Open
    2. Must scale on-demand
      • Policy engine can be integrated with inventory systems to dynamically respond to application scaling operations
      • indicate examples of inventory or orchestration systems that we would test against – docker, vcenter, Eucalyptus (AWS), open stack
    3. Auto-Scaling due to addition of new host assets
      • Must be able to be granular – “per device” or zero trust policy.
      • New/next device joining the network (eg servers) must be secure by definition; policies for virt and physical endpoints can be defined
    4. We must assume that there is no perimeter security.
      • Nick: Yes! don’t rely on perimeter security alone – fine for north/south, but what about east/west
      • John: cannot assume perimeter security is there – cannot assume defense in depth exists
      • This is not about replacing existing security – but about adding an east/west layer
    5. Must not care where devices are located
      • Private Cloud, Public Cloud, VMWare, KVM etc…
      • Locality must not matter. Devices should be able to appear/move at will – policy/state etc must follow.
      • Addresses private and public cloud – but changing wording so that we know what, say, a public clouds provider policy is – location independent is fine – but need to know where things are located – and what their policies are – ideally would like workloads to be place able anywhere but need to keep Thom’s caveats in mind – must be able to host in public or private  
    6. Must to be independant of the whole environment.
      • This includes independance from the physical and/or network architecture/fabric, the workloads that are being protected, the hypervisor type etc.
      • How closely are security controls coupled to infrastructure – cannot be specific vendor-dependent
      • How would you provide security controls to a range of devices without being hypervisor dependent?
      • That suggests we need to constrain solutions to open – yes? – or, better: we’d need to enumerate scenarios for brownfield “plug-ins” and call out those that can’t be covered
    7. Must have policies with functional equivalence to NGFW:
      • Fully stateful and application aware analysis of network connections should be supported across the security fabric.
      • Again, need to define what exactly we mean by “Next Generation Firewall”
      • And what exactly that gets us
    8. Must provide logging of network communications:
      • Logging of allowed and denied flows
      • Group agrees
    9. Must provide the ability to identify potentially threat-related communications within the logged communications
      • This could be inherent within the system, or passing information onto other systems to provide
      • Need to be able to discern anomalistic behavior – engine for this? – be more specific
    10. Must provide the capability to immediately implement mitigating controls to prevent attacks (example – critical unpatched vulnerabilities within DC)
      • Not addressed at Oct 5 mtg
    11. Ability to apply higher priority policies (quarantine? NAC?)
      • Not addressed at Oct 5 mtg
    12. Must allow for dpi matching
      • Execute policy at L7 with full statefulness.
      • Not addressed at Oct 5 mtg

Adam agreed to begin the formal requirements document authoring process

Next meeting: October 14

Requirements paper due: October 21

_____

Updates from October 14, 2015 SF Working Group Meeting

SDN Datacenter Security Fabric Requirements Documents

DRAFT-IN-PROGRESS

The SDN DC-Security Fabric…

 

  1. 1. Must provide open management and automation interfaces. Policies should be able to be implemented via API, CLI, or GUI interfaces. API interfaces should be functionally complete and not have any restrictions in the capability of policy definition.

 

  1. 2. Must be able to scale on-demand. [Scaling] Policy engines should integrate with data stores [formerly: inventory systems] (eg Docker, vCenter, Eucalyptus (AWS), Open Stack, Mesosphere) to respond dynamically to application scaling operations.
    1. Policy identifies what data belongs in which “bucket”
      1. The above needs clarification
    2. How do we propose using Identity-based information in the security fabric?
    3. How should authorization be allowed for scaling to occur?

 

  1. 3. Should auto-scale with the addition of additional hosts. Fabrics should scale as additional hosts are instantiated, assigning zero-trust policies by default as new hosts join the fabric.
    1. What exactly do we mean by “hosts”? In our 10/14 meeting we indicated that this meant hypervisors – should “hosts” be limited to hypervisors alone?

 

  1. 4. Must not rely on classic perimeter firewall architectures. Policy enforcement should be applied regardless of whether traffic is North/South or East/West in nature. [Now includes the former Requirement #7:] Must have policies with functional equivalence to Next Generation Firewalls. Fabrics must implement policies that are fully-stateful and Layer 7 (Application) aware.
    1. Is “classic” the best word in sentence 1 of #4? Alternatives: “traditional,” “legacy,” others?
    2. Do we need to delineate what we mean by north/south vs. east/west or should that simply be understood given the audience?
    3. Need to be explicit about what we mean by “Next Generation Firewalls” so that there’s no misunderstanding on this

 

  1. 5. Must be independent of host location (private or public cloud) and platform (VMWare, KVM, etc). Hosts should be able to be instantiated or moved at any time and policies should be created or migrated with hosts automatically.
    1. Include “hybrid” along with private and public cloud?
    2. Reference additional platforms?
    3. Are we explicit enough overall with our intent here? Do we need to explain the “why” further?
    4. Do we need to explain what we mean by “automatically”?

 

  1. 6. Must exist independently of the overall data center environment. That is, the security fabric must exist independent of the network infrastructure, virtualization hosts, and workloads being protected.

 

  1. 7. Must provide logging of [presumably: “all”?] network communications. Fabrics must ensure that both accepted and denied flows are logged. [Now includes former Requirement #9:] Must provide the ability to identify potentially threat-related communications within the logged communications.
    1. And deliver via API’s as noted in #1 above to alerting engines?

 

  1. 8. Previously this was Requirement #10:”Must provide the capability to immediately implement mitigating controls to prevent attacks (example – critical unpatched vulnerabilities within the data center)”An extended conversation took place regarding this item at our 10/14 meeting, with the following points being highlighted:
    1. Presumably, “immediately” means exactly that – but is this even attainable?
    2. The precise context in which an attack occurs (eg internal/external), will impact how the threat is mitigated – context is everything
      1. So, what classes of attacks are we addressing?
      2. Internal, for example: countless possibilities – again, need to be clear
      3. Also: are we clear on where the boundary of the security fabric is?
      4. For that matter, are we clear on what is in-scope/out-of-scope as regards the security fabric? Is it enough to say “anything that the SF touches”? Nick: uncomfortable because this is so open-ended – could turn into hundreds of req’s
      5. Colin: Req #10 meant to be a preventative measure…inside v. outside less of an issue – as boundary is at the asset itself – so: identify vulnerability, apply mitigating measures – really about defense-in-depth- zero trust
      6. Nick: once anomalistic behavior is id’d, signature broadly determined, SF has the ability to address
      7. Thom’s interp: suggests vulnerability scanner, interface to scanner, and the ability to respond to outputs
      8. Colin: not intended to “automatically” convert information into policy – most likely a manual step – once vulnerability ID’d, should be able to define a policy – rule – and respond accordingly
      9. Thom: need to describe this in a generic-enough way in order to be able to make this meaningful to vendors in general
      10. Colin: Former Req #’s 10 and 11 are intrinsically linked – and “vulnerability” is just an example
      11. Zakir: what we’re really talking about here appears to be a feedback mechanism – so quarantine is another example
      12. Former Req #11: Now subsumed within present Req #8: “Ability to apply higher priority policies (quarantine? NAC?)”
  1. Formerly Req #12:”Must allow for dpi matching – Execute policy at L7 with full statefulness”Discussion:
    1. Colin: Must allow for deep packet inspection matching – ie must contain application awareness policy capability – could be tied to #4 – but also not specifically tied to firewall
    2. Nick: create a DB of all apps that run through this fabric – then apply policies accordingly – calling out the need to id app’s via the SF
    3. Is this implementable? – how to define an app? – and how to accommodate so many?
    4. Do we leave this last point to the vendor to determine? or leave open? or get more specific?
    5. Understand that we are now at a particular level of maturity – current statement doesn’t need to be for all time, but would evolve over time
    6. Nick: capture and catalog all apps via DPI – via diff appliances

____________

November 2015 ONUG Presentation:

SDDC-SF_ONUG Fall 2015 _WorkingGroupUpdate_11042015

____________