Subject: Re: [saag] Informal Gathering to discuss NSaaS (a.k.a Bar BoF)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 21 Jul 2014 18:19:37 +0000

Thanks for the announcement, Linda. I encourage all interested SACM participants to attend. We shall also make some room on the second SACM session on Friday morning to discuss the outcome of the Bar BoF and relationship with SACM.

Regards,

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, July 21, 2014 7:34 PM
To: [email-masked]; [email-masked]
Cc: Zarny, Myo; [email-masked]'; 'Shaibal Chakrabarty'
Subject: [sacm] Informal Gathering to discuss NSaaS (a.k.a Bar BoF)

We will have an informal gathering (a.k.a. Bar BOF) at New Brunswick room Thurs at 8:30pm to discuss NSaaS.

The purpose of this meeting is to collect comments and requirements from service providers to see there is justification for a full BOF at IETF 91.
For this purpose I have invited Vodafone, DT, Cable Lab, Verizon, and Telefonica to attend this informal gathering.

Cheers,

Linda

From: Zarny, Myo [mailto:[email-masked]]
Sent: Sunday, July 20, 2014 7:11 PM
To: Linda Dunbar; 'David Harrington'
Cc: [email-masked]'; Andrew Malis; 'Romascanu, Dan (Dan)'; 'Kathleen Moriarty'; 'Shaibal Chakrabarty'; [email-masked]'
Subject: RE: Summerized differences between SACM and NSaaS

Hello all,

I can see why some could consider NSaaS as part of "security automation". After all, NSaaS seeks to define how endpoints can request *network* security services over standard protocols (or APIs), which will facilitate automation.

>From what I see, the current SACM charter seems mainly concerned with assessing endpoint posture, and how (by what protocols) requisite policies could be pushed down to the endpoints.

I see potential synergies but we'll need to iron out a few differences:

*         Scope:  Security vs. network security services

*         Goal:  Automating endpoint posture assessment vs. defining how network security services are requested

*         Security policy enforcement location:  Endpoint vs network (and endpoint-network security services could exist on the endpoint itself.)

I'd like to add that the need to standardize how services could be requested from the "cloud" goes beyond network security services. We've intentionally narrowed down the scope to network security in order not to chew too much at once. (Indeed, one could argue network security itself already is a broad field.) On the other hand, we don't want to be too narrow: each IETF WG solving essentially the same problem over and over in (slightly) different ways isn't most productive and will create market confusion. I hope we'll get the right balance here.

Regards,

From: Linda Dunbar [mailto:[email-masked]]
Sent: 18 July 2014 6:15 PM
To: David Harrington
Cc: [email-masked]<mailto:[email-masked]>; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo [Tech]; Shaibal Chakrabarty
Subject: Summerized differences between SACM and NSaaS

Thanks to David H explanation and especially many thanks to Gunnar Engelbach's extended examples for SACM, I summarized the major differences between SACM and NSaaS:

SACM: Security Assessment of End Points:
*       End points can be routers, switches, clustered DB, installed piece of software
*       SACM is about "How to encode that policy in a manner where assessment can be automated"
*       Examples:
-      a Solaris 10 SPARC or Window 7 system used in a environment that requires adherence to a policy of Mission Critical Classified.
-      rules like "The maximum password age must be 30 days" and "The minimum password age must be 1 day"

NSaaS: Network Security as a Function:
*       Protocols for edge devices (e.g. vCPE) or clients to request/query/verify Security related functions from Network Providers
*       Firewall
*       DDOS/Anti-DOS
*       Access control/Authorization/Authentication
*       Remote identity management
*       Secure Key management
*       Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
*       Threat detection: Eavesdropping, Trojans, viruses and worms, Malware, etc.
*       Examples:
vCPE needs vFW that are hosted in the network.
vCPE provides the "Group Policies" for the vFW, like A can talk to B & C, but B can't talk to C.

Please let me know if you have comments/suggestions.

Thank you,

Linda  Dunbar

From: Linda Dunbar
Sent: Wednesday, July 16, 2014 4:48 PM
To: 'David Harrington'
Cc: [email-masked]<mailto:[email-masked]>; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty
Subject: RE: [sacm] Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers?

David,

Thank you very much for the reply.

What NSaaS intends to do is more along the line of BGP: distribute and negotiate relevant policies to security functions, and receives supported policies for verification and coordination.

So it is quite different from the Data Modeling language, like SNMP or Netconf.

We can discuss more at Toronto. SACM chairs have allocated a slot for us at Toronto meeting.

Linda

From: David Harrington [mailto:[email-masked]]
Sent: Wednesday, July 16, 2014 11:09 AM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>; Andrew Malis; Romascanu, Dan (Dan); Kathleen Moriarty; Zarny, Myo; Shaibal Chakrabarty
Subject: Re: [sacm] Any feedback on mechanisms of enabling enterprise (or applications) to request/verify virtual Security Function from network providers?

Hi Linda,

I quickly scanned your draft.
It appears to me, as a contributor, that your use cases seem to fit within the scope of SACM.
We are focused on endpoint assessment, but in your use cases, the endpoint happens to be a virtual endpoint in a virtual network, but an endpoint nonetheless.
And your use cases discuss assessing the configuration of security functionality on the virtual endpoint.

Your use cases raise some concerns that might be out of scope.
Inter-domain correlation would be part of the functionality of the NMS/SMS/security manager application that is gathering reports of assessments.
I think SACM is focused mainly on creating infrastructure for assessing individual endpoints, so those assessments can be used by applications.
The infrastructure for collecting data, storing data, and making the stored data accessible to applications would seem to be in scope.
What the application does with the data would seem to be out of scope.

Comparing this to an SNMP ecosystem, the IETF defines a data modeling language, data models, and a protocol for transporting the data. It assumes the data could be stored for later retrieval.
But what an application does with the collected/retrieved MIB data is not within the scope of the SNMP infrastructure.
If the application tries to correlate MIB data across multiple management domains, that is not part of the IETF scope.
As far as I can see, almost everything in your use cases fits within SACM.

David harrington
[email-masked]<mailto:[email-masked]>

On Jul 8, 2014, at 9:50 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

SACM participants:

We have a draft on problem and use cases of enabling  enterprise (or applications) to request/verify security functions hosted by network providers: http://tools.ietf.org/pdf/draft-dunbar-nsaas-problem-statement-00.pdf.

We didn't know which IETF area or WG are good fit for the proposed work.
Security Area Director Kathleen Moriaty suggests that the proposed work is somewhat related to SACM.
After reading through the SCAM charter, my initial feeling is that SCAM doesn't quite fit because SCAM is about  the language and data format for "endpoint posture assessment".  What we proposed is about the mechanism to enable Network Security as a Service (NSaaS). I can see the mechanisms provided by SCAM can be used for some attributes negotiation of NSaaS.
But I could be wrong.

We are seeking feedback from SACM group, in particular:
-          If what we propose fits with SACM?
-          Can the mechanism defined by SACM be used for NSaaS?
-          Any other thoughts?

if it turns out that it is in the SCAM group scope, it is great. If it doesn't, we will see what else can be done.

Linda Dunbar

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 21 Jul 2014 16:34:23 +0000

Cheers,

Linda

Hello all,

Regards,

Thank you,

Linda  Dunbar

From: Linda Dunbar

David,

Linda

Hi Linda,

David harrington

SACM participants:

Linda Dunbar