draft-ietf-i2nsf-client-facing-interface-req-01.txt   draft-ietf-i2nsf-client-facing-interface-req-02.txt 
I2NSF Working Group R. Kumar I2NSF Working Group R. Kumar
Internet-Draft A. Lohiya Internet-Draft A. Lohiya
Intended status: Informational Juniper Networks Intended status: Informational Juniper Networks
Expires: October 28, 2017 D. Qi Expires: January 4, 2018 D. Qi
Bloomberg Bloomberg
N. Bitar N. Bitar
S. Palislamovic S. Palislamovic
Nokia Nokia
L. Xia L. Xia
Huawei Huawei
April 26, 2017 July 3, 2017
Requirements for Client-Facing Interface to Security Controller Requirements for Client-Facing Interface to Security Controller
draft-ietf-i2nsf-client-facing-interface-req-01 draft-ietf-i2nsf-client-facing-interface-req-02
Abstract Abstract
This document captures requirements for Client-Facing interface to This document captures requirements for Client-Facing interface to
Security Controller. The interface is expressed using objects and the Security Controller as defined by [I-D.ietf-i2nsf-framework].
constructs understood by Security Admin as opposed to vendor or The interface is expressed using objects and constructs understood by
device specific expressions associated with individual product and Security Admin as opposed to vendor or device specific expressions
feature. This document identifies a broad set of requirements needed associated with individual product and feature. This document
to express security policies based on User-constructs which are well identifies a broad set of requirements needed to express Security
understood by User Community. This gives ability to decouple policy Policies based on User-constructs which are well understood by the
definition from policy enforcement on a specific element, be it a User Community. This gives ability to decouple policy definition
physical or virtual. from policy enforcement on a specific security functional element, be
it a physical or virtual.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . . 4 2. Conventions Used in this Document . . . . . . . . . . . . . . 4
3. Guiding principle for Client-Facing Interface defintion . . . 5 3. Guiding principle for Client-Facing Interface definition . . 5
3.1. User-construct based modeling . . . . . . . . . . . . . . 5 3.1. User-construct based modeling . . . . . . . . . . . . . . 5
3.2. Basic rules for Client-Facing Interface definition . . . 6 3.2. Basic rules for Client-Facing Interface definition . . . 6
3.3. Deployment Models for Implementing Security Policies . . 7 3.3. Deployment Models for Implementing Security Policies . . 7
4. Functional Requirements for the Client-Facing Interface . . . 10 4. Functional Requirements for the Client-Facing Interface . . . 10
4.1. Requirement for Multi-Tenancy in client interface . . . . 11 4.1. Requirement for Multi-Tenancy in Client-Facing interface 11
4.2. Requirement for Authentication and Authorization of 4.2. Requirement for Authentication and Authorization of
client interface . . . . . . . . . . . . . . . . . . . . 12 Client-Facing interface . . . . . . . . . . . . . . . . . 12
4.3. Requirement for Role-Based Access Control (RBAC) in 4.3. Requirement for Role-Based Access Control (RBAC) in
client interface . . . . . . . . . . . . . . . . . . . . 12 Client-Facing interface . . . . . . . . . . . . . . . . . 12
4.4. Requirement to protect client interface from attacks . . 12 4.4. Requirement to protect Client-Facing interface from
4.5. Requirement to protect client interface from attacks . . . . . . . . . . . . . . . . . . . . . . . . . 13
misconfiguration . . . . . . . . . . . . . . . . . . . . 12 4.5. Requirement to protect Client-Facing interface from
4.6. Requirement to manage policy lifecycle with diverse needs 13 misconfiguration . . . . . . . . . . . . . . . . . . . . 13
4.7. Requirement to define dynamic policy Endpoint group . . . 14 4.6. Requirement to manage policy lifecycle with rich set of
4.8. Requirement to express rich set of policy rules . . . . . 15 controls . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9. Requirement to express rich set of policy actions . . . . 16 4.7. Requirement to define dynamic Policy Endpoint Group . . . 14
4.10. Requirement to express policy in a generic model . . . . 18 4.8. Requirement to express rich set of Policy Rules . . . . . 16
4.11. Requirement to detect and correct policy conflicts . . . 18 4.9. Requirement to express rich set of Policy Actions . . . . 17
4.12. Requirement for backward compatibility . . . . . . . . . 18 4.10. Requirement for consistent policy enforcement . . . . . . 19
4.13. Requirement for Third-Party integration . . . . . . . . . 18 4.11. Requirement to detect and correct policy conflicts . . . 19
4.14. Requirement to collect telemetry data . . . . . . . . . . 19 4.12. Requirement for backward compatibility . . . . . . . . . 19
5. Operational Requirements for the Client-Facing Interface . . 19 4.13. Requirement for Third-Party integration . . . . . . . . . 20
5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 19 4.14. Requirement to collect telemetry data . . . . . . . . . . 20
5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 19 5. Operational Requirements for the Client-Facing Interface . . 20
5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 20 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 20
5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 20 5.2. API Extensibility . . . . . . . . . . . . . . . . . . . . 21
5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 21
5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 20 5.4. Notification and Monitoring . . . . . . . . . . . . . . . 21
5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Programming security policies in a network has been a fairly complex Programming security policies in a network has been a fairly complex
task that often requires very deep knowledge of vendor specific task that often requires deep knowledge of vendor specific devices
device and features. This has been the biggest challenge for both and features. This has been the biggest challenge for both Service
Service Provider and Enterprise, henceforth named as Security Admin Providers and Enterprises, henceforth named as Security Admins in
in this document. This challenge is further amplified due to network this document. This challenge is further amplified due to network
virtualization with security functions deployed in physical and virtualization with security functions deployed in physical and
virtual form factor, henceforth named as network security function virtual form factors, henceforth named as network security function
(NSF) in this document, from multiple vendors with proprietary (NSF) in this document, from multiple vendors with proprietary
interface. interfaces.
Even if a Security Admin deploys a single vendor solution with one or Even if Security Admin deploys a single vendor solution with one or
more security appliances across its entire network, it is still very more security appliances across its entire network, it is still very
difficult to manage security policies due to complexity of security difficult to manage Security Policies that requires mapping of
features, and mapping of business requirements to vendor specific business needs to complex security features with vendor specific
configuration. The Security Admin may use vendor provided management configurations. The Security Admin may use vendor provided
systems to provision and manage security policies. But, the single management systems to provision and manage Security Policies. But,
vendor approach is highly restrictive in today's network for the single vendor approach is highly restrictive in today's network
following reasons: for following reasons:
o An organization may not be able to rely on a single vendor because o An organization may not be able to rely on a single vendor because
the changing security requirements may not align with vendor's the changing security requirements may not align with vendor's
release cycle. release cycle.
o A large organization may have a presence across different sites o A large organization may have a presence across different sites
and regions; which means, it may not be possible to deploy same and regions; which means, it may not be possible to deploy same
solution from the same vendor because of regional regulatory and solution from the same vendor because of regional regulatory and
compliance policy. compliance policy.
o If and when an organization migrates from one vendor to another, o If and when an organization migrates from one vendor to another,
it is almost impossible to migrate security policies from one it is almost impossible to migrate Security Policies from one
vendor to another without complex and time consuming manual vendor to another without complex and time consuming manual
workflows. workflows.
o An organization may deploy multiple network security functions in o An organization may deploy multiple security functions in either
virtual and physical forms to attain the flexibility, elasticity, virtual or physical form to attain the flexibility, elasticity,
performance scale, and operational efficiency they require. performance scale and operational efficiency they require.
Practically, that often requires different sources (vendor, open Practically, that often requires different sources (vendor, open
source) to get the best of breed for any such security function. source) to get the best of breed for a given security function.
o An organization may choose all or part of their assets such as o An organization may choose all or part of their assets such as
routers, switches, firewalls, and overlay-networks as policy routers, switches, firewalls, and overlay-networks as policy
enforcement points for operational and cost efficiency. It would enforcement points for operational and cost efficiency. It would
be highly complex to manage policy enforcement with different tool be highly complex to manage policy enforcement with different tool
set for each type of device. set for each type of device.
In order to facilitate deployment of security policies across In order to facilitate deployment of Security Policies across
different vendor provided NSFs, the Interface to Network Security different vendor provided NSFs, the Interface to Network Security
Functions (I2NSF) working group in the IETF is defining a Client- Functions (I2NSF) working group in the IETF is defining a Client-
Facing interface to Security Controller [I-D. ietf-i2nsf-framework] Facing interface to Security Controller [I-D. ietf-i2nsf-framework]
[I-D. ietf-i2nsf-terminology]. Deployment facilitation should be [I-D. ietf-i2nsf-terminology]. Deployment facilitation should be
agnostic to the type of device, be it physical or virtual, or type of agnostic to the type of device, be it physical or virtual, or type of
enforcement point. Using these interfaces, it becomes possible to enforcement point. Using these interfaces, it becomes possible to
write different kinds of security management applications (e.g. GUI write different kinds of security management applications (e.g. GUI
portal, template engine, etc.) allowing Security Admin to express portal, template engine, etc.) allowing Security Admin to express
security policies in an abstract form with choice of wide variety of Security Policy in an abstract form with choice of wide variety of
NSF for policy enforcement. The implementation of security NSF as policy enforcement point. The implementation of security
management applications or controller is completely out of the scope management applications or controller is out of scope for I2NSF
of the I2NSF working group, which is only focused on interface working group.
definition.
This document captures the requirements for Client-Facing interface This document captures the requirements for Client-Facing interface
that can be easily used by Security Admin without a need for that can be easily used by Security Admin without a need for
expertise in vendor and device specific feature set. We refer to expertise in vendor and device specific feature set. We refer to
this as "User-construct" based interfaces. To further clarify, in this as "User-construct" based interfaces. To further clarify, in
the scope of this document, the "User-construct" here does not mean the scope of this document, the "User-construct" here does not mean
some free-from natural language input or an abstract intent such as some free-from natural language input or an abstract intent such as
"I want my traffic secure" or "I don't want DDoS attacks in my "I want my traffic secure" or "I don't want DDoS attacks in my
network"; rather the User-construct here means that policies are network"; rather the User-construct here means that Security Policies
described using expressions such as application names, application are described using expressions such as application names,
groups, device groups, user groups etc. with a vocabulary of verbs application groups, device groups, user groups etc. with a vocabulary
(e.g., drop, tap, throttle), prepositions, conjunctions, of verbs (e.g., drop, tap, throttle), prepositions, conjunctions,
conditionals, adjectives, and nouns instead of using standard conditionals, adjectives, and nouns instead of using standard
n-tuples from the packet header. n-tuples from the packet header.
2. Conventions Used in this Document 2. Conventions Used in this Document
BSS: Business Support System BSS: Business Support System
CLI: Command Line Interface CLI: Command Line Interface
CMDB: Configuration Management Database CMDB: Configuration Management Database
Controller: Used interchangeably with Security Controller or Controller: Used interchangeably with Security Controller or
management system throughout this document management system throughout this document
CRUD: Create, Retrieve, Update, Delete CRUD: Create, Retrieve, Update, Delete
FW: Firewall
FW: Firewall
GUI: Graphical User Interface GUI: Graphical User Interface
IDS: Intrusion Detection System IDS: Intrusion Detection System
IPS: Intrusion Protection System IPS: Intrusion Protection System
LDAP: Lightweight Directory Access Protocol LDAP: Lightweight Directory Access Protocol
NSF: Network Security Function, defined by NSF: Network Security Function, defined by
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
skipping to change at page 5, line 27 skipping to change at page 5, line 25
OSS: Operation Support System OSS: Operation Support System
RBAC: Role Based Access Control RBAC: Role Based Access Control
SIEM: Security Information and Event Management SIEM: Security Information and Event Management
URL: Universal Resource Locator URL: Universal Resource Locator
vNSF: Refers to NSF being instantiated on Virtual Machines vNSF: Refers to NSF being instantiated on Virtual Machines
3. Guiding principle for Client-Facing Interface defintion 3. Guiding principle for Client-Facing Interface definition
Client-Facing Interface must ensure that a Security Admin can deploy Client-Facing Interface must ensure that a Security Admin can deploy
any NSF from any vendor and should still be able to use the same a NSF from any vendor and should still be able to use the same
consistent interface. In essence, this interface must allow a consistent interface. In essence, this interface allows a Security
Security Admin to express security policies independent of how NSFs Admin to express a Security Policy enforced on the NSF to be
are implemented in their deployment. Henceforth, in this document, independent of vendor and its implementation. Henceforth, in this
we use "security policy management interface" interchangeably when we document, we use "security policy management interface"
refer to Client-Facing interface. interchangeably when we refer to Client-Facing interface.
3.1. User-construct based modeling 3.1. User-construct based modeling
Traditionally, security policies have been expressed using Traditionally, Security Policies have been expressed using vendor
proprietary interface. The interface is defined by a vendor based on proprietary interface. The interface is defined by a vendor based on
proprietary command line text or a GUI based system with proprietary command line text or a GUI based system with
implementation specific constructs such IP address, protocol and implementation specific constructs such IP address, protocol and
L4-L7 information. This requires Security Admin to translate their L4-L7 information. This requires Security Admin to translate their
business objectives into vendor provided constructs in order to business objectives into vendor provided constructs in order to
express a security policy. But, this alone is not sufficient to express a Security Policy. But, this alone is not sufficient to
render a policy in the network; the admin must also understand render a policy in the network; the admin must also understand
network and application design to locate a specific policy network and application design to locate a specific policy
enforcement point to make sure policy is effective. This may be enforcement point to make sure policy is effective. To further
highly manual task based on specific network design and may become complicate the matters, when changes happen in the network topology,
unmanageable in virtualized networks. the Security Policy may require modifications accordingly. This may
be a highly manual task based on network design and becomes
unmanageable in virtualized environment.
The User-construct based framework does not rely on lower level The User-construct based framework does not rely on lower level
semantics due to problem explained above, but rather uses higher semantics due to problem explained above, but rather uses higher
level constructs such as User-group, Application-group, Device-group, level constructs such as User-group, Application-group, Device-group,
Location-group, etcetera. A Security Admin would use these Location-group, etcetera. A Security Admin would use these
constructs to express a security policy instead of proprietary constructs to express a security policy instead of proprietary
implementation or feature specific constructs. The policy defined in implementation or feature specific constructs. The policy defined in
such a manner is referred to User-construct based policies in this such a manner is referred to User-construct based policies in this
draft. The idea is to enable Security Admin to use constructs they draft. The idea is to enable Security Admin to use constructs they
understand best in expressing security policies which simplify their understand best in expressing Security Policies which simplify their
tasks and help avoiding human errors in complex security tasks and help avoiding human errors in complex security
provisioning. provisioning.
3.2. Basic rules for Client-Facing Interface definition 3.2. Basic rules for Client-Facing Interface definition
The basic rules in defining the Client-Facing interfaces are as The basic rules in defining the Client-Facing interfaces are as
follows: follows:
o Not dependent on particular Network topology or the NSF location o Not dependent on a particular network topology or the NSF location
in the network in the network
o Not requiring deep knowledge of proprietary features and o Not forced to express Security Policy with proprietary vendor
capabilities supported in the deployed NSFsa€ specific interfaces for a given NSFa€
o Independent of NSF type that will implement the user security o Independent of NSF type that will implement a specific Security
policy be it a stateful firewall,IDP, IDS, Router, Switch Policy; e.g., the interface remains same no matter if a specific
Security Policy is enforced on a stateful firewall,IDP, IDS,
Router or a Switch
o Declarative/Descriptive model instead of Imperative/Prescriptive o Declarative/Descriptive model instead of Imperative/Prescriptive
model - What security policy need to be enforced (declarative) model - What security policy need to be expressed (declarative)
instead of how it is implemented (imperative) instead of how it is implemented (imperative)
o Not dependent on any specific vendor implementation or form-factor o Not dependent on vendor's' implementation or form-factor
(physical, virtual) of the NSF (physical, virtual) of the NSF
o Not dependent on how a NSF becomes operational - Network o Not dependent on how a NSF becomes operational - network
connectivity and other hosting requirements. connectivity and other hosting requirements.
o Not dependent on NSF control plane implementation (if there is o Not dependent on NSF control plane implementation (if there is
one) E.g., cluster of NSFs active as one unified service for scale one), e.g., cluster of NSFs active as one unified service for
and/ or resilience. scale and/ or resilience.
o Not depending on specific data plane implementation of NSF i.e. o Not depending on specific data plane implementation of NSF, e.g.
Encapsulation, Service function chains. encapsulation, service function chains.
Note that the rules stated above only apply to the Client-Facing Note that the rules stated above only apply to the Client-Facing
interface, which a user would use to express a high level policy. interface, which a Security Admin would use to express a high level
These rules do not apply to the lower layers e.g. Security policy. These rules do not apply to the lower layers, e.g., Security
Controller that convert higher level policies into lower level Controller that convert higher level policies into lower level
constructs. The lower layers may still need some intelligence such constructs. The lower layers may still need some intelligence such
as topology awareness, capability of the NSF and its functions, as topology awareness, capability of the NSF and its functions,
supported encapsulations etc. to convert and apply the policies supported encapsulations etc., to convert and apply the policies
accurately on the NSF. accurately on the NSF.
3.3. Deployment Models for Implementing Security Policies 3.3. Deployment Models for Implementing Security Policies
Traditionally, medium and large Enterprise deploy management systems Traditionally, medium and large Enterprises deploy vendor provided
to manage their statically defined security policies. This approach management systems to create Security Policies and any changes to
may not be suitable nor sufficient for modern automated and dynamic these Security Policies are made manually over time by Security
data centers that are largely virtualized and rely on various Admin. This approach may not be suitable and nor sufficient for
management systems and controllers to dynamically implement security modern highly automated data centers that are largely virtualized and
policies over any types of NSF. rely on various management systems and controllers to implement
dynamic Security Policies over large number of NSF in the network.
There are two different deployment models in which the Client-Facing There are two distinct deployment models for Security Controller.
interface referred to in this document could be implemented. These Although, these have no direct impact on the Client-Facing interface,
models have no direct impact on the Client-Facing interface, but but illustrate the overall Security Policy management framework in an
illustrate the overall security policy and management framework and organization and how the Client-Facing interface remain same which is
where various processing functions reside. These models are: the main objective of this document. These models are:
a. Policy management without an explicit management system for a. Policy management without an explicit management system for
control of NSFs. In this deployment, Security Controller acts as control of NSFs. In this deployment, Security Controller acts as
a NSF management system; it takes information passed over Client- a NSF management system; it takes information passed over Client-
Facing interface and translates into data on I2NSF NSF-facing Facing interface and translates into data on I2NSF NSF-facing
interface. The NSF-Facing interface is implemented by NSF interface. The NSF-Facing interface is implemented by NSF
vendors; this would usually be done by having an I2NSF agent vendors; this would usually be done by having an I2NSF agent
embedded in the NSF. This deployment model is shown in Figure 1. embedded in the NSF. This deployment model is shown in Figure 1.
RESTful API RESTful API
SUPA or I2NSF Policy Management SUPA or I2NSF Policy Management
^ ^
| |
Client-Facing Interface | Client-Facing Interface |
(Independent of individual | (Independent of individual |
NSFs, devices,and vendors)| NSFs, devices, and vendors) |
| |
------------------------------ ------------------------------
| | | |
| Security Controller | | Security Controller |
| | | |
------------------------------ ------------------------------
| ^ | ^
| I2NSF | | I2NSF |
NSF Interface | NSF-facing | NSF Interface | NSF-facing |
(Specific to NSFs) | Interface | (Specific to NSFs) | Interface |
skipping to change at page 9, line 13 skipping to change at page 9, line 13
management system that proxy I2NSF NSF-Facing interfaces as NSF management system that proxy I2NSF NSF-Facing interfaces as NSF
may not support NSF-Facing interface. This is a useful model to may not support NSF-Facing interface. This is a useful model to
support legacy NSF. This deployment model is shown in Figure 2. support legacy NSF. This deployment model is shown in Figure 2.
RESTful API RESTful API
SUPA or I2NSF Policy Management SUPA or I2NSF Policy Management
^ ^
| |
Client-facing Interface | Client-facing Interface |
(Independent of individual | (Independent of individual |
NSFs,devices,and vendors) | NSFs, devices, and vendors) |
| |
------------------------------ ------------------------------
| | | |
| Security Controller | | Security Controller |
| | | |
------------------------------ ------------------------------
| ^ | ^
| I2NSF | | I2NSF |
NSF Interface | NSF-facing | NSF Interface | NSF-facing |
(Specific to NSFs) | Interface | (Specific to NSFs) | Interface |
skipping to change at page 10, line 10 skipping to change at page 10, line 10
physical) | X | physical) | X |
| / \ | | / \ |
-------------/ \------------- -------------/ \-------------
| |---| | | |---| |
| NSF | | NSF | | NSF | | NSF |
| | | | | | | |
------------- ------------- ------------- -------------
Figure 2: Deployment with Management System or I2NSF Proxy Agent Figure 2: Deployment with Management System or I2NSF Proxy Agent
Although the deployment models discussed here don't necessarily As mentioned above, these models discussed here don't affect the
affect the definition of Client-Facing interface, they do give an definition of Client-Facing interface, they do give an overall
overall context for defining a security policy interface based on context for defining a Security Policy interface based on
abstraction. abstraction. This can help in implementing a Security Controller.
4. Functional Requirements for the Client-Facing Interface 4. Functional Requirements for the Client-Facing Interface
As stated in the guiding principle for defining the I2NSF Client- As stated in the guiding principle for defining the I2NSF Client-
Facing interface, the security policies and the Client-Facing Facing interface, the Security Policies and the Client-Facing
interface shall be defined from user's or client's perspective and interface shall be defined from Security Admin's perspective and
abstracted away from type of NSF, NSF specific implementation, abstracted away from type of NSF, NSF specific implementation,
controller implementation, network topology, controller NSF-Facing controller implementation, network topology, controller NSF-Facing
interface. Thus, the security policy definition shall be interface. Thus, the Security Policy definition shall be
declarative, expressed using User-construct, and driven by how declarative, expressed using User-construct, and driven by how
Security Admin view security policies from definition, communication Security Admin view Security Policies from their business needs and
and deployment perspective. objectives.
Security Controller's' implementation is outside the scope of this Security Controller's' implementation is outside the scope of this
document and the I2NSF working group. document and the I2NSF working group.
In order to express and build security policies, high level In order to express and build security policies, high level
requirement for Client-Facing interface is as follows: requirement for Client-Facing interface is as follows:
o Multi-Tenancy o Multi-Tenancy
o Authentication and Authorization o Authentication and Authorization
skipping to change at page 11, line 15 skipping to change at page 11, line 15
o Policy Conflict Resolution o Policy Conflict Resolution
o Backward Compatibility o Backward Compatibility
o Third-Party Integration o Third-Party Integration
o Telemetry Data o Telemetry Data
The above requirements are by no means a complete list and may not be The above requirements are by no means a complete list and may not be
sufficient for all use-cases and all Security Admins, but should be a sufficient or required for all use-cases, but should be a good
good starting point for a wide variety of use-cases in Service starting point for a wide variety of use-cases in Service Provider
Provider and Enterprise networks. and Enterprise networks.
4.1. Requirement for Multi-Tenancy in client interface A specific implementation may not support all these requirements but
in order to define a base set of requirements which would works for
most use-cases, this document will make an attempt to classify these
requirements in three categories:
A Security Admin may have internal tenants and might want a framework MUST: This means, the requirement must be supported by Client-Facing
wherein each tenant manages its own security policies with isolation interface.
from other tenants.
A Security Admin may be a cloud service provider with multi-tenant RECOMMENDED: This means, we recommend that Client-Facing interface
support this requirement since it might be applicable to large
number of use-cases but some vendor may choose to omit if their
focus is only certain market segments.
MAY: This means, the requirement is not mandatory for Client-Facing
interface but may be needed for specific use-cases.
4.1. Requirement for Multi-Tenancy in Client-Facing interface
An organization may have internal tenants and might want a framework
wherein each tenant manages its own Security Policies with isolation
from other tenants. This requirement may be applicable to Service
Providers and Large Enterprises so we classify this requirement in
RECOMMENDED category. If an implement does not support this
requirement, it must support a default implicit tenant created by
Security Controller that owns all the Security Policies.
A Security Admin may be a Cloud Service Provider with multi-tenant
deployment, where each tenant is a different customer. Each tenant deployment, where each tenant is a different customer. Each tenant
or customer must be allowed to manage its own security policies. or customer must be able to manage its own Security Policies without
affecting other tenants.
It should be noted that tenants may have their own tenants, so a It should be noted that tenants may have their own tenants, so a
recursive relation may exist. For instance, a tenant in a Cloud recursive relation may exist. For instance, a tenant in a Cloud
Service Provider may have multiple departments or organizations that Service Provider may have multiple departments or organizations that
need to manage their own security rules for compliance. need to manage their own security rules for compliance.
Some key concepts are listed below and used throughout the document The following objects are needed to fulfill this requirement:
hereafter:
Policy-Tenant: An entity that owns and manages the security policies Policy-Tenant: An entity that owns and manages Security Policies
applied on its resources. applied to its own asset and resources.
Policy-Administrator: A user authorized to manage the security Policy-Administrator: A user authorized to manage the security
policies for a Policy-Tenant. policies for a Policy-Tenant.
Policy-User: A user within a Policy-Tenant who is authorized to Policy-User: A user within a Policy-Tenant who is authorized to
access certain resources of that tenant according to the access certain resources of that tenant according to the
privileges assigned to it. privileges assigned to it.
4.2. Requirement for Authentication and Authorization of client 4.2. Requirement for Authentication and Authorization of Client-Facing
interface interface
Security Admin MUST authenticate to and be authorized by Security A Security Admin must be authenticated and authorized in order to
Controller before they are able to issue control commands and any manage Security Policies. We classify this requirement in MUST
policy data exchange commands. category since without proper authentication and authorization, the
security posture of entire organization can be easily compromised.
There must be methods defined for Policy-Administrator to be There must be methods defined for Policy-Administrator to be
authenticated and authorized to use Security Controller. There are authenticated and authorized to use Security Controller. There are
several authentication methods available such as OAuth, XAuth and several authentication methods available such as OAuth [RFC6749],
X.509 certificate based; the authentication may be mutual or single- XAuth and X.509 certificate based; the authentication may be mutual
sided based on business needs and outside the scope of I2NSF. In or single-sided based on business needs and outside the scope of
addition, there must be a method o authorize the Policy-Administrator I2NSF. In addition, there must be a method o authorize the Policy-
to perform certain action. It should be noted that, Policy- Administrator to perform certain action. It should be noted that,
Administrator authentication and authorization to perform actions Policy-Administrator authentication and authorization to perform
could be part of Security Controller or outside; this document does actions could be part of Security Controller or outside; this
not mandate any specific implementation but requires that such a document does not mandate any specific implementation but requires
scheme must be implemented. that such a scheme must be implemented.
4.3. Requirement for Role-Based Access Control (RBAC) in client 4.3. Requirement for Role-Based Access Control (RBAC) in Client-Facing
interface interface
Policy-Authorization-Role represents a role assigned to a Policy-User A tenant in organization may have multiple users with each user given
that determines whether a user has read-write access, read-only certain privileges. Some user such as "Admin" may have all the
access, or no access for certain resources. A User can be mapped to permission but other may have limited permissions. We classify this
a Policy-Authorization-Role using an internal or external identity requirement in RECOMMENDED category since it aligns with Multi-
provider or mapped statically. Tenancy requirement. If this requirement is not supported, a default
privilege must be assigned to all the users.
4.4. Requirement to protect client interface from attacks The following objects are needed to fulfill this requirement:
The interface must be protections from attacks, malicious or Policy-Authorization-Role: Defines the permissions assigned to a
otherwise, from clients or a client impersonator. Potential attacks user such as creating and managing policies on specified
could come from Botnets, hosts infected with virus or some resources. A user may not be allowed to change existing policies
unauthorized entity. It is recommended that Security Controller use but only view them.
a dedicated IP interface for Client-Facing communications and those
communications should be carried over an isolated out-of-band
network. In addition, it is recommended that traffic between clients
and Security controller be encrypted. Furthermore, some
straightforward traffic/session control mechanisms (i.e., Rate-limit,
ACL, White/Black list) can be employed on Security Controller to
defend against DDoS flooding attacks.
4.5. Requirement to protect client interface from misconfiguration 4.4. Requirement to protect Client-Facing interface from attacks
The interface must be protections against attacks from malicious
clients or a client impersonator. Potential attacks could come from
Botnets, hosts infected with virus or some unauthorized entities.
This requirement is highly RECOMMENDED since it may not be needed if
the entire framework is deployed in very controlled environment. But
if needed, we recommend that Security Controller uses a out-of-band
communication channel for Client-Facing interface. In addition,it is
also recommended that traffic Client-Facing interface communication
be encrypted; furthermore, some straightforward traffic/session
control mechanisms (i.e., Rate-limit, ACL, White/Black list) can be
employed on Security Controller to defend against DDoS flooding
attacks.
4.5. Requirement to protect Client-Facing interface from
misconfiguration
There must be protections from mis-configured clients. System and There must be protections from mis-configured clients. System and
policy validations should be implemented to detect this. Validation policy parameters validations should be implemented to detect this.
may be based on a set of default parameters or custom tuned Validation may be based on a set of default parameters or custom
thresholds such as the number of policy changes submitted, number of tuned thresholds such as the number of policy changes submitted,
objects requested in a given time interval, etc. number of objects requested in a given time interval, etc. We
consider this to be a MUST requirement but implementation aspects
would depend upon each individual API communication.
4.6. Requirement to manage policy lifecycle with diverse needs 4.6. Requirement to manage policy lifecycle with rich set of controls
In order to provide more sophisticated security framework, there In order to provide more sophisticated security framework, there
should be a mechanism so that a policy becomes dynamically active/ should be a mechanism so that a policy becomes dynamically active/
enforced or inactive based on Security Admin's manual intervention or enforced or inactive based on multiple different criteria such as
some external event. Security Admin's manual intervention or some external event. We
consider requirement listed here to be a MUST for wide variety of
use-cases.
One example of dynamic policy management is when Security Admin pre- One example of dynamic policy management is when Security Admin pre-
configures all the security policies, but the policies get activated configures all the security policies, but the policies get activated
or deactivated based on dynamic threats. Basically, a threat event or deactivated based on dynamic threat detection. Basically, a
may activate certain inactive policies, and once a new event threat event may activate certain inactive policies, and once a new
indicates that the threat has gone away, the policies become inactive event indicates that the threat has gone away, the policies become
again. inactive again.
There are following ways for dynamically activating policies: There are following ways for dynamically activating policies:
o The policy may be dynamically activated by Security Admin or o The policy may be activated by Security Admin manually using a
associated management entity client interface such as GUI or CLI.
o The policy may be dynamically activated by Security Controller upon o The policy may be dynamically activated by Security Controller upon
detecting an external event or an event from I2NSF monitoring detecting an external event or an event from I2NSF monitoring
interface interface
o The policy can be statically configured but activated or o The policy can be configured but gets activated or deactivated upon
deactivated upon policy attributes, such as timing calendar specified timing calendar with Security Policy definition.
Client-Facing interface should support the following policy Client-Facing interface should support the following policy
attributes for policy enforcement: attributes for policy enforcement:
Admin-Enforced: A policy, once configured, remains active/enforced Admin-Enforced: A policy, once configured, remains active/enforced
until removed by Security Admin. until removed by Security Admin.
Time-Enforced: A policy configuration specifies the time profile Time-Enforced: A policy configuration specifies the time profile
that determines when the policy is to be activated/enforced. that determines when the policy is to be activated/enforced.
Otherwise, it is de-activated. Otherwise, it is de-activated.
skipping to change at page 14, line 13 skipping to change at page 14, line 41
becomes inactive for certain time. becomes inactive for certain time.
A policy could be a composite policy, that is composed of many rules, A policy could be a composite policy, that is composed of many rules,
and subject to updates and modification. For the policy maintenance, and subject to updates and modification. For the policy maintenance,
enforcement, and audit-ability purposes, it becomes important to name enforcement, and audit-ability purposes, it becomes important to name
and version Security Policy. Thus, the policy definition SHALL and version Security Policy. Thus, the policy definition SHALL
support policy naming and versioning. In addition, the i2NSF Client- support policy naming and versioning. In addition, the i2NSF Client-
Facing interface SHALL support the activation, deactivation, Facing interface SHALL support the activation, deactivation,
programmability, and deletion of policies based on name and version. programmability, and deletion of policies based on name and version.
In addition, it should support reporting operational state of In addition, it should support reporting operational state of
policies by name and version. For instance, a client may probe policies by name and version. For instance, a Security Admin may
Security Controller whether a Security Policy is enforced for a probe Security Controller whether a Security Policy is enforced for a
tenant and/or a sub-tenant (organization) for audit-ability or tenant and/or a sub-tenant (organization) for audit-ability or
verification purposes. verification purposes.
4.7. Requirement to define dynamic policy Endpoint group 4.7. Requirement to define dynamic Policy Endpoint Group
When Security Admin configures a Security Policy, it may have When Security Admin configures a Security Policy, it may have
requirement to apply this policy to certain subsets of the network. requirement to apply this policy to certain subsets of the network.
The subsets may be identified based on criteria such as Users, The subsets may be identified based on criteria such as Users,
Devices, and Applications. We refer to such a subset of the network Devices, and Applications. We refer to such a subset of the network
as a "Policy Endpoint Group". as a "Policy Endpoint Group". This requirement is the fundamental
building block of Client-Facing interface; so making it a MUST
requirement. But object defined here may not support all use-cases
and may not be required by everyone so it is left up to vendor
whether all or partial set of these object is supported.
One of the biggest challenges for a Security Admin is how to make One of the biggest challenges for a Security Admin is how to make
sure that a Security Policy remain effective while constant changes sure that a Security Policy remain effective while constant changes
are happening to the "Policy Endpoint Group" for various reasons are happening to the "Policy Endpoint Group" for various reasons
(e.g., organizational, network and application changes). If a policy (e.g., organizational, network and application changes). If a policy
is created based on static information such as user names, is created based on static information such as user names,
application, or network subnets; then every time this static application, or network subnets; then every time this static
information change, policies need to be updated. For example, if a information change, policies need to be updated. For example, if a
policy is created that allows access to an application only from the policy is created that allows access to an application only from the
group of Human Resource users (HR-users group), then each time the group of Human Resource users (HR-users group), then each time the
HR-users group changes, the policy needs to be updated. HR-users group changes, the policy needs to be updated.
We call these dynamic Policy Endpoint Groups "Meta-data Driven We call these dynamic Policy Endpoint Groups "Metadata Driven
Groups". The meta-data is a tag associated with endpoint information Groups". The metadata is a tag associated with endpoint information
such as User, Application, or Device. The mapping from meta-data to such as User, Application, or Device. The mapping from metadata to
dynamic content could come from a standards-based or proprietary dynamic content could come from a standards-based or proprietary
tools. Security Controller could use any available mechanisms to tools. Security Controller could use any available mechanisms to
derive this mapping and to make automatic updates to policy content derive this mapping and to make automatic updates to policy content
if the mapping information changes. The system SHOULD allow for if the mapping information changes. The system SHOULD allow for
multiple, or sets of tags to be applied to a single network object. multiple, or sets of tags to be applied to a single endpoint.
Client-Facing policy interface must support endpoint groups for Client-Facing interface must support Endpoint Groups as a target for
expressing a Security Policy. The following meta-data driven groups a Security Policy. The following metadata driven groups MAY be used
MAY be used for configuring security polices: for configuring Security Polices:
User-Group: This group identifies a set of users based on a tag or User-Group: This group identifies a set of users based on a tag or
on static information. The tag to identify user is dynamically static information such as user-names. The tag identifying users,
derived from systems such as Active Directory or LDAP. For is dynamically derived from systems such as Active Directory or
example, an organization may have different User-groups, such as LDAP. For example, an organization may have different User-
HR-users, Finance-users, Engineering-users, to classify a set of groups,such as HR-users, Finance-users, Engineering-users, to
users in each department. classify a set of users in each department.
Device-Group: This group identifies a set of devices based on a tag Device-Group: This group identifies a set of devices based on a tag
or on static information. The tag to identify device is or device information. The tag identifying the devices, is
dynamically derived from systems such as configuration management dynamically derived from systems such as configuration management
database (CMDB). For example, a Security Admin may want to database (CMDB). For example, a Security Admin may want to
classify all machines running a particular operating system into classify all machines running a particular operating system into
one group and machines running a different operating system into one group and machines running a different operating system into
another group. another group.
Application-Group: This group identifies a set of applications based Application-Group: This group identifies a set of applications based
on a tag or on static information. The tag to identify on a tag or on application names. The tag identifying
application is dynamically derived from systems such as CMDB. For applications, is dynamically derived from systems such as CMDB.
example, a Security Admin may want to classify all applications For example, a Security Admin may want to classify all
running in the Legal department into one group and all applications running in the Legal department into one group and
applications running in the HR department into another group. In all applications running in the HR department into another group.
some cases, the application can semantically associated with a VM In some cases, the application can semantically associated with a
or a device. However, in other cases, the application may need to VM or a device. However, in other cases, the application may need
be associated with a set of identifiers (e.g., transport numbers, to be associated with a set of identifiers (e.g., transport
signature in the application packet payload) that identify the numbers, signature in the application packet payload) that
application in the corresponding packets. The mapping of identify the application in the corresponding packets. The
application names/tags to signatures in the associated application mapping of application names/tags to signatures in the associated
packets should be defined and communicated to the NSF. The application packets should be defined and communicated to the NSF.
Client-Facing Interface shall support the communication of this The Client-Facing Interface shall support the communication of
information. this information.
Location-Group: This group identifies a set of location tags. Tag Location-Group: This group identifies a set of locations. Tag may
may correspond 1:1 to location. The tag to identify location is correspond 1:1 to location. The tag identifying locations is
either statically defined or dynamically derived from systems such either statically defined or dynamically derived from systems such
as CMDB. For example, a Security Admin may want to classify all as CMDB. For example, a Security Admin may want to classify all
sites/locations in a geographic region as one group. sites/locations in a geographic region as one group.
4.8. Requirement to express rich set of policy rules 4.8. Requirement to express rich set of Policy Rules
The security policy rules can be as simple as specifying a match for The Policy Rules is a central component of any Security Policy but
the user or application specified through "Policy Endpoint Group" and rule requirements may vary based on use-cases and it is hard to
take one of the "Policy Actions" or more complicated rules that define a complete set that works for everyone. In order to build a
specify how two different "Policy Endpoint Groups" interact with each rich interface, we are going to take a different approach; we will
other. The Client-Facing interface must support mechanisms to allow define the building block of rules and let Security Admin build rules
the following rule matches. using these construct so that Security Policies meet their
requirements:
Policy Endpoint Groups: The rule must allow a way to match either a Segmentation policies : This set of policies create rules for
single or a member of a list of "Policy Endpoint Groups". communication between two Endpoint Groups. An organization may
restrict certain communication between a set of user and
applications for example. The segmentation policy may be a micro-
segmentation rule between components of complex applications or
related to hybrid cloud deployment based on location.
There must be a way to express a match between two "Policy Endpoint Threat policies: This set of policies creates rules to prevent
Groups" so that a policy can be effective for communication between communication with externally or internally identified threats.
two groups. The threats may be well knows such as threat feeds from external
sources or dynamically identified by using specialty devices in
the network.
Direction: The rule must allow a way to express whether Security Governance and Compliance policies: This set of policies creates
Admin wants to match the "Policy Endpoint Group" as the source or rules to implement business requirement such as controlling access
destination. The default should be to match both directions, if to internal or external resources for meeting regulatory
the direction rule is not specified in the policy. compliance or business objectives.
Threats: The rule should allow the security administrator to express In order to build a generic rule engine to satisfy diverse set of
a match for threats that come either in the form of feeds (such as Policy Rules, we propose following objects:
Botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or
speciality security appliances. Threats could be identified by
Tags/names in policy rules. The tag is a label of one or more
event types that may be detected by a threat detection system.
The threat could be from malware and this requires a way to match for In order to build a generic rule engine to satisfy diverse set of
virus signatures or file hashes. Policy Rules, we propose following objects:
4.9. Requirement to express rich set of policy actions Source Policy Endpoint Group: A source target of the Policy Rule.
This may be special object "ALL" if all groups meet this criteria.
Security Admin must be able to configure a variety of actions within Destination Policy Endpoint Group: A destination target of the
a security policy. Typically, security policy specifies a simple Policy Rule. This may be a special object "ALL", if all groups
meet this criteria.
Direction: By default rules are applied in either direction but this
object can be used to make rule definition uni-directional.
Threat Group: An object that represents a set of static or dynamic
threats such as Botnet, GeoIP, URL feeds or virus and malware
signatures detected dynamically. This object can be used as
source or destination target in a rule.
Match Condition: An object that represents a set of allowed
interactions. It could be as simple as group of application names
or L4 ports allowed between two Endpoint Groups. It could very
well that all traffic is allowed between two groups.
Exceptions: In order to truly build rules which are Security Admin
and built with user semantics, we should allow to specify
exceptions to the match criteria. This will greatly simplify
Security Admin's task. E.g., we could build a rule that allows
all traffic between two groups except a particular application or
threat source.
Actions: Action is what makes rule and Policy work. The Action is
defined in details in next section. We RECOMMEND that there be a
one-to-one mapping between rule and action otherwise if multiple
rules are associated with one action, it may be a difficult to
manage Security Policy lifecycle as they evolve.
4.9. Requirement to express rich set of Policy Actions
Security Admin must be able to configure a variety of actions for a
given Policy Rule. Typically, Security Policy specifies a simple
action of "deny" or "permit" if a particular condition is matched. action of "deny" or "permit" if a particular condition is matched.
Although this may be enough for most of the simple policies, the Although this may be enough for most use-cases, the I2NSF Client-
I2NSF Client-Facing interface must also provide a more comprehensive Facing interface must provide a more comprehensive set of actions so
set of actions so that the interface can be used effectively across that the interface can be used effectively across various security
various security functions. needs.
Policy action MUST be extensible so that additional policy action Policy action MUST be extensible so that additional policy action
specifications can easily be added. specifications can easily be added.
The following list of actions SHALL be supported: The following list of actions SHALL be supported:
Permit: This action means continue processing the next rule or allow Permit: This action means continue processing the next rule or allow
the packet to pass if this is the last rule. This is often a the packet to pass if this is the last rule. This is often a
default action. default action.
skipping to change at page 17, line 8 skipping to change at page 18, line 24
Drop connection: This action means stop further packet processing, Drop connection: This action means stop further packet processing,
drop the packet, and drop connection (for example, by sending a drop the packet, and drop connection (for example, by sending a
TCP reset). TCP reset).
Log: This action means create a log entry whenever a rule is Log: This action means create a log entry whenever a rule is
matched. matched.
Authenticate connection: This action means that whenever a new Authenticate connection: This action means that whenever a new
connection is established it should be authenticated. connection is established it should be authenticated.
Quarantine/Redirect: This action may be relevant for event driven Quarantine/Redirect: This action is useful for threat remediation
policy where certain events would activate a configured policy purposes. If a security breach or infection point is detected, a
that quarantines or redirects certain packets or flows. The Security Admin would like to isolate for purpose of remediation or
redirect action must specify whether the packet is to be tunneled controlling attack surface.
and in that case specify the tunnel or encapsulation method and
destination identifier.
Netflow: This action creates a Netflow record; Need to define Netflow: This action creates a Netflow record; Need to define
Netflow server or local file and version of Netflow. Netflow server or local file and version of Netflow.
Count: This action counts the packets that meet the rule condition. Count: This action counts the packets that meet the rule condition.
Encrypt: This action encrypts the packets on an identified flow. Encrypt: This action encrypts the packets on an identified flow.
The flow could be over an IPSEC tunnel, or TLS session for The flow could be over an IPSEC tunnel, or TLS session for
instance. instance.
skipping to change at page 17, line 35 skipping to change at page 18, line 49
The flow could be over an IPSEC tunnel, or TLS session for The flow could be over an IPSEC tunnel, or TLS session for
instance. instance.
Throttle: This action defines shaping a flow or a group of flows Throttle: This action defines shaping a flow or a group of flows
that match the rule condition to a designated traffic profile. that match the rule condition to a designated traffic profile.
Mark: This action defines traffic that matches the rule condition by Mark: This action defines traffic that matches the rule condition by
a designated DSCP value and/or VLAN 802.1p Tag value. a designated DSCP value and/or VLAN 802.1p Tag value.
Instantiate-NSF: This action instantiates an NSF with a predefined Instantiate-NSF: This action instantiates an NSF with a predefined
profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or profile. An NSF can be any of the FW, IPS, IDS, honeypot, or VPN,
VPN, etc. etc.
WAN-Accelerate: This action optimizes packet delivery using a set of
predefined packet optimization methods.
Load-Balance: This action load balances connections based on
predefined LB schemes or profiles.
The policy actions should support combination of terminating actions The policy actions should support combination of terminating actions
and non-terminating actions. For example, Syslog and then Permit; and non-terminating actions. For example, Syslog and then Permit;
Count and then Redirect. Count and then Redirect.
Policy actions SHALL support any L2, L3, L4-L7 policy actions. Policy actions SHALL support any L2, L3, L4-L7 policy actions.
4.10. Requirement to express policy in a generic model 4.10. Requirement for consistent policy enforcement
Client-Facing interface SHALL provide a generic metadata model that
defines once and then be used by appropriate model elements any
times, regardless of where they are located in the class hierarchy,
as necessary.
Client-Facing interface SHALL provide a generic context model that As proposed in this document that the Client-Facing interface MUST be
enables the context of an entity, and its surrounding environment, to built using higher-level "User-Constructs" that are independent of
be measured, calculated, and/or inferred. network design and implementations. In order to achieve this, it
becomes important that Security Controller functionality becomes more
complex that keep track of various objects that are used to express
Security Policies. The Security Controller MUST evaluate the
Security Policies whenever these objects and network topology change
to make sure that Security Policy is consistently enforced as
expressed.
Client-Facing interface SHALL provide a generic policy model that Although this document does not specify how Security Controller
enables context-aware policy rules to be defined to change the achieve this and any implementation challenges. It is assumed that
configuration and monitoring of resources and services as context once Security Controller uses Client-Facing interface to accept
changes. Security Policies; it would maintain the security posture as per the
Security Policies during all changes in network or Endpoints and
other building blocks of the framework.
Client-Facing interface SHALL provide the ability to apply policy or An event must be logged by Security Controller when a Security Policy
multiple sets of policies to any given object. Policy application is updated due to changes in it's building blocks such as Endpoint
process SHALL allow for nesting capabilities of given policies or set Group contents or the Security Policy is moved from one enforcement
of policies. For example, an object or any given set of objects point to another because the Endpoint has moved in the network. This
could have application team applying certain set of policy rules, may help in debugging and auditing for compliance reasons. The
while network team would apply different set of their policy rules. Security Admin may optionally receive notifications if supported and
Lastly, security team would have an ability to apply its set of desired.
policy rules, being the last policy to be evaluated against.
4.11. Requirement to detect and correct policy conflicts 4.11. Requirement to detect and correct policy conflicts
Client-Facing interface SHALL be able to detect policy "conflicts", Client-Facing interface SHALL be able to detect policy "conflicts",
and SHALL specify methods on how to resolve these "conflicts" and SHALL specify methods on how to resolve these "conflicts"
For example: two clients issues conflicting set of security policies For example a newly expressed Security Policy could conflict with
to be applied to the same Policy Endpoint Group. existing Security Policies applied to a set of Policy Endpoint
Groups. This MUST be detected and Security Admin be allowed for
manual correction if needed.
4.12. Requirement for backward compatibility 4.12. Requirement for backward compatibility
It MUST be possible to add new capabilities to Client-Facing It MUST be possible to add new capabilities to Client-Facing
interface in a backward compatible fashion. interface in a backward compatible fashion.
4.13. Requirement for Third-Party integration 4.13. Requirement for Third-Party integration
The security policies in a network may require the use of specialty The security framework in a network may require the use of a
devices such as honeypots, behavioral analytics, or SIEM in the specialty device such as honeypot, behavioral analytic, or SIEM for
network, and may also involve threat feeds,virus signatures, and threat detection; the device may provide threat information such as
malicious file hashes as part of comprehensive security policies. threat feeds, virus signatures, and malicious file hashes.
The Client-Facing interface must allow Security Admin to configure The Client-Facing interface must allow Security Admin to include
these threat sources and any other information to provide integration these devices under Security Controller's Client-Facing interface so
and fold this into policy management. that a Security Policy could be expressed using information from such
devices; basically it allows ability to integrate third part devices
into the Security Policy framework.
4.14. Requirement to collect telemetry data 4.14. Requirement to collect telemetry data
One of the most important aspect of security is to have visibility One of the most important aspect of security is to have visibility
into the networks. As threats become more sophisticated, Security into the network. As threats become more sophisticated, Security
Admin must be able to gather different types of telemetry data from Admin must be able to gather different types of telemetry data from
various devices in the network. The collected data could simply be various NSFs in the network. The collected data could simply be
logged or sent to security analysis engines for behavioral analysis, logged or sent to security analysis engines for behavioral analysis,
policy violations, and for threat detection. policy violations, and for threat detection.
The Client-Facing interface MUST allow Security Admin to collect The Client-Facing interface MUST allow Security Admin to collect
various kinds of data from NSFs. The data source could be syslog, various kinds of data from NSFs. The data source could be syslog,
flow records, policy violation records, and other available data. flow records, policy violation records, and other available data.
Detailed Client-Facing interface telemetry data should be available Client-Facing interface must provide a set of telemetry data
between clients and Security Controller. Clients should be able to available to Security Admin from Security Controller. The Security
subscribe and receive these telemetry data. Admin should be able to subscribe and receive to this data set.
client should be able to receive notifications when a policy is
dynamically updated.
5. Operational Requirements for the Client-Facing Interface 5. Operational Requirements for the Client-Facing Interface
5.1. API Versioning 5.1. API Versioning
Client-Facing interface must support a version number for each Client-Facing interface must support a version number for each
RESTful API. This is very important because the client application RESTful API. This is important since Security Controller could be
and the controller application may come from different vendors. Even deployed by using multiple componenets and different pieces may come
if the vendor is same, it is hard to imagine that two different from different vendors; it is difficult to isolate and debug issues
applications would be released in lock step. without ablility to track each component's operational behavior.
Even if the vendor is same for all the components, it is hard to
imagine that all pieces would be released in lock step by the vendor.
Without API versioning, it is hard to debug and figure out issues if Without API versioning, it is hard to debug and figure out issues
an application breaks. Although API versioning does not guarantee when deploying Security Controller and its components built overtime
that applications will always work, it helps in debugging if the across multiple release cycles. Although API versioning does not
problem is caused by an API mismatch. guarantee that Security Controller would always work but it helps in
debugging if the problem is caused by an API mismatch.
5.2. API Extensiblity 5.2. API Extensibility
Abstraction and standardization of Client-Facing interface is of Abstraction and standardization of Client-Facing interface is of
tremendous value to Security Admin as it gives them the flexibility tremendous value to Security Admins as it gives them the flexibility
of deploying any vendor's NSF without need to redefine their policies of deploying any vendor's NSF without need to redefine their policies
if or when a NSF is changed. if or when a NSF is changed.
If a vendor comes up with new feature or functionality that can't be If a vendor comes up with new feature or functionality that can't be
expressed through the currently defined Client-Facing interface, expressed through the currently defined Client-Facing interface,
there must be a way to extend existing APIs or to create a new API there SHALL be a way to extend existing APIs or to create a new API
that is relevant for that NSF vendor only. that addresses specific vendors's new NSF functionality.
5.3. APIs and Data Model Transport 5.3. APIs and Data Model Transport
The APIs for client interface must be derived from the YANG based The APIs for interface SHALL be derived from the YANG based data
data model. The YANG data model for client interface must capture model. The data model for Client-Facing interface must capture all
all the requirements as defined in this document to express a the requirements as defined in this document to express a Security
security policy. The interface between a client and controller must Policy. The interface between a client and controller must be
be reliable to ensure robust policy enforcement. One such transport reliable to ensure robust policy enforcement. One such transport
mechanism is RESTCONF that uses HTTP operations to provide necessary mechanism is RESTCONF that uses HTTP operations to provide necessary
CRUD operations for YANG data objects, but any other mechanism can be CRUD operations for YANG data objects, but any other mechanism can be
used. used.
5.4. Notification 5.4. Notification and Monitoring
Client-Facing interface must allow Security Admin to collect various Client-Facing interface must allow ability to collect various alarms,
alarms and events from the NSF in the network. The events and alarms events, statistics about enforcement and policy violations from NSFs
may be either related to security policy itself or related to NSF in the network. The events and alarms may be associated with a
where the policy is implemented. The events and alarms could also be specific policy or associated with operating conditions of a specific
used as an input to the security policy for autonomous handling as NSF in general. The statistics may be a measure of potential
specified in a given security policy. Security Policy violations or general data that reflect operational
behavior of a NSF. The events, alarms and statistics may also be
used as an input to automate Security Policy lifecycle management.
5.5. Affinity 5.5. Affinity
Client-Facing interface must allow Security Admin to pass any Client-Facing interface must allow Security Admin to pass any
additional metadata that a user may want to provide for a security additional metadata that a user may want to provide with a Security
policy e.g. certain security policy needs to be implemented only on a Policy e.g., if the policy needs to be enforced by a very highly
very highly secure NSF with Trusted Platform Module (TPM) chip. A secure NSF with Trusted Platform Module (TPM) chip. Another example
user may require Security Controller not to share the NSF with other would be, if a policy can not be enforced by a multi-tenant NSF.
tenant, this must be expressed through the interface API. This would Security Admin control on operating environment
5.6. Test Interface 5.6. Test Interface
Client-Facing interface must allow Security Admin ability to test a Client-Facing interface must support ability to test a Security
security policy before it is enforced e.g. a user may want to verify Policy before it is enforced e.g., a user may want to verify whether
whether the policy creates any potential conflicts with the existing the policy creates any potential conflicts with existing policies or
policies or if there are even resources to enforce the policy. The if there are enough resources and capability to enforce this policy.
test policy would provide such a capability without actually applying The test interface would provide a mechanism to Security Admin where
the policies. policies could be tested in the actual environment before
enforcement.
6. Security Considerations 6. Security Considerations
Client-Facing interface to Security controller must be protected to Client-Facing interface to Security controller must be protected to
ensure that entire security posture is not compromised. This draft make sure that entire security posture is not compromised. This
mandates that interface must have proper authentication and draft mandates that interface must have proper authentication and
authorization with Role Based Access Controls to address multi- authorization control mechanisms to ward off malicious attacks. The
tenancy requirement. The draft does not specify a particular draft does not specify a particular mechanism as different
mechanism as different organization may have different needs based on organization may have different needs based on their specific
their deployment. This has been discussed extensively in this draft. deployment environment and moreover new methods may evolve to better
suit contemporary requirements.
Authentication and authorization alone may not be sufficient for Authentication and authorization alone may not be sufficient for
Client-Facing interface; the interface API must be validated for Client-Facing interface; the interface API must be validated for
proper inputs to guard against attacks. The type of checks and proper input to guard against attacks. The type of checks and
verification may be specific to each interface API, but a careful verification may be specific to each interface API, but a careful
consideration must be made to ensure that Security Controller is not consideration must be made to ensure that Security Controller is not
compromised. compromised.
We recommend that all attack surface must be examined with careful
consideration of the operating environment and available industry
best practices must be used such as process and standards to protect
security controller against malicious or inadvertent attacks.
7. IANA Considerations 7. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove This document requires no IANA actions. RFC Editor: Please remove
this section before publication. this section before publication.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Adrian Farrel, Linda Dunbar and Diego The authors would like to thank Adrian Farrel, Linda Dunbar and Diego
R.Lopez from IETF I2NSF WG for helpful discussions and advice. R.Lopez from IETF I2NSF WG for helpful discussions and advice.
The authors would also like to thank Kunal Modasiya, Prakash T. The authors would also like to thank Kunal Modasiya, Prakash T.
Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful
discussions. discussions.
9. Normative References 9. Normative References
[I-D.ietf-i2nsf-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-06 (work in
progress), July 2017.
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "I2NSF Problem Statement and Use cases", and J. Jeong, "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-15 (work in draft-ietf-i2nsf-problem-and-use-cases-16 (work in
progress), April 2017. progress), May 2017.
Authors' Addresses Authors' Addresses
Rakesh Kumar Rakesh Kumar
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: rkkumar@juniper.net Email: rkkumar@juniper.net
 End of changes. 114 change blocks. 
340 lines changed or deleted 434 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/