I2NSF Working Group R. Kumar Internet-Draft A. Lohiya Intended status: Informational Juniper Networks Expires: November 1, 2017 D. Qi Bloomberg N. Bitar S. Palislamovic Nokia L. Xia Huawei April 30, 2017 Information model for Client-Facing Interface to Security Controller draft-kumar-i2nsf-client-facing-interface-im-02 Abstract This document defines information model for Client-Facing interface to Security Controller based on the requirements identified in [I-D.kumar-i2nsf-client-facing-interface-req]. The information model defines various managed objects and relationship among these objects needed to build the interface. Status of This Memo 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 http://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 November 1, 2017. Copyright Notice Copyright (c) 2017 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 Kumar, et al. Expires November 1, 2017 [Page 1] Internet-Draft Client Interface Information Model April 2017 (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 3. Information Model for Multi Tenancy . . . . . . . . . . . . . 4 3.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Policy-Management-Authentication-Method . . . . . . . . . 6 4. Information Model for Policy Endpoint Groups . . . . . . . . 6 4.1. Meta-Data-Source . . . . . . . . . . . . . . . . . . . . 7 4.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Application-Group . . . . . . . . . . . . . . . . . . . . 8 4.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 9 5. Information Model for Threat Prevention . . . . . . . . . . . 9 5.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 10 5.4. Event-Map-Group . . . . . . . . . . . . . . . . . . . . . 11 6. Information Model for Telemetry Data . . . . . . . . . . . . 11 6.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 11 6.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 12 6.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 13 7. Information Model for Policy Instance . . . . . . . . . . . . 13 7.1. Policy-Calendar . . . . . . . . . . . . . . . . . . . . . 13 7.2. Policy-Action . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Policy-Rule . . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Policy-Instance . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Kumar, et al. Expires November 1, 2017 [Page 2] Internet-Draft Client Interface Information Model April 2017 1. Introduction The Security Controller's Client-Facing interfaces would be built using a set of objects, with each object capturing a unique set of information from Security Admin need to express a Security Policy. An objects 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. The information model proposed in this draft is in accordance with interface requirements as defined in [I-D.kumar-i2nsf-client-facing-interface-req]. The [RFC3444] explains differences between an information and data model. This draft use those guidelines to define information model for Client-Facing interface in this draft. A data model, that represents an implementation of the proposed information model in a specific data representation language, will be defined in a separate draft. 2. Conventions Used in this Document BSS: Business Support System CLI: Command Line Interface CMDB: Configuration Management Database Controller: Used interchangeably with Service Provider Security Controller or management system throughout this document CRUD: Create, Retrieve, Update, Delete FW: Firewall GUI: Graphical User Interface IDS: Intrusion Detection System IPS: Intrusion Protection System LDAP: Lightweight Directory Access Protocol NSF: Network Security Function, defined by [I-D.ietf-i2nsf-problem-and-use-cases] OSS: Operation Support System RBAC: Role Based Access Control Kumar, et al. Expires November 1, 2017 [Page 3] Internet-Draft Client Interface Information Model April 2017 SIEM: Security Information and Event Management URL: Universal Resource Locator vNSF: Refers to NSF being instantiated on Virtual Machines 3. Information Model for Multi Tenancy Multi-tenancy is an important aspect of any application that enables multiple administrative domains in order to manage application resources. An organization may have multiple tenants or departments such as HR, Finance, Legal, with each tenant having a need 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. 3.1. Policy-Domain 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 host 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 applicable in all such environments. The 'Policy-Domain' object SHALL have following information: Name: Name of the organization or customer representing this domain Address: Address of the organization or customer Contact: Contact information of the organization or customer Date: Date this account was created or last modified Authentication Method: Authentication method to be used for this domain. It should be reference to a 'Policy-Management- Authentication-Method' object Kumar, et al. Expires November 1, 2017 [Page 4] Internet-Draft Client Interface Information Model April 2017 3.2. Policy-Tenant This object defines an entity within an organization that wants to manage its own Security Policies. The entity could be a Department or a Division that would like to manages its own Policies due to regulatory, compliance or business reasons. The 'Policy-Tenant' object SHALL have following information: Name: Name of the Department or Division within an organization Date: Date this account was created or last modified Domain: This field identifies the domain to which this tenant belongs. This should be reference to a 'Policy-Domain' object 3.3. Policy-Role This object defines a set of permissions assigned to a user in an organization that want to manage its own Security Policies. It provides a convenient way to assign policy users to a job function or set of permissions within the organization. The 'Policy-Role' object SHALL have following information: Name: This field identifies name of the role Date: Date this role was created or last modified Access Profile: This field identifies the access profile for the role. The profile grants or denies access to policy objects. Multiple access profiles can be concatenated together 3.4. Policy-User 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 do policy management. A user may be an individual, system, or application requiring access to Security Controller. The 'Policy-User' object SHALL have following information: Name: Name of user Date: Date this user was created or last modified Kumar, et al. Expires November 1, 2017 [Page 5] Internet-Draft Client Interface Information Model April 2017 Password: User password for basic authentication Email: E-mail address of user Scope Type: This field identifies whether a user has domain-wide or tenant-wide privileges Scope Reference: This field should be reference to either a 'Policy-Domain' or a 'Policy-Tenant' object Role: This field should be reference to a 'Policy-Role' object that defines the specific permissions 3.5. Policy-Management-Authentication-Method This object represents authentication schemes supported by security controller. This 'Policy-Management-Authentication-Method' object' SHALL have following information: Name: This field identifies name of this object Date: Date this object was created or last modified Authentication Method: This field identifies the authentication methods. It could be a password based, token based, certificate based or single sign-on authentication Mutual Authentication: This field indicates whether mutual authentication is mandatory or not Token Server: This field stores the information about server that validates the token submitted as credentials Certificate Server: This field stores the information about server that validates certificates submitted as credentials Single Sign-on Server: This field stores the information about server that validates user credentials 4. Information Model for Policy Endpoint Groups The Policy Endpoint Group is 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. Kumar, et al. Expires November 1, 2017 [Page 6] Internet-Draft Client Interface Information Model April 2017 There are multiple managed objects that constitute Policy Endpoint Group. This section lists these objects and relationship among these objects. 4.1. Meta-Data-Source This object represents information source for meta-data or tag. The meta-data in a group must be mapped to its corresponding contents to enforce a Security Policy. 'Meta-Data-Source' object SHALL have following information: Name: This field identifies name of this object Date: Date this object was created or last modified Tag Type: This field identifies the Endpoint Group type. It can be either a 'User' group or 'App' group or 'Device' group, or 'Location' group Tag Server Information: This field identifies information related to the source of the tag such as IP address and UDP/TCP port information Tag Application Protocol: This filed identifies the protocol e.g. LDAP, Active Directory, or CMDB Tag Server Credentials: This field identifies the credential information needed to access the tag server 4.2. User-Group This object represents a user group based on either tag or other information. The 'User-Group' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Group Type: This field identifies whether the user group is based on 'User-tag', 'User-name', or 'IP-address' Meta-data Server: This field should be reference to a 'Meta-Data- Source' object Kumar, et al. Expires November 1, 2017 [Page 7] Internet-Draft Client Interface Information Model April 2017 Group Member: This field is the 'User-tag, or 'User-names', or IP addresses based on the 'Group Type' Risk Level: This field represents the threat level; valid range may be 0 to 9 4.3. Device-Group This object represents a device group based on either tag or other information. The 'Device-Group' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Group Type: This field identifies whether the device group is based on 'Device-tag' or 'Device-name', or IP address Meta-data Server: This field should be reference to a 'Meta-Data- Source' object Group Member: This field is the 'Device-tag, or 'Device-name', or IP address based on the 'Group Type' Risk Level: This field represents the threat level; valid range may be 0 to 9 4.4. Application-Group This object represents an application group based on either tag or other information. The 'Application-Group' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Group Type: This field identifies whether the device group is based on 'App-tag' or 'App-name', or IP address Meta-data Server: This field should be reference to a 'Meta-Data- Source' object Group Member: This field is the 'Device-tag, or 'Device-name', or IP address and port information based on the 'Group Type' Kumar, et al. Expires November 1, 2017 [Page 8] Internet-Draft Client Interface Information Model April 2017 Risk Level: This field represents the threat level; valid range may be 0 to 9 4.5. Location-Group This object represents an location group based on either tag or other information. The 'Location-Group' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Group Type: This field identifies whether the location group is based on 'Location-tag' or 'Location-name', or IP address Meta-data Server: This field should be reference to a 'Meta-Data- Source' object Group Member: This field is the 'Location-tag, or 'Location- names', or IP addresses based on the 'Group Type' Risk Level: This field represents the threat level; valid range may be 0 to 9 5. Information Model for Threat Prevention The threat prevention plays an important part in the overall security posture by reducing the attack surface. 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. 5.1. Threat-Feed This object represents threat feed such as Botnet servers and GeoIP. The 'Threat-Feed' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Kumar, et al. Expires November 1, 2017 [Page 9] Internet-Draft Client Interface Information Model April 2017 Feed Type: This field identifies whether a feed type is IP address based or URL based. Feed Server: This field identifies the information about the feed provider, it may be an external service or local server Feed Priority: This field represents the feed priority level to resolve conflict if there are multiple feed sources; valid range may be 0 to 9 5.2. Custom-List This object represents custom list created for the purpose of defining exception to threat feeds. An organization may want to allow certain exception to threat feeds obtained from a third party The 'Custom-List' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified List Type: This field identifies whether the list type is IP address based or URL based. List Property: This field identifies the attributes of the list property e.g. Blacklist or Whitelist. List Content: This field contains the blacklist or whitelist contents such as IP addresses or URL names. 5.3. Malware-Scan-Group 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 following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Signature Server: This field contains information about the server from where signatures can be downloaded periodically as updates become available Kumar, et al. Expires November 1, 2017 [Page 10] Internet-Draft Client Interface Information Model April 2017 File Types: This field contains list of file types needed to be scanned for the virus Malware Signatures: This field contains list of malware signatures or hash 5.4. Event-Map-Group 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: Name: This field identifies the name of this object Date: Date this object was created or last modified Security Events: This contains a list of security events Threat Map: This contains a list of threat levels 6. Information Model for Telemetry Data Telemetry provides visibility into the network activities which can be tapped for further security analytics e.g. detecting potential vulnerabilities, malicious activities etc. 6.1. Telemetry-Data This object contains information collected for telemetry. The 'Telemetry-Data' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Logs: This field identifies whether 'Logs' need to be collected Syslogs This field identifies whether 'Syslogs' need to be collected SNMP: This field identifies whether 'SNMP traps' and 'SNMP alarms' need to be collected sFlow: This field identifies whether 'sFlow' data need to be collected Kumar, et al. Expires November 1, 2017 [Page 11] Internet-Draft Client Interface Information Model April 2017 NetFlow: This field identifies whether 'NetFlow' data need to be collected Interface Stats: This field identifies whether 'Interface' data such as packet bytes and counts need to be collected 6.2. Telemetry-Source This object contains information related to telemetry source. The source would be a NSF element in the network. The 'Telemetry-Source' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Source Type: This field contains type of the NSF telemetry source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- NSF", "PROXY-NSF", "VPN-NSF", "DNS", "ACTIVE-DIRECTORY","IP Reputation Authority", "Web Reputation Authority", "Anti- Malware Sandbox", "Honey Pot", "DHCP", "Other Third Party", "ENDPOINT" NSF Access Parameters: This field contains information such as IP address and protocol (UDP or TCP) port number of the NSF providing telemetry data NSF Access Credentials: This field contains username and passwod to authenticate with the NSF Collection Interval: This field contains time in milliseconds between each data collection. For example, a value of 5000 means data is streamed to collector every 5 seconds. Value of 0 means data streaming is event-based. Collection Method: This field contains method of collection whether it is PUSH-based or PULL-based Heartbeat Interval: This field contains time in seconds the source must send telemetry heartbeat QoS Marking: This field contains DSCP value source MUST mark on its generated telemetry packets Kumar, et al. Expires November 1, 2017 [Page 12] Internet-Draft Client Interface Information Model April 2017 6.3. Telemetry-Destination 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 following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Collector State: This field contains the state info regarding the collector Collector Access Parameter: This field contains the information such as IP address and protocol (UDP or TCP) port number for the collector's destination Collector Access Credentials: This field contains the username and passwod for the collector Data Encoding: This field contains the telemetry data encoding, which could in the form of a schema Data Transport: This field contains streaming telemetry data protocols: whether it is gRPC, protocol buffer over UDP, etc. 7. Information Model for Policy Instance In order to enforce a security policy, a policy instance must have complete information such as where and when a policy need to be applied. The policy instantiation is done by combining the managed objects described so far and a few others listed below. 7.1. Policy-Calendar This object contains information related to scheduling a policy. The policy could be activated based on a time calendar or security event including threat level changes. The 'Policy-Calendar' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Kumar, et al. Expires November 1, 2017 [Page 13] Internet-Draft Client Interface Information Model April 2017 Enforecment Type: This field identifies whether the policy enforcement is 'ADMIN-ENFORCED' or 'TIME-ENFORCED', or 'EVENT-ENFORCED' Time Information: This field contains time calendar such as 'BEGIN-TIME' and 'END-TIME' for one time enforcement or recurring time calendar for periodic enforcement Event Map: This field contains security events and threat map in order to determine when a policy need to be activated 7.2. Policy-Action This object represents actions that a Security Admin want to perform based on certain traffic class. The 'Policy-Action' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Primary Action: This field identifies the action when a rule is matched by NSF. The action could be one of 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 'AUTHENTICATE- SESSION', 'IPS, 'APP-FIREWALL' Secondary Action: Security Admin can also specify additional actions if a rule is matched. This could be one of 'LOG', 'SYSLOG', 'SESSION-LOG' 7.3. Policy-Rule This object represents rules that a Security Admin want to define in order to express its business objectives in a Security Policy. The 'Policy-Rule' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Source: This field identifies the source of the traffic. This could be reference to either 'Policy Endpoint Group' or 'Threat-Feed' or 'Custom-List' if Security Admin wants to specify the source otherwise the default is to match all traffic Kumar, et al. Expires November 1, 2017 [Page 14] Internet-Draft Client Interface Information Model April 2017 Destination: This field identifies the destination of the traffic. This could be reference to either 'Policy Endpoint Group' or 'Threat-Feed' or 'Custom-List' if Security Admin wants to specify the destination otherwise the default is to match all traffic Exception: This field identifies the exception consideration when 'Source' and 'Destination' are matched for a given communication. This should be reference to 'Policy Endpoint Group' object Action: This field identifies the action taken when 'Source' and 'Destination' are matched for a given communication Precedence: This field identifies the precedence assigned to this rule by Security Admin. This is helpful in conflict resolution when two or more rules match a given traffic class 7.4. Policy-Instance This object represents a mechanism to express a Security Policy by Security Admin using Security Controller Client-Facing interface; the policy would be enforced on a NSF. The 'Policy-Instance' object SHALL have following information: Name: This field identifies the name of this object Date: Date this object was created or last modified Rules: This field contains list of rules. If the rule does not have a user defined precedence, then any conflict must be manually resolved Scheduling Type: This field specifies when this policy should be scheduled. The policy could be scheduled based on time calendar or event-map Scheduling Information: This field contains either the 'Calendar' or 'Event-map' based on 'Schedule type' Owner: This field defines the owner of this policy. Only the owner is authorized to modify the contents of the policy Kumar, et al. Expires November 1, 2017 [Page 15] Internet-Draft Client Interface Information Model April 2017 8. Security Considerations Information model provides mechanism to protect Client-Facing interface to Security controller. One of the specified mechanism must be used to protect Enterprise network, data and all resources from external attacks. This model mandates that interface must have proper authentication and authorization with Role Based Access Controls to address multi-tenancy requirement. The draft does not mandate that a particular mechanism be used as different organization may have different needs based on their deployment. 9. IANA Considerations This document requires no IANA actions. RFC Editor: Please remove this section before publication. 10. Acknowledgements The authors would like to thank Kunal Modasiya, Prakash T. Sehsadri and Srinivas Nimmagadda from Juniper Networks for helpful discussions. 11. Informative References [I-D.ietf-i2nsf-problem-and-use-cases] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "I2NSF Problem Statement and Use cases", draft-ietf-i2nsf-problem-and-use-cases-15 (work in progress), April 2017. [I-D.ietf-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-03 (work in progress), March 2017. [I-D.kumar-i2nsf-client-facing-interface-req] Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, S., and L. Xia, "Requirements for Client-Facing Interface to Security Controller", draft-kumar-i2nsf-client-facing- interface-req-02 (work in progress), October 2016. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, . Kumar, et al. Expires November 1, 2017 [Page 16] Internet-Draft Client Interface Information Model April 2017 Authors' Addresses Rakesh Kumar Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 US Email: rkkumar@juniper.net Anil Lohiya Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 US Email: alohiya@juniper.net Dave Qi Bloomberg 731 Lexington Avenue New York, NY 10022 US Email: DQI@bloomberg.net Nabil Bitar Nokia 755 Ravendale Drive Mountain View, CA 94043 US Email: nabil.bitar@nokia.com Senad Palislamovic Nokia 755 Ravendale Drive Mountain View, CA 94043 US Email: senad.palislamovic@nokia.com Kumar, et al. Expires November 1, 2017 [Page 17] Internet-Draft Client Interface Information Model April 2017 Liang Xia Huawei 101 Software Avenue Nanjing, Jiangsu 210012 China Email: Frank.Xialiang@huawei.com Kumar, et al. Expires November 1, 2017 [Page 18]