idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-i2nsf-capability], [I-D.ietf-i2nsf-client-facing-interface-req]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 172: '...he Policy object SHALL have following ...' RFC 2119 keyword, line 219: '... The rule object SHALL have the follow...' RFC 2119 keyword, line 250: '... Event object SHALL have following i...' RFC 2119 keyword, line 274: '... Group object SHALL have following i...' RFC 2119 keyword, line 293: '...Condition object SHALL have following ...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-i2nsf-capability-01 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group R. Kumar 3 Internet-Draft A. Lohiya 4 Intended status: Informational Juniper Networks 5 Expires: January 3, 2019 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 J. Jeong 13 Sungkyunkwan University 14 July 2, 2018 16 Information Model for Consumer-Facing Interface to Security Controller 17 draft-kumar-i2nsf-client-facing-interface-im-06 19 Abstract 21 This document defines an information model for Consumer-Facing 22 interface to Security Controller based on the requirements identified 23 in [I-D.ietf-i2nsf-client-facing-interface-req]. The information 24 model defines various managed objects and relationship among these 25 objects needed to build the interface. The information model is 26 organized based on the "Event-Condition-Event" (ECA) policy model 27 defined by a capability information model for Interface to Network 28 Security Functions (I2NSF) [I-D.ietf-i2nsf-capability]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 3, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 66 3. Information Model for Policy . . . . . . . . . . . . . . . . 4 67 3.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 6 68 3.1.1. Event-Map-Group . . . . . . . . . . . . . . . . . . . 6 69 3.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 7 70 3.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 8 71 4. Information Model for Multi Tenancy . . . . . . . . . . . . . 9 72 4.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 10 74 4.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.5. Policy-Management-Authentication-Method . . . . . . . . . 11 77 5. Information Model for Policy Endpoint Groups . . . . . . . . 12 78 5.1. Tag-Source . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 14 81 5.4. Application-Group . . . . . . . . . . . . . . . . . . . . 14 82 5.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 15 83 6. Information Model for Threat Prevention . . . . . . . . . . . 15 84 6.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 16 86 6.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 17 87 7. Information Model for Telemetry Data . . . . . . . . . . . . 17 88 7.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 17 89 7.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 18 90 7.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 19 91 8. Role-Based Acess Control (RBAC) . . . . . . . . . . . . . . . 19 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 96 13. Informative References . . . . . . . . . . . . . . . . . . . 21 97 Appendix A. Changes from draft-kumar-i2nsf-client-facing- 98 interface-im-05 . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 Interface to Network Security Functions (I2NSF) defines a Consumer- 104 Facing Interface to deliver high-level security policies to Security 105 Controller [RFC8192][RFC8329] for securiy enforcement in Network 106 Security Functions (NSFs). 108 The Consumer-Facing interface would be built using a set of objects, 109 with each object capturing a unique set of information from Security 110 Admin (i.e., I2NSF User [RFC8329]) needed to express a Security 111 Policy. An object may have relationship with various other objects 112 to express a complete set of requirement. An information model 113 captures the managed objects and relationship among these objects. 114 The information model proposed in this document is in accordance with 115 interface requirements as defined in 116 [I-D.ietf-i2nsf-client-facing-interface-req]. 118 An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as 119 the basic model for both the NSF-Facing interface and Consumer-Facing 120 interface security policy model of this document. The information 121 model proposed in this document is structured in accordance with the 122 "Event-Condition-Event" (ECA) policy model. 124 [RFC3444] explains differences between an information and data model. 125 This document use the guidelines in [RFC3444] to define an 126 information model for Consumer-Facing interface in this document. A 127 data model, which represents an implementation of the proposed 128 information model in a specific data representation language, will be 129 defined in a separate document. 131 Figure 1: High-level-abstraction of Consumer-Facing Interface 133 2. Conventions Used in this Document 135 BSS: Business Support System 137 CLI: Command Line Interface 139 CMDB: Configuration Management Database 140 Controller: Security Controller or Management System 142 CRUD: Create, Retrieve, Update, Delete 144 FW: Firewall 146 GUI: Graphical User Interface 148 IDS: Intrusion Detection System 150 IPS: Intrusion Prevention System 152 LDAP: Lightweight Directory Access Protocol 154 NSF: Network Security Function, defined by 155 [I-D.ietf-i2nsf-terminology] 157 OSS: Operations Support System 159 RBAC: Role-Based Access Control 161 SIEM: Security Information and Event Management 163 URL: Universal Resource Locator 165 vNSF: NSF being instantiated on Virtual Machines 167 3. Information Model for Policy 169 A Policy object represents a mechanism to express a Security Policy 170 by Security Admin (i.e., I2NSF User) using Consumer-Facing interface 171 toward Security Controller; the policy would be enforced on an NSF. 172 The Policy object SHALL have following information: 174 Name: This field identifies the name of this object. 176 Date: Date when this object was created or last modified. 178 Multi-Tenancy: The multi-tenant environment information in which 179 the policy is applied. The Rules in the Policy can refer 180 to sub-objects (e.g., domain, tenant, role, and user) of 181 it. It can be either a reference to a Multi-Tenancy object 182 defined in another place, or a concrete object. See 183 details in Section 4. 185 End-Group: This field contains a list of logical entities in the 186 business environment where a Security Policy is to be 187 applied. It can be referenced by the Condition objects in 188 a Rule, e.g., Source, Destination, Match, etc. It can be 189 either a reference to an End-Group object defined in other 190 place, or a concrete object. See details in Section 5. 192 Threat-Feed: This field represents threat feed such as Botnet 193 servers, GeoIP, and Malware signature. This information 194 can be referenced by the Rule Action object directly to 195 execute the threat mitigation. See details in Section 6. 197 Telemetry-Data: This field represents the telemetry collection 198 related information that the Rule Action object can refer 199 to about how to collect the interested telemetry 200 information, for example, what type of telemetry to 201 collect, where the telemetry source is, where to send the 202 telemetry information. See details in Section 7. 204 Rules: This field contains a list of rules. If the rule does not 205 have a user-defined precedence, then any conflict must be 206 manually resolved. 208 Owner: This field defines the owner of this policy. Only the 209 owner is authorized to modify the contents of the policy. 211 A policy is a container of Rules. In order to express a Rule, a Rule 212 must have complete information such as where and when a policy needs 213 to be applied. This is done by defining a set of managed objects and 214 relationship among them. A Policy Rule may be related segmentation, 215 threat mitigation or telemetry data collection from an NSF in the 216 network, which will be specified as the sub-model of the policy model 217 in the subsequent sections. 219 The rule object SHALL have the following information: 221 Name: This field identifies the name of this object. 223 Date: This field indicates the date when this object was created 224 or last modified. 226 Event: This field includes the information to determine whether 227 the Rule Condition can be evaluated or not. See details in 228 Section 3.1. 230 Condition: This field contains all the checking conditions to 231 apply to the objective traffic. See details in 232 Section 3.2. 234 Action: This field identifies the action taken when a rule is 235 matched. There is always an implicit action to drop 236 traffic if no rule is matched for a traffic type. See 237 details in Section 3.3. 239 Precedence: This field identifies the precedence assigned to this 240 rule by Security Admin. This is helpful in conflict 241 resolution when two or more rules match a given traffic 242 class. 244 3.1. Event Sub-Model 246 The Event Object contains information related to scheduling a Rule. 247 The Rule could be activated based on a time calendar or security 248 event including threat level changes. 250 Event object SHALL have following information: 252 Name: This field identifies the name of this object. 254 Date: This field indicates the date when this object was created 255 or last modified. 257 Event-Type: This field identifies whether the event of triggering 258 policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or 259 "EVENT-ENFORCED". 261 Time-Information: This field contains a time calendar such as 262 "BEGIN-TIME" and "END-TIME" for one time enforcement or 263 recurring time calendar for periodic enforcement. 265 Event-Map-Group: This field contains security events or threat 266 map in order to determine when a policy needs to be 267 activated. This is a reference to Event-Map-Group defined 268 later. 270 3.1.1. Event-Map-Group 272 This object represents an event map containing security events and 273 threat levels used for dynamic policy enforcement. The Event-Map- 274 Group object SHALL have following information: 276 Name: This field identifies the name of this object. 278 Date: This field indicates the date when this object was created 279 or last modified. 281 Security-Events: This contains a list of security events used for 282 purpose for Security Policy definition. 284 Threat-Map: This contains a list of threat levels used for 285 purpose for Security Policy definition. 287 3.2. Condition Sub-Model 289 This object represents Conditions that Security Admin wants to apply 290 the checking on the traffic in order to determine whether the set of 291 actions in the Rule can be executed or not. 293 The Condition object SHALL have following information: 295 Source: This field identifies the source of the traffic. This 296 could be a reference to either Policy-Endpoint-Group, 297 Threat-Feed or Custom-List as defined earlier. This could 298 be a special object "ALL" that matches all traffic. This 299 could also be Telemetry-Source for telemetry collection 300 policy. 302 Destination: This field identifies the destination of the 303 traffic. This could be a reference to either Policy- 304 Endpoint-Group, Threat-Feed or Custom-List as defined 305 earlier. This could be a special object "ALL" that matches 306 all traffic. This could also be Telemetry- Destination for 307 telemetry collection policy. 309 Match: This field identifies the match criteria used to evaluate 310 whether the specified action needs to be taken or not. 311 This could be either a Policy-Endpoint-Group identifying an 312 Application set or a set of traffic rules. 314 Match-Direction: This field identifies whether the match criteria 315 is to be evaluated for both directions or only one 316 direction of the traffic with a default of allowing the 317 other direction for stateful match conditions. This is 318 optional and by default a rule should apply to both 319 directions. 321 Exception: This field identifies the exception consideration when 322 a rule is evaluated for a given communication. This could 323 be a reference to "Policy-Endpoint-Group" object or set of 324 traffic matching criteria. 326 The condition object is made of condition clauses. Each condition 327 clause consists of three tuples; variable, operator and value. 329 The variable and value can be source and destination IP address, for 330 example, and they have logical operator in between to check whether 331 they match the condition criteria set by a security admin. For 332 Example: If condition A AND B is true: THEN execute actions ENDIF 333 where A denotes a destination address, and B denotes a blacklisted IP 334 address. The operator AND is the logical AND operation. 336 1..n 337 +----------------+ 338 | | 339 +------------>+ Policy rule | 340 | | | 341 1..n | +----------------+ 342 +--------+--------+ 343 | | 344 +---------+Condition clause +---------+ 345 | | | | 346 | +--------+--------+ | 347 | ^ | 348 | | | 349 1..n | 1..n | 1..n | 350 +--------+-------+ +--------+--------+ +-------+-------+ 351 | | | | | | 352 | Variable | | Operator | | Value | 353 | | | | | | 354 +----------------+ +-----------------+ +---------------+ 356 Figure 2: Condition-clause Diagram 358 The semantics used in a condition clause is also used in the clauses 359 in the Event-submodel and Action sub-model. 361 3.3. Action Sub-Model 363 This object represents actions that Security Admin wants to perform 364 based on certain traffic class. 366 The Action object SHALL have following information: 368 Name: This field identifies the name of this object. 370 Date: This field indicates the date when this object was created 371 or last modified. 373 Primary-Action: This field identifies the action when a rule is 374 matched by an NSF. The action could be one of "PERMIT", 375 "DENY", "DROP-CONNECTION", "AUTHENTICATE-CONNECTION", 376 "MIRROR", "REDIRECT", "NETFLOW", "COUNT", "ENCRYPT", 377 "DECRYPT", "THROTTLE", "MARK", or "INSTANTIATE-NSF". 379 Secondary-Action: Security Admin can also specify additional 380 actions if a rule is matched. This could be one of "LOG", 381 "SYSLOG", or "SESSION-LOG". 383 4. Information Model for Multi Tenancy 385 Multi-tenancy is an important aspect of any application that enables 386 multiple administrative domains in order to manage application 387 resources. An Enterprise organization may have multiple tenants or 388 departments such as Human Resources (HR), Finance, and Legal, with 389 each tenant having a need to manage their own Security Policies. In 390 a Service Provider, a tenant could represent a Customer that wants to 391 manage its own Security Policies. 393 There are multiple managed objects that constitute multi-tenancy 394 aspects. This section lists these objects and any relationship among 395 these objects. Below diagram shows an example of multi-tenancy in an 396 Enterprise domain. 398 +-------------------+ 399 (Multi-Tenancy) | Domain | 400 | (e.g. Enterprise) | 401 +---------+---------+ 402 ^ 403 | 404 +--------------------+--------------------+ 405 | | | 406 +--------+-------+ +---------+--------+ +--------+--------+ 407 | Department 1 | | Department 2 | | Department n | 408 +--------+-------+ +---------+--------+ +--------+--------+ 409 ^ ^ ^ 410 | | | 411 +--------+--------+ +-----------------+ +--------+--------+ 412 | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | 413 +--------+--------+ +--------+--------+ +--------+--------+ 414 ^ ^ ^ 415 | | | 416 +--------+--------+ +--------+--------+ +--------+--------+ 417 | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | 418 +-----------------+ +-----------------+ +-----------------+ 420 Figure 3: Diagram for Multi-tenancy 422 4.1. Policy-Domain 424 This object defines a boundary for the purpose of policy management 425 within a Security Controller. This may vary based on how the 426 Security Controller is deployed and hosted. For example, if an 427 Enterprise hosts a Security Controller in their network; the domain 428 in this case could just be the one that represents that Enterprise. 429 But if a Cloud Service Provider hosts managed services, then a domain 430 could represent a single customer of that Provider. Multi-tenancy 431 model should be able to work in all such environments. 433 The Policy-Domain object SHALL have following information: 435 Name: Name of the organization or customer representing this 436 domain. 438 Address: Address of the organization or customer. 440 Contact: Contact information of the organization or customer. 442 Date: Date when this account was created or last modified. 444 Authentication-Method: Authentication method to be used for this 445 domain. It should be a reference to a 'Policy-Management- 446 Authentication-Method' object. 448 4.2. Policy-Tenant 450 This object defines an entity within an organization. The entity 451 could be a department or business unit within an Enterprise 452 organization that would like to manage its own Policies due to 453 regulatory compliance or business reasons. 455 The Policy-Tenant object SHALL have following information: 457 Name: Name of the Department or Division within an organization. 459 Date: Date when this account was created or last modified. 461 Domain: This field identifies the domain to which this tenant 462 belongs. This should be a reference to a Policy-Domain 463 object. 465 4.3. Policy-Role 467 This object defines a set of permissions assigned to a user in an 468 organization that wants to manage its own Security Policies. It 469 provides a convenient way to assign policy users to a job function or 470 a set of permissions within the organization. 472 The Policy-Role object SHALL have the following information: 474 Name: This field identifies the name of the role. 476 Date: Date when this role was created or last modified. 478 Access-Profile: This field identifies the access profile for the 479 role. The profile grants or denies the permissions to 480 access Endpoint Groups for the purpose of policy management 481 or may restrict certain operations related to policy 482 managements. 484 4.4. Policy-User 486 This object represents a unique identity within an organization. The 487 identity authenticates with Security Controller using credentials 488 such as a password or token in order to perform policy management. A 489 user may be an individual, system, or application requiring access to 490 Security Controller. 492 The Policy-User object SHALL have the following information: 494 Name: Name of a user. 496 Date: Date when this user was created or last modified. 498 Password: User password for basic authentication. 500 Email: E-mail address of the user. 502 Scope-Type: This field identifies whether the user has domain- 503 wide or tenant-wide privileges. 505 Scope-Reference: This field should be a reference to either a 506 Policy-Domain or a Policy-Tenant object. 508 Role: This field should be a reference to a Policy-Role object 509 that defines the specific permissions. 511 4.5. Policy-Management-Authentication-Method 513 This object represents authentication schemes supported by Security 514 Controller. 516 This Policy-Management-Authentication-Method object SHALL have the 517 following information: 519 Name: This field identifies name of this object. 521 Date: Date when this object was created or last modified. 523 Authentication-Method: This field identifies the authentication 524 methods. It could be a password-based, token-based, 525 certificate-based or single sign-on authentication. 527 Mutual-Authentication: This field indicates whether mutual 528 authentication is mandatory or not. 530 Token-Server: This field stores the information about server that 531 validates the token submitted as credentials. 533 Certificate-Server: This field stores the information about 534 server that validates certificates submitted as 535 credentials. 537 Single Sign-on-Server: This field stores the information about 538 server that validates user credentials. 540 5. Information Model for Policy Endpoint Groups 542 The Policy Endpoint Group is a very important part of building User- 543 construct based policies. Security Admin would create and use these 544 objects to represent a logical entity in their business environment, 545 where a Security Policy is to be applied. 547 There are multiple managed objects that constitute a Policy Endpoint 548 Group. This section lists these objects and relationship among these 549 objects. 551 +------------------+ 552 | End-point groups | 553 +--------+---------+ 554 ^ 555 | 556 +------------+-------+-----+---------------+ 557 1..n | 1..n | 1..n | 1..n | 558 +-----+----+ +----+---+ +------+------+ +-----+----+ 559 | User | | Device | | Application | | Location | 560 +----------+ +--------+ +-------------+ +----------+ 562 Figure 4: Endpoint 564 5.1. Tag-Source 566 This object represents information source for tag. The tag in a 567 group must be mapped to its corresponding contents to enforce a 568 Security Policy. 570 Tag-Source object SHALL have the following information: 572 Name: This field identifies name of this object. 574 Date: Date when this object was created or last modified. 576 Tag-Type: This field identifies the Endpoint Group type. It can 577 be a User-Group, App-Group, Device-Group or Location-Group. 579 Tag-Source-Server: This field identifies information related to 580 the source of the tag such as IP address and UDP/TCP port 581 information. 583 Tag-Source-Application: This filed identifies the protocol, e.g., 584 LDAP, Active Directory, or CMDB used to communicate with a 585 server. 587 Tag-Source-Credentials: This field identifies the credential 588 information needed to access the server. 590 5.2. User-Group 592 This object represents a user group based on either tag or other 593 information. 595 The User-Group object SHALL have the following information: 597 Name: This field identifies the name of this object. 599 Date: Date when this object was created or last modified. 601 Group-Type: This field identifies whether the user group is based 602 on User-tag, User-name or IP-address. 604 Metadata-Server: This field should be a reference to a Metadata- 605 Source object. 607 Group-Member: This field is a list of User-tag, User-names or IP 608 addresses based on Group-Type. 610 Risk-Level: This field represents the risk level or importance of 611 the Endpoint to Security Admin for policy purpose; the 612 valid range may be 0 to 9. 614 5.3. Device-Group 616 This object represents a device group based on either tag or other 617 information. 619 The Device-Group object SHALL have the following information: 621 Name: This field identifies the name of this object. 623 Date: Date when this object was created or last modified. 625 Group-Type: This field identifies whether the device group is 626 based on Device-tag or Device-name or IP address. 628 Tag-Server: This field should be a reference to a Tag-Source 629 object. 631 Group-Member: This field is a list of Device-tag, Device-name or 632 IP address based on Group-Type. 634 Risk-Level: This field represents the risk level or importance of 635 the Endpoint to Security Admin for policy purpose; the 636 valid range may be 0 to 9. 638 5.4. Application-Group 640 This object represents an application group based on either tag or 641 other information. 643 The Application-Group object SHALL have the following information: 645 Name: This field identifies the name of this object. 647 Date: Date when this object was created or last modified. 649 Group-Type: This field identifies whether the application group 650 is based on App-tag or App-name, or IP address. 652 Tag-Server: This field should be a reference to a Tag-Source 653 object. 655 Group-Member: This field is a list of Application-tag 656 Application-name or IP address and port information based 657 on Group-Type. 659 Risk-Level: This field represents the risk level or importance of 660 the Endpoint to Security Admin for policy purpose; the 661 valid range may be 0 to 9. 663 5.5. Location-Group 665 This object represents a location group based on either tag or other 666 information. 668 The 'Location-Group' object SHALL have the following information: 670 Name: This field identifies the name of this object. 672 Date: Date when this object was created or last modified. 674 Group-Type: This field identifies whether the location group is 675 based on Location-tag, Location-name or IP address. 677 Tag-Server: This field should be a reference to a Tag-Source 678 object. 680 Group-Member: This field is a list of Location-tag, Location-name 681 or IP addresses based on Group-Type. 683 Risk Level: This field represents the risk level or importance of 684 the Endpoint to Security Admin for policy purpose; the 685 valid range may be 0 to 9. 687 6. Information Model for Threat Prevention 689 The threat prevention plays an important part in the overall security 690 posture by reducing the attack surfaces. This information could come 691 in the form of threat feeds such as Botnet and GeoIP feeds usually 692 from a third party or external service. 694 There are multiple managed objects that constitute this category. 695 This section lists these objects and relationship among these 696 objects. 698 +---------------------+ 699 | Threat Prevention | 700 +----------+----------+ 701 ^ 702 | 703 +---------------------+----------------------+ 704 1..n | 1..n | 1..n | 705 +----------+---------+ +---------+---------+ +----------+---------+ 706 | Threat feed | | Custom list | | Malware scan group | 707 +--------------------+ +-------------------+ +--------------------+ 709 Figure 5: Threat Prevention Diagram 711 6.1. Threat-Feed 713 This object represents a threat feed such as Botnet servers and 714 GeoIP. 716 The Threat-Feed object SHALL have the following information: 718 Name: This field identifies the name of this object. 720 Date: Date when this object was created or last modified. 722 Feed-Type: This field identifies whether a feed type is IP 723 address-based or URL-based. 725 Feed-Server: This field identifies the information about the feed 726 provider, it may be an external service or local server. 728 Feed-Priority: This field represents the feed priority level to 729 resolve conflict if there are multiple feed sources; the 730 valid range may be 0 to 9. 732 6.2. Custom-List 734 This object represents a custom list created for the purpose of 735 defining exception to threat feeds. An organization may want to 736 allow a certain exception to threat feeds obtained from a third party 738 The Custom-List object SHALL have the following information: 740 Name: This field identifies the name of this object. 742 Date: Date when this object was created or last modified. 744 List-Type: This field identifies whether the list type is IP 745 address-based or URL-based. 747 List-Property: This field identifies the attributes of the list 748 property, e.g., Blacklist or Whitelist. 750 List-Content: This field contains contents such as IP addresses 751 or URL names. 753 6.3. Malware-Scan-Group 755 This object represents information needed to detect malware. This 756 information could come from a local server or uploaded periodically 757 from a third party. 759 The Malware-Scan-Group object SHALL have the following information: 761 Name: This field identifies the name of this object. 763 Date: Date when this object was created or last modified. 765 Signature-Server: This field contains information about the 766 server from where signatures can be downloaded periodically 767 as updates become available. 769 File-Types: This field contains a list of file types needed to be 770 scanned for the virus. 772 Malware-Signatures: This field contains a list of malware 773 signatures or hash values. 775 7. Information Model for Telemetry Data 777 Telemetry provides System Admin with the visibility of the network 778 activities which can be tapped for further security analytics, e.g., 779 detecting potential vulnerabilities, malicious activities, etc. 781 7.1. Telemetry-Data 783 This object contains information collected for telemetry. 785 The Telemetry-Data object SHALL have the following information: 787 Name: This field identifies the name of this object. 789 Date: Date when this object was created or last modified. 791 Log-Data: This field identifies whether Log data need to be 792 collected. 794 Syslog-Data This field identifies whether Syslog data need to be 795 collected. 797 SNMP-Data: This field identifies whether SNMP traps and alarm 798 data need to be collected. 800 sFlow-Record: This field identifies whether sFlow records need to 801 be collected. 803 NetFlow-Record: This field identifies whether NetFlow record need 804 to be collected. 806 NSF-Stats: This field identifies whether statistics need to be 807 collected from an NSF. 809 7.2. Telemetry-Source 811 This object contains information related to telemetry source. The 812 source would be an NSF in the network. 814 The Telemetry-Source object SHALL have the following information: 816 Name: This field identifies the name of this object. 818 Date: Date when this object was created or last modified. 820 Source-Type: This field contains the type of the NSF telemetry 821 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 822 NSF", "PROXY-NSF or "OTHER-NSF". 824 NSF-Source: This field contains information such as IP address 825 and protocol (UDP or TCP) port number of the NSF providing 826 telemetry data. 828 NSF-Credentials: This field contains a username and a password 829 used to authenticate the NSF. 831 Collection-Interval: This field contains time in milliseconds 832 between each data collection. For example, a value of 833 5,000 means data is streamed to collector every 5 seconds. 834 Value of 0 means data streaming is event-based. 836 Collection-Method: This field contains a method of collection 837 whether it is PUSH-based or PULL-based. 839 Heartbeat-Interval: This field contains time in seconds when the 840 source must send telemetry heartbeat. 842 QoS-Marking: This field contains a DSCP value source marked on 843 its generated telemetry packets. 845 7.3. Telemetry-Destination 847 This object contains information related to telemetry destination. 848 The destination is usually a collector which is either a part of 849 Security Controller or external system such as SIEM. 851 The Telemetry-Destination object SHALL have the following 852 information: 854 Name: This field identifies the name of this object. 856 Date: Date when this object was created or last modified. 858 Collector-Source: This field contains the information such as IP 859 address and protocol (UDP or TCP) port number for the 860 collector's destination. 862 Collector-Credentials: This field contains a username and a 863 password provided by the collector. 865 Data-Encoding: This field contains the telemetry data encoding, 866 which could in the form of a schema. 868 Data-Transport: This field contains streaming telemetry data 869 protocols: whether it is gRPC, protocol buffer over UDP, 870 etc. 872 8. Role-Based Acess Control (RBAC) 874 Role-Based Access Control (RBAC) provides a powerful and centralized 875 control within a network. It is a policy neutral access control 876 mechanism defined around roles and privileges. The components of 877 RBAC, such as role-permissions, user-role and role-role 878 relationships, make it simple to perform user assignments. 880 +--------------+ 881 | | 882 | User, ID = 1 + (has many) 883 | |\ 884 +--------------+ \ +---------------+ +-------------+ 885 . \| | (has many) | | 886 . + List of roles +----------->+ Permissions | 887 +--------------+ /| | | | 888 | | / +---------------+ +-------------+ 889 |Group of users+/ 890 | | (has many) 891 +--------------+ 893 Figure 6: RBAC Diagram 895 As shown in figure 6, A role represents a collection of permissions 896 (e.g. accessing a file server or other particular resources). A role 897 may be assigned to one or multiple users. Both roles and permissions 898 can be organized in a hirarchy. A role may consists of other roles 899 and permissions. 901 Following are the steps required to build RBAC. 903 1. Defining roles and permissions. 905 2. Establishing relations among roles and permissions. 907 3. Defining users. 909 4. Associating rules with roles and permissions. 911 5. assigning roles to users. 913 9. Security Considerations 915 An information model provides a mechanism to protect Consumer-Facing 916 interface between System Admin (i.e., I2NSF User) and Security 917 Controller. One of the specified mechanism must be used to protect 918 an Enterprise network, data and all resources from external attacks. 919 This information model mandates that the interface must have proper 920 authentication and authorization with Role-Based Access Controls to 921 address the multi-tenancy requirement. The document does not mandate 922 that a particular mechanism should be used because a different 923 organization may have different needs based on their deployment. 925 10. IANA Considerations 927 This document requires no IANA actions. RFC Editor: Please remove 928 this section before publication. 930 11. Acknowledgments 932 This work was supported by Institute for Information & communications 933 Technology Promotion (IITP) grant funded by the Korea government 934 (MSIT) (No. R-20160222-002755, Cloud based Security Intelligence 935 Technology Development for the Customized Security Service 936 Provisioning). 938 12. Contributors 940 This document is the work of I2NSF working group, greatly benefiting 941 from inputs and suggestions by Kunal Modasiya, Prakash T. Sehsadri 942 and Srinivas Nimmagadda from Juniper Networks. The authors sincerely 943 appreciate their contributions. 945 The following are contributing authors of this document, who are 946 considered co-authors: 948 o Eunsoo Kim (Sungkyunkwan University) 950 o Hyoungshick Kim (Sungkyunkwan University) 952 13. Informative References 954 [I-D.ietf-i2nsf-capability] 955 Xia, L., Strassner, J., Basile, C., and D. Lopez, 956 "Information Model of NSFs Capabilities", draft-ietf- 957 i2nsf-capability-01 (work in progress), April 2018. 959 [I-D.ietf-i2nsf-client-facing-interface-req] 960 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 961 S., and L. Xia, "Requirements for Client-Facing Interface 962 to Security Controller", draft-ietf-i2nsf-client-facing- 963 interface-req-05 (work in progress), May 2018. 965 [I-D.ietf-i2nsf-terminology] 966 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 967 Birkholz, "Interface to Network Security Functions (I2NSF) 968 Terminology", draft-ietf-i2nsf-terminology-05 (work in 969 progress), January 2018. 971 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 972 Information Models and Data Models", RFC 3444, 973 DOI 10.17487/RFC3444, January 2003, 974 . 976 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 977 and J. Jeong, "Interface to Network Security Functions 978 (I2NSF): Problem Statement and Use Cases", RFC 8192, 979 DOI 10.17487/RFC8192, July 2017, 980 . 982 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 983 Kumar, "Framework for Interface to Network Security 984 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 985 . 987 Appendix A. Changes from draft-kumar-i2nsf-client-facing-interface- 988 im-05 990 The following changes have been made from draft-kumar-i2nsf-client- 991 facing-interface-im-05: 993 o In Section 3.2, the description and diagram of a condition clause 994 is added. 996 o In Section 4, a Multi-tenancy diagram is added. 998 o In Section 5, the diagram of a Endpoint group is added. 1000 o In Section 6, the diagram of a Threat prevention is added. 1002 o In Section 8, the description and diagram of RBAC is added. 1004 o References are updated. 1006 Authors' Addresses 1008 Rakesh Kumar 1009 Juniper Networks 1010 1133 Innovation Way 1011 Sunnyvale, CA 94089 1012 US 1014 Email: rakeshkumarcloud@gmail.com 1015 Anil Lohiya 1016 Juniper Networks 1017 1133 Innovation Way 1018 Sunnyvale, CA 94089 1019 US 1021 Email: alohiya@juniper.net 1023 Dave Qi 1024 Bloomberg 1025 731 Lexington Avenue 1026 New York, NY 10022 1027 US 1029 Email: DQI@bloomberg.net 1031 Nabil Bitar 1032 Nokia 1033 755 Ravendale Drive 1034 Mountain View, CA 94043 1035 US 1037 Email: nabil.bitar@nokia.com 1039 Senad Palislamovic 1040 Nokia 1041 755 Ravendale Drive 1042 Mountain View, CA 94043 1043 US 1045 Email: senad.palislamovic@nokia.com 1047 Liang Xia 1048 Huawei 1049 101 Software Avenue 1050 Nanjing, Jiangsu 210012 1051 China 1053 Email: Frank.Xialiang@huawei.com 1054 Jaehoon Paul Jeong 1055 Department of Software 1056 Sungkyunkwan University 1057 2066 Seobu-Ro, Jangan-Gu 1058 Suwon, Gyeonggi-Do 16419 1059 Republic of Korea 1061 Phone: +82 31 299 4957 1062 Fax: +82 31 290 7996 1063 Email: pauljeong@skku.edu 1064 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php