| I2NSF Working Group | R. Kumar |
| Internet-Draft | A. Lohiya |
| Intended status: Informational | Juniper Networks |
| Expires: January 18, 2019 | D. Qi |
| Bloomberg | |
| N. Bitar | |
| S. Palislamovic | |
| Nokia | |
| L. Xia | |
| Huawei | |
| J. Jeong | |
| Sungkyunkwan University | |
| July 17, 2018 |
Information Model for Consumer-Facing Interface to Security Controller
draft-kumar-i2nsf-client-facing-interface-im-07
This document defines an information model for Consumer-Facing interface to Security Controller based on the requirements identified in [I-D.ietf-i2nsf-client-facing-interface-req]. The information model defines various managed objects and relationship among these objects needed to build the interface. The information model is organized based on the "Event-Condition-Event" (ECA) policy model defined by a capability information model for Interface to Network Security Functions (I2NSF) [I-D.ietf-i2nsf-capability].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 18, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Interface to Network Security Functions (I2NSF) defines a Consumer-Facing Interface to deliver high-level security policies to Security Controller [RFC8192][RFC8329] for securiy enforcement in Network Security Functions (NSFs).
The Consumer-Facing Interface would be built using a set of objects, with each object capturing a unique set of information from Security Admin (i.e., I2NSF User [RFC8329]) needed to express a Security Policy. An object may have relationship with various other objects to express a complete set of requirement. An information model captures the managed objects and relationship among these objects. The information model proposed in this document is in accordance with interface requirements as defined in [I-D.ietf-i2nsf-client-facing-interface-req].
An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as the basic model for both the NSF-Facing interface and Consumer-Facing Interface security policy model of this document. The information model proposed in this document is structured in accordance with the "Event-Condition-Event" (ECA) policy model.
[RFC3444] explains differences between an information and data model. This document use the guidelines in [RFC3444] to define an information model for Consumer-Facing Interface in this document. Figure 1 shows a high-level abstraction of Consumer-Facing Interface. A data model, which represents an implementation of the proposed information model in a specific data representation language, will be defined in a separate document.
+-----------------+ +-----------------+
| | | |
| Consumer-Facing +------>+ Consumer Facing |
| Interface | | Interface |
|Information Model| | Data Model |
+--------+--------+ +-----------------+
^
|
|
+-------------+-------------+
| |
| Policy-general |
| |
+-------------+-------------+
^
|
+------------+-------------+------------+--------------+
| | | | |
+-----+----+ +----+-----+ +----+----+ +----+----+ +------+-----+
| | | | | | | | | |
| Multi | | Endpoint | | Policy | | Threat | | Telemetry |
| tenancy | | groups | | | | feed | | data |
+----------+ +----------+ +----+----+ +---------+ +------------+
^
|
|
+------+------+
| |
| Rule |
| |
+------+------+
^
|
+----------------+----------------+
| | |
+------+------+ +------+------+ +------+------+
| | | | | |
| Event | | Condition | | Action |
| | | | | |
+-------------+ +-------------+ +-------------+
Figure 1: Diagram for High-level Abstraction of Consumer-Facing Interface
A Policy object represents a mechanism to express a Security Policy by Security Admin (i.e., I2NSF User) using Consumer-Facing Interface toward Security Controller; the policy would be enforced on an NSF. The Policy object SHALL have following information:
A policy is a container of Rules. In order to express a Rule, a Rule must have complete information such as where and when a policy needs to be applied. This is done by defining a set of managed objects and relationship among them. A Policy Rule may be related segmentation, threat mitigation or telemetry data collection from an NSF in the network, which will be specified as the sub-model of the policy model in the subsequent sections.
The rule object SHALL have the following information:
The Event Object contains information related to scheduling a Rule. The Rule could be activated based on a time calendar or security event including threat level changes.
Event object SHALL have following information:
This object represents an event map containing security events and threat levels used for dynamic policy enforcement. The Event-Map-Group object SHALL have following information:
This object represents Conditions that Security Admin wants to apply the checking on the traffic in order to determine whether the set of actions in the Rule can be executed or not.
The Condition object SHALL have following information:
The condition object is made of condition clauses. Each condition clause consists of three tuples; variable, operator and value.
The variable and value can be source and destination IP address, for example, and they have logical operator in between to check whether they match the condition criteria set by a security admin. For Example: If condition A AND B is true: THEN execute actions ENDIF where A denotes a destination address, and B denotes a blacklisted IP address. The operator AND is the logical AND operation.
1..n
+----------------+
| |
+------------>+ Policy rule |
| | |
1..n | +----------------+
+--------+--------+
| |
+Condition clause +
| |
+--------+--------+
^ ^ ^
| | |
+--------------+ | +--------------+
1..n | 1..n | 1..n |
+--------+-------+ +--------+--------+ +-------+-------+
| | | | | |
| Variable | | Operator | | Value |
| | | | | |
+----------------+ +-----------------+ +---------------+
Figure 2: Condition Clause Diagram
The semantics used in a condition clause is also used in the clauses in the Event-submodel and Action sub-model.
This object represents actions that Security Admin wants to perform based on certain traffic class.
The Action object SHALL have following information:
Multi-tenancy is an important aspect of any application that enables multiple administrative domains in order to manage application resources. An Enterprise organization may have multiple tenants or departments such as Human Resources (HR), Finance, and Legal, with each tenant having a need to manage their own Security Policies. In a Service Provider, a tenant could represent a Customer that wants to manage its own Security Policies.
There are multiple managed objects that constitute multi-tenancy aspects. This section lists these objects and any relationship among these objects. Below diagram shows an example of multi-tenancy in an Enterprise domain.
+-------------------+
(Multi-Tenancy) | Domain |
|(e.g., Enterprise) |
+---------+---------+
^
|
+--------------------+--------------------+
| | |
+--------+-------+ +---------+--------+ +--------+--------+
| Department 1 | | Department 2 | | Department n |
+--------+-------+ +---------+--------+ +--------+--------+
^ ^ ^
| | |
+--------+--------+ +-----------------+ +--------+--------+
| Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n |
+--------+--------+ +--------+--------+ +--------+--------+
^ ^ ^
| | |
+--------+--------+ +--------+--------+ +--------+--------+
| Tenant 1..n | | Tenant 1..n | | Tenant 1..n |
+-----------------+ +-----------------+ +-----------------+
Figure 3: Multi-tenancy Diagram
This object defines a boundary for the purpose of policy management within a Security Controller. This may vary based on how the Security Controller is deployed and hosted. For example, if an Enterprise hosts a Security Controller in their network; the domain in this case could just be the one that represents that Enterprise. But if a Cloud Service Provider hosts managed services, then a domain could represent a single customer of that Provider. Multi-tenancy model should be able to work in all such environments.
The Policy-Domain object SHALL have following information:
This object defines an entity within an organization. The entity could be a department or business unit within an Enterprise organization that would like to manage its own Policies due to regulatory compliance or business reasons.
The Policy-Tenant object SHALL have following information:
This object defines a set of permissions assigned to a user in an organization that wants to manage its own Security Policies. It provides a convenient way to assign policy users to a job function or a set of permissions within the organization.
The Policy-Role object SHALL have the following information:
This object represents a unique identity within an organization. The identity authenticates with Security Controller using credentials such as a password or token in order to perform policy management. A user may be an individual, system, or application requiring access to Security Controller.
The Policy-User object SHALL have the following information:
This object represents authentication schemes supported by Security Controller.
This Policy-Management-Authentication-Method object SHALL have the following information:
The Policy Endpoint Group is a very important part of building User-construct based policies. Security Admin would create and use these objects to represent a logical entity in their business environment, where a Security Policy is to be applied.
There are multiple managed objects that constitute a Policy Endpoint Group. This section lists these objects and relationship among these objects.
+-------------------+
| Endpoint Group |
+---------+---------+
^
|
+------------+-------+-----+---------------+
1..n | 1..n | 1..n | 1..n |
+-----+----+ +----+---+ +------+------+ +-----+----+
| User | | Device | | Application | | Location |
+----------+ +--------+ +-------------+ +----------+
Figure 4: Endpoint Group Diagram
This object represents information source for tag. The tag in a group must be mapped to its corresponding contents to enforce a Security Policy.
Tag-Source object SHALL have the following information:
This object represents a user group based on either tag or other information.
The User-Group object SHALL have the following information:
This object represents a device group based on either tag or other information.
The Device-Group object SHALL have the following information:
This object represents an application group based on either tag or other information.
The Application-Group object SHALL have the following information:
This object represents a location group based on either tag or other information.
The 'Location-Group' object SHALL have the following information:
The threat prevention plays an important part in the overall security posture by reducing the attack surfaces. This information could come in the form of threat feeds such as Botnet and GeoIP feeds usually from a third party or external service.
There are multiple managed objects that constitute this category. This section lists these objects and relationship among these objects.
+---------------------+
| Threat Prevention |
+----------+----------+
^
|
+---------------------+----------------------+
1..n | 1..n | 1..n |
+----------+---------+ +---------+---------+ +----------+---------+
| Threat feed | | Custom list | | Malware scan group |
+--------------------+ +-------------------+ +--------------------+
Figure 5: Threat Prevention Diagram
This object represents a threat feed such as Botnet servers and GeoIP.
The Threat-Feed object SHALL have the following information:
This object represents a custom list created for the purpose of defining exception to threat feeds. An organization may want to allow a certain exception to threat feeds obtained from a third party
The Custom-List object SHALL have the following information:
This object represents information needed to detect malware. This information could come from a local server or uploaded periodically from a third party.
The Malware-Scan-Group object SHALL have the following information:
Telemetry provides System Admin with the visibility of the network activities which can be tapped for further security analytics, e.g., detecting potential vulnerabilities, malicious activities, etc.
This object contains information collected for telemetry.
The Telemetry-Data object SHALL have the following information:
This object contains information related to telemetry source. The source would be an NSF in the network.
The Telemetry-Source object SHALL have the following information:
This object contains information related to telemetry destination. The destination is usually a collector which is either a part of Security Controller or external system such as SIEM.
The Telemetry-Destination object SHALL have the following information:
Role-Based Access Control (RBAC) provides a powerful and centralized control within a network. It is a policy neutral access control mechanism defined around roles and privileges. The components of RBAC, such as role-permissions, user-role and role-role relationships, make it simple to perform user assignments.
+--------------+
| |
| User 1 + (has many)
| |\
+--------------+ \ +---------------+ +-------------+
. \ | | (has many) | |
. --->+ List of roles +----------->+ Permissions |
+--------------+ / | | | |
| | / +---------------+ +-------------+
| User n +/
| | (has many)
+--------------+
Figure 6: RBAC Diagram
As shown in Figure 6, a role represents a collection of permissions (e.g., accessing a file server or other particular resources). A role may be assigned to one or multiple users. Both roles and permissions can be organized in a hirarchy. A role may consists of other roles and permissions.
Following are the steps required to build RBAC.
An information model provides a mechanism to protect Consumer-Facing Interface between System Admin (i.e., I2NSF User) and Security Controller. One of the specified mechanism must be used to protect an Enterprise network, data and all resources from external attacks. This information model mandates that the interface must have proper authentication and authorization with Role-Based Access Controls to address the multi-tenancy requirement. The document does not mandate that a particular mechanism should be used because a different organization may have different needs based on their deployment.
This document requires no IANA actions. RFC Editor: Please remove this section before publication.
This work was supported by Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIT) (No. R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning).
This document is the work of I2NSF working group, greatly benefiting from inputs and suggestions by Kunal Modasiya, Prakash T. Sehsadri and Srinivas Nimmagadda from Juniper Networks. The authors sincerely appreciate their contributions.
The following are contributing authors of this document, who are considered co-authors:
The following changes have been made from draft-kumar-i2nsf-client-facing-interface-im-06: