idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-07.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 216: '...he Policy object SHALL have following ...' RFC 2119 keyword, line 263: '... The rule object SHALL have the follow...' RFC 2119 keyword, line 294: '... Event object SHALL have following i...' RFC 2119 keyword, line 318: '... Group object SHALL have following i...' RFC 2119 keyword, line 337: '...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 17, 2018) is 2107 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-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-06 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 18, 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 17, 2018 16 Information Model for Consumer-Facing Interface to Security Controller 17 draft-kumar-i2nsf-client-facing-interface-im-07 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 18, 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 the Document . . . . . . . . . . . . . . 5 66 3. Information Model for Policy . . . . . . . . . . . . . . . . 5 67 3.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 7 68 3.1.1. Event-Map-Group . . . . . . . . . . . . . . . . . . . 8 69 3.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 8 70 3.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 10 71 4. Information Model for Multi-Tenancy . . . . . . . . . . . . . 10 72 4.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 11 73 4.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 12 74 4.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.5. Policy Management Authentication Method . . . . . . . . . 13 77 5. Information Model for Policy Endpoint Groups . . . . . . . . 14 78 5.1. Tag-Source . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 15 80 5.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 15 81 5.4. Application-Group . . . . . . . . . . . . . . . . . . . . 16 82 5.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 16 83 6. Information Model for Threat Prevention . . . . . . . . . . . 17 84 6.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 18 86 6.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 18 87 7. Information Model for Telemetry Data . . . . . . . . . . . . 18 88 7.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 19 89 7.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 19 90 7.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 20 91 8. Role-Based Acess Control (RBAC) . . . . . . . . . . . . . . . 21 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 95 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 96 13. Informative References . . . . . . . . . . . . . . . . . . . 22 97 Appendix A. Changes from draft-kumar-i2nsf-client-facing- 98 interface-im-06 . . . . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. 127 Figure 1 shows a high-level abstraction of Consumer-Facing Interface. 128 A data model, which represents an implementation of the proposed 129 information model in a specific data representation language, will be 130 defined in a separate document. 132 +-----------------+ +-----------------+ 133 | | | | 134 | Consumer-Facing +------>+ Consumer Facing | 135 | Interface | | Interface | 136 |Information Model| | Data Model | 137 +--------+--------+ +-----------------+ 138 ^ 139 | 140 | 141 +-------------+-------------+ 142 | | 143 | Policy-general | 144 | | 145 +-------------+-------------+ 146 ^ 147 | 148 +------------+-------------+------------+--------------+ 149 | | | | | 150 +-----+----+ +----+-----+ +----+----+ +----+----+ +------+-----+ 151 | | | | | | | | | | 152 | Multi | | Endpoint | | Policy | | Threat | | Telemetry | 153 | tenancy | | groups | | | | feed | | data | 154 +----------+ +----------+ +----+----+ +---------+ +------------+ 155 ^ 156 | 157 | 158 +------+------+ 159 | | 160 | Rule | 161 | | 162 +------+------+ 163 ^ 164 | 165 +----------------+----------------+ 166 | | | 167 +------+------+ +------+------+ +------+------+ 168 | | | | | | 169 | Event | | Condition | | Action | 170 | | | | | | 171 +-------------+ +-------------+ +-------------+ 173 Figure 1: Diagram for High-level Abstraction of Consumer-Facing 174 Interface 176 2. Conventions used in the Document 178 BSS: Business Support System 180 CLI: Command Line Interface 182 CMDB: Configuration Management Database 184 Controller: Security Controller or Management System 186 CRUD: Create, Retrieve, Update, Delete 188 FW: Firewall 190 GUI: Graphical User Interface 192 IDS: Intrusion Detection System 194 IPS: Intrusion Prevention System 196 LDAP: Lightweight Directory Access Protocol 198 NSF: Network Security Function, defined by 199 [I-D.ietf-i2nsf-terminology] 201 OSS: Operations Support System 203 RBAC: Role-Based Access Control 205 SIEM: Security Information and Event Management 207 URL: Universal Resource Locator 209 vNSF: NSF being instantiated on Virtual Machines 211 3. Information Model for Policy 213 A Policy object represents a mechanism to express a Security Policy 214 by Security Admin (i.e., I2NSF User) using Consumer-Facing Interface 215 toward Security Controller; the policy would be enforced on an NSF. 216 The Policy object SHALL have following information: 218 Name: This field identifies the name of this object. 220 Date: Date when this object was created or last modified. 222 Multi-Tenancy: The multi-tenant environment information in which 223 the policy is applied. The Rules in the Policy can refer 224 to sub-objects (e.g., domain, tenant, role, and user) of 225 it. It can be either a reference to a Multi-Tenancy object 226 defined in another place, or a concrete object. See 227 details in Section 4. 229 End-Group: This field contains a list of logical entities in the 230 business environment where a Security Policy is to be 231 applied. It can be referenced by the Condition objects in 232 a Rule, e.g., Source, Destination, Match, etc. It can be 233 either a reference to an End-Group object defined in other 234 place, or a concrete object. See details in Section 5. 236 Threat-Feed: This field represents threat feed such as Botnet 237 servers, GeoIP, and Malware signature. This information 238 can be referenced by the Rule Action object directly to 239 execute the threat mitigation. See details in Section 6. 241 Telemetry-Data: This field represents the telemetry collection 242 related information that the Rule Action object can refer 243 to about how to collect the interested telemetry 244 information, for example, what type of telemetry to 245 collect, where the telemetry source is, where to send the 246 telemetry information. See details in Section 7. 248 Rules: This field contains a list of rules. If the rule does not 249 have a user-defined precedence, then any conflict must be 250 manually resolved. 252 Owner: This field defines the owner of this policy. Only the 253 owner is authorized to modify the contents of the policy. 255 A policy is a container of Rules. In order to express a Rule, a Rule 256 must have complete information such as where and when a policy needs 257 to be applied. This is done by defining a set of managed objects and 258 relationship among them. A Policy Rule may be related segmentation, 259 threat mitigation or telemetry data collection from an NSF in the 260 network, which will be specified as the sub-model of the policy model 261 in the subsequent sections. 263 The rule object SHALL have the following information: 265 Name: This field identifies the name of this object. 267 Date: This field indicates the date when this object was created 268 or last modified. 270 Event: This field includes the information to determine whether 271 the Rule Condition can be evaluated or not. See details in 272 Section 3.1. 274 Condition: This field contains all the checking conditions to 275 apply to the objective traffic. See details in 276 Section 3.2. 278 Action: This field identifies the action taken when a rule is 279 matched. There is always an implicit action to drop 280 traffic if no rule is matched for a traffic type. See 281 details in Section 3.3. 283 Precedence: This field identifies the precedence assigned to this 284 rule by Security Admin. This is helpful in conflict 285 resolution when two or more rules match a given traffic 286 class. 288 3.1. Event Sub-Model 290 The Event Object contains information related to scheduling a Rule. 291 The Rule could be activated based on a time calendar or security 292 event including threat level changes. 294 Event object SHALL have following information: 296 Name: This field identifies the name of this object. 298 Date: This field indicates the date when this object was created 299 or last modified. 301 Event-Type: This field identifies whether the event of triggering 302 policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or 303 "EVENT-ENFORCED". 305 Time-Information: This field contains a time calendar such as 306 "BEGIN-TIME" and "END-TIME" for one time enforcement or 307 recurring time calendar for periodic enforcement. 309 Event-Map-Group: This field contains security events or threat 310 map in order to determine when a policy needs to be 311 activated. This is a reference to Event-Map-Group defined 312 later. 314 3.1.1. Event-Map-Group 316 This object represents an event map containing security events and 317 threat levels used for dynamic policy enforcement. The Event-Map- 318 Group object SHALL have following information: 320 Name: This field identifies the name of this object. 322 Date: This field indicates the date when this object was created 323 or last modified. 325 Security-Events: This contains a list of security events used for 326 purpose for Security Policy definition. 328 Threat-Map: This contains a list of threat levels used for 329 purpose for Security Policy definition. 331 3.2. Condition Sub-Model 333 This object represents Conditions that Security Admin wants to apply 334 the checking on the traffic in order to determine whether the set of 335 actions in the Rule can be executed or not. 337 The Condition object SHALL have following information: 339 Source: This field identifies the source of the traffic. This 340 could be a reference to either Policy-Endpoint-Group, 341 Threat-Feed or Custom-List as defined earlier. This could 342 be a special object "ALL" that matches all traffic. This 343 could also be Telemetry-Source for telemetry collection 344 policy. 346 Destination: This field identifies the destination of the 347 traffic. This could be a reference to either Policy- 348 Endpoint-Group, Threat-Feed or Custom-List as defined 349 earlier. This could be a special object "ALL" that matches 350 all traffic. This could also be Telemetry- Destination for 351 telemetry collection policy. 353 Match: This field identifies the match criteria used to evaluate 354 whether the specified action needs to be taken or not. 355 This could be either a Policy-Endpoint-Group identifying an 356 Application set or a set of traffic rules. 358 Match-Direction: This field identifies whether the match criteria 359 is to be evaluated for both directions or only one 360 direction of the traffic with a default of allowing the 361 other direction for stateful match conditions. This is 362 optional and by default a rule should apply to both 363 directions. 365 Exception: This field identifies the exception consideration when 366 a rule is evaluated for a given communication. This could 367 be a reference to "Policy-Endpoint-Group" object or set of 368 traffic matching criteria. 370 The condition object is made of condition clauses. Each condition 371 clause consists of three tuples; variable, operator and value. 373 The variable and value can be source and destination IP address, for 374 example, and they have logical operator in between to check whether 375 they match the condition criteria set by a security admin. For 376 Example: If condition A AND B is true: THEN execute actions ENDIF 377 where A denotes a destination address, and B denotes a blacklisted IP 378 address. The operator AND is the logical AND operation. 380 1..n 381 +----------------+ 382 | | 383 +------------>+ Policy rule | 384 | | | 385 1..n | +----------------+ 386 +--------+--------+ 387 | | 388 +Condition clause + 389 | | 390 +--------+--------+ 391 ^ ^ ^ 392 | | | 393 +--------------+ | +--------------+ 394 1..n | 1..n | 1..n | 395 +--------+-------+ +--------+--------+ +-------+-------+ 396 | | | | | | 397 | Variable | | Operator | | Value | 398 | | | | | | 399 +----------------+ +-----------------+ +---------------+ 401 Figure 2: Condition Clause Diagram 403 The semantics used in a condition clause is also used in the clauses 404 in the Event-submodel and Action sub-model. 406 3.3. Action Sub-Model 408 This object represents actions that Security Admin wants to perform 409 based on certain traffic class. 411 The Action object SHALL have following information: 413 Name: This field identifies the name of this object. 415 Date: This field indicates the date when this object was created 416 or last modified. 418 Primary-Action: This field identifies the action when a rule is 419 matched by an NSF. The action could be one of "PERMIT", 420 "DENY", "DROP-CONNECTION", "AUTHENTICATE-CONNECTION", 421 "MIRROR", "REDIRECT", "NETFLOW", "COUNT", "ENCRYPT", 422 "DECRYPT", "THROTTLE", "MARK", or "INSTANTIATE-NSF". 424 Secondary-Action: Security Admin can also specify additional 425 actions if a rule is matched. This could be one of "LOG", 426 "SYSLOG", or "SESSION-LOG". 428 4. Information Model for Multi-Tenancy 430 Multi-tenancy is an important aspect of any application that enables 431 multiple administrative domains in order to manage application 432 resources. An Enterprise organization may have multiple tenants or 433 departments such as Human Resources (HR), Finance, and Legal, with 434 each tenant having a need to manage their own Security Policies. In 435 a Service Provider, a tenant could represent a Customer that wants to 436 manage its own Security Policies. 438 There are multiple managed objects that constitute multi-tenancy 439 aspects. This section lists these objects and any relationship among 440 these objects. Below diagram shows an example of multi-tenancy in an 441 Enterprise domain. 443 +-------------------+ 444 (Multi-Tenancy) | Domain | 445 |(e.g., Enterprise) | 446 +---------+---------+ 447 ^ 448 | 449 +--------------------+--------------------+ 450 | | | 451 +--------+-------+ +---------+--------+ +--------+--------+ 452 | Department 1 | | Department 2 | | Department n | 453 +--------+-------+ +---------+--------+ +--------+--------+ 454 ^ ^ ^ 455 | | | 456 +--------+--------+ +-----------------+ +--------+--------+ 457 | Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n | 458 +--------+--------+ +--------+--------+ +--------+--------+ 459 ^ ^ ^ 460 | | | 461 +--------+--------+ +--------+--------+ +--------+--------+ 462 | Tenant 1..n | | Tenant 1..n | | Tenant 1..n | 463 +-----------------+ +-----------------+ +-----------------+ 465 Figure 3: Multi-tenancy Diagram 467 4.1. Policy-Domain 469 This object defines a boundary for the purpose of policy management 470 within a Security Controller. This may vary based on how the 471 Security Controller is deployed and hosted. For example, if an 472 Enterprise hosts a Security Controller in their network; the domain 473 in this case could just be the one that represents that Enterprise. 474 But if a Cloud Service Provider hosts managed services, then a domain 475 could represent a single customer of that Provider. Multi-tenancy 476 model should be able to work in all such environments. 478 The Policy-Domain object SHALL have following information: 480 Name: Name of the organization or customer representing this 481 domain. 483 Address: Address of the organization or customer. 485 Contact: Contact information of the organization or customer. 487 Date: Date when this account was created or last modified. 489 Authentication-Method: Authentication method to be used for this 490 domain. It should be a reference to a 'Policy-Management- 491 Authentication-Method' object. 493 4.2. Policy-Tenant 495 This object defines an entity within an organization. The entity 496 could be a department or business unit within an Enterprise 497 organization that would like to manage its own Policies due to 498 regulatory compliance or business reasons. 500 The Policy-Tenant object SHALL have following information: 502 Name: Name of the Department or Division within an organization. 504 Date: Date when this account was created or last modified. 506 Domain: This field identifies the domain to which this tenant 507 belongs. This should be a reference to a Policy-Domain 508 object. 510 4.3. Policy-Role 512 This object defines a set of permissions assigned to a user in an 513 organization that wants to manage its own Security Policies. It 514 provides a convenient way to assign policy users to a job function or 515 a set of permissions within the organization. 517 The Policy-Role object SHALL have the following information: 519 Name: This field identifies the name of the role. 521 Date: Date when this role was created or last modified. 523 Access-Profile: This field identifies the access profile for the 524 role. The profile grants or denies the permissions to 525 access Endpoint Groups for the purpose of policy management 526 or may restrict certain operations related to policy 527 managements. 529 4.4. Policy-User 531 This object represents a unique identity within an organization. The 532 identity authenticates with Security Controller using credentials 533 such as a password or token in order to perform policy management. A 534 user may be an individual, system, or application requiring access to 535 Security Controller. 537 The Policy-User object SHALL have the following information: 539 Name: Name of a user. 541 Date: Date when this user was created or last modified. 543 Password: User password for basic authentication. 545 Email: E-mail address of the user. 547 Scope-Type: This field identifies whether the user has domain- 548 wide or tenant-wide privileges. 550 Scope-Reference: This field should be a reference to either a 551 Policy-Domain or a Policy-Tenant object. 553 Role: This field should be a reference to a Policy-Role object 554 that defines the specific permissions. 556 4.5. Policy Management Authentication Method 558 This object represents authentication schemes supported by Security 559 Controller. 561 This Policy-Management-Authentication-Method object SHALL have the 562 following information: 564 Name: This field identifies name of this object. 566 Date: Date when this object was created or last modified. 568 Authentication-Method: This field identifies the authentication 569 methods. It could be a password-based, token-based, 570 certificate-based or single sign-on authentication. 572 Mutual-Authentication: This field indicates whether mutual 573 authentication is mandatory or not. 575 Token-Server: This field stores the information about server that 576 validates the token submitted as credentials. 578 Certificate-Server: This field stores the information about 579 server that validates certificates submitted as 580 credentials. 582 Single Sign-on-Server: This field stores the information about 583 server that validates user credentials. 585 5. Information Model for Policy Endpoint Groups 587 The Policy Endpoint Group is a very important part of building User- 588 construct based policies. Security Admin would create and use these 589 objects to represent a logical entity in their business environment, 590 where a Security Policy is to be applied. 592 There are multiple managed objects that constitute a Policy Endpoint 593 Group. This section lists these objects and relationship among these 594 objects. 596 +-------------------+ 597 | Endpoint Group | 598 +---------+---------+ 599 ^ 600 | 601 +------------+-------+-----+---------------+ 602 1..n | 1..n | 1..n | 1..n | 603 +-----+----+ +----+---+ +------+------+ +-----+----+ 604 | User | | Device | | Application | | Location | 605 +----------+ +--------+ +-------------+ +----------+ 607 Figure 4: Endpoint Group Diagram 609 5.1. Tag-Source 611 This object represents information source for tag. The tag in a 612 group must be mapped to its corresponding contents to enforce a 613 Security Policy. 615 Tag-Source object SHALL have the following information: 617 Name: This field identifies name of this object. 619 Date: Date when this object was created or last modified. 621 Tag-Type: This field identifies the Endpoint Group type. It can 622 be a User-Group, App-Group, Device-Group or Location-Group. 624 Tag-Source-Server: This field identifies information related to 625 the source of the tag such as IP address and UDP/TCP port 626 information. 628 Tag-Source-Application: This filed identifies the protocol, e.g., 629 LDAP, Active Directory, or CMDB used to communicate with a 630 server. 632 Tag-Source-Credentials: This field identifies the credential 633 information needed to access the server. 635 5.2. User-Group 637 This object represents a user group based on either tag or other 638 information. 640 The User-Group object SHALL have the following information: 642 Name: This field identifies the name of this object. 644 Date: Date when this object was created or last modified. 646 Group-Type: This field identifies whether the user group is based 647 on User-tag, User-name or IP-address. 649 Metadata-Server: This field should be a reference to a Metadata- 650 Source object. 652 Group-Member: This field is a list of User-tag, User-names or IP 653 addresses based on Group-Type. 655 Risk-Level: This field represents the risk level or importance of 656 the Endpoint to Security Admin for policy purpose; the 657 valid range may be 0 to 9. 659 5.3. Device-Group 661 This object represents a device group based on either tag or other 662 information. 664 The Device-Group object SHALL have the following information: 666 Name: This field identifies the name of this object. 668 Date: Date when this object was created or last modified. 670 Group-Type: This field identifies whether the device group is 671 based on Device-tag or Device-name or IP address. 673 Tag-Server: This field should be a reference to a Tag-Source 674 object. 676 Group-Member: This field is a list of Device-tag, Device-name or 677 IP address based on Group-Type. 679 Risk-Level: This field represents the risk level or importance of 680 the Endpoint to Security Admin for policy purpose; the 681 valid range may be 0 to 9. 683 5.4. Application-Group 685 This object represents an application group based on either tag or 686 other information. 688 The Application-Group object SHALL have the following information: 690 Name: This field identifies the name of this object. 692 Date: Date when this object was created or last modified. 694 Group-Type: This field identifies whether the application group 695 is based on App-tag or App-name, or IP address. 697 Tag-Server: This field should be a reference to a Tag-Source 698 object. 700 Group-Member: This field is a list of Application-tag 701 Application-name or IP address and port information based 702 on Group-Type. 704 Risk-Level: This field represents the risk level or importance of 705 the Endpoint to Security Admin for policy purpose; the 706 valid range may be 0 to 9. 708 5.5. Location-Group 710 This object represents a location group based on either tag or other 711 information. 713 The 'Location-Group' object SHALL have the following information: 715 Name: This field identifies the name of this object. 717 Date: Date when this object was created or last modified. 719 Group-Type: This field identifies whether the location group is 720 based on Location-tag, Location-name or IP address. 722 Tag-Server: This field should be a reference to a Tag-Source 723 object. 725 Group-Member: This field is a list of Location-tag, Location-name 726 or IP addresses based on Group-Type. 728 Risk Level: This field represents the risk level or importance of 729 the Endpoint to Security Admin for policy purpose; the 730 valid range may be 0 to 9. 732 6. Information Model for Threat Prevention 734 The threat prevention plays an important part in the overall security 735 posture by reducing the attack surfaces. This information could come 736 in the form of threat feeds such as Botnet and GeoIP feeds usually 737 from a third party or external service. 739 There are multiple managed objects that constitute this category. 740 This section lists these objects and relationship among these 741 objects. 743 +---------------------+ 744 | Threat Prevention | 745 +----------+----------+ 746 ^ 747 | 748 +---------------------+----------------------+ 749 1..n | 1..n | 1..n | 750 +----------+---------+ +---------+---------+ +----------+---------+ 751 | Threat feed | | Custom list | | Malware scan group | 752 +--------------------+ +-------------------+ +--------------------+ 754 Figure 5: Threat Prevention Diagram 756 6.1. Threat-Feed 758 This object represents a threat feed such as Botnet servers and 759 GeoIP. 761 The Threat-Feed object SHALL have the following information: 763 Name: This field identifies the name of this object. 765 Date: Date when this object was created or last modified. 767 Feed-Type: This field identifies whether a feed type is IP 768 address-based or URL-based. 770 Feed-Server: This field identifies the information about the feed 771 provider, it may be an external service or local server. 773 Feed-Priority: This field represents the feed priority level to 774 resolve conflict if there are multiple feed sources; the 775 valid range may be 0 to 9. 777 6.2. Custom-List 779 This object represents a custom list created for the purpose of 780 defining exception to threat feeds. An organization may want to 781 allow a certain exception to threat feeds obtained from a third party 783 The Custom-List object SHALL have the following information: 785 Name: This field identifies the name of this object. 787 Date: Date when this object was created or last modified. 789 List-Type: This field identifies whether the list type is IP 790 address-based or URL-based. 792 List-Property: This field identifies the attributes of the list 793 property, e.g., Blacklist or Whitelist. 795 List-Content: This field contains contents such as IP addresses 796 or URL names. 798 6.3. Malware-Scan-Group 800 This object represents information needed to detect malware. This 801 information could come from a local server or uploaded periodically 802 from a third party. 804 The Malware-Scan-Group object SHALL have the following information: 806 Name: This field identifies the name of this object. 808 Date: Date when this object was created or last modified. 810 Signature-Server: This field contains information about the 811 server from where signatures can be downloaded periodically 812 as updates become available. 814 File-Types: This field contains a list of file types needed to be 815 scanned for the virus. 817 Malware-Signatures: This field contains a list of malware 818 signatures or hash values. 820 7. Information Model for Telemetry Data 822 Telemetry provides System Admin with the visibility of the network 823 activities which can be tapped for further security analytics, e.g., 824 detecting potential vulnerabilities, malicious activities, etc. 826 7.1. Telemetry-Data 828 This object contains information collected for telemetry. 830 The Telemetry-Data object SHALL have the following information: 832 Name: This field identifies the name of this object. 834 Date: Date when this object was created or last modified. 836 Log-Data: This field identifies whether Log data need to be 837 collected. 839 Syslog-Data This field identifies whether Syslog data need to be 840 collected. 842 SNMP-Data: This field identifies whether SNMP traps and alarm 843 data need to be collected. 845 sFlow-Record: This field identifies whether sFlow records need to 846 be collected. 848 NetFlow-Record: This field identifies whether NetFlow record need 849 to be collected. 851 NSF-Stats: This field identifies whether statistics need to be 852 collected from an NSF. 854 7.2. Telemetry-Source 856 This object contains information related to telemetry source. The 857 source would be an NSF in the network. 859 The Telemetry-Source object SHALL have the following information: 861 Name: This field identifies the name of this object. 863 Date: Date when this object was created or last modified. 865 Source-Type: This field contains the type of the NSF telemetry 866 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 867 NSF", "PROXY-NSF or "OTHER-NSF". 869 NSF-Source: This field contains information such as IP address 870 and protocol (UDP or TCP) port number of the NSF providing 871 telemetry data. 873 NSF-Credentials: This field contains a username and a password 874 used to authenticate the NSF. 876 Collection-Interval: This field contains time in milliseconds 877 between each data collection. For example, a value of 878 5,000 means data is streamed to collector every 5 seconds. 879 Value of 0 means data streaming is event-based. 881 Collection-Method: This field contains a method of collection 882 whether it is PUSH-based or PULL-based. 884 Heartbeat-Interval: This field contains time in seconds when the 885 source must send telemetry heartbeat. 887 QoS-Marking: This field contains a DSCP value source marked on 888 its generated telemetry packets. 890 7.3. Telemetry-Destination 892 This object contains information related to telemetry destination. 893 The destination is usually a collector which is either a part of 894 Security Controller or external system such as SIEM. 896 The Telemetry-Destination object SHALL have the following 897 information: 899 Name: This field identifies the name of this object. 901 Date: Date when this object was created or last modified. 903 Collector-Source: This field contains the information such as IP 904 address and protocol (UDP or TCP) port number for the 905 collector's destination. 907 Collector-Credentials: This field contains a username and a 908 password provided by the collector. 910 Data-Encoding: This field contains the telemetry data encoding, 911 which could in the form of a schema. 913 Data-Transport: This field contains streaming telemetry data 914 protocols: whether it is gRPC, protocol buffer over UDP, 915 etc. 917 8. Role-Based Acess Control (RBAC) 919 Role-Based Access Control (RBAC) provides a powerful and centralized 920 control within a network. It is a policy neutral access control 921 mechanism defined around roles and privileges. The components of 922 RBAC, such as role-permissions, user-role and role-role 923 relationships, make it simple to perform user assignments. 925 +--------------+ 926 | | 927 | User 1 + (has many) 928 | |\ 929 +--------------+ \ +---------------+ +-------------+ 930 . \ | | (has many) | | 931 . --->+ List of roles +----------->+ Permissions | 932 +--------------+ / | | | | 933 | | / +---------------+ +-------------+ 934 | User n +/ 935 | | (has many) 936 +--------------+ 938 Figure 6: RBAC Diagram 940 As shown in Figure 6, a role represents a collection of permissions 941 (e.g., accessing a file server or other particular resources). A 942 role may be assigned to one or multiple users. Both roles and 943 permissions can be organized in a hirarchy. A role may consists of 944 other roles and permissions. 946 Following are the steps required to build RBAC. 948 1. Defining roles and permissions. 950 2. Establishing relations among roles and permissions. 952 3. Defining users. 954 4. Associating rules with roles and permissions. 956 5. assigning roles to users. 958 9. Security Considerations 960 An information model provides a mechanism to protect Consumer-Facing 961 Interface between System Admin (i.e., I2NSF User) and Security 962 Controller. One of the specified mechanism must be used to protect 963 an Enterprise network, data and all resources from external attacks. 964 This information model mandates that the interface must have proper 965 authentication and authorization with Role-Based Access Controls to 966 address the multi-tenancy requirement. The document does not mandate 967 that a particular mechanism should be used because a different 968 organization may have different needs based on their deployment. 970 10. IANA Considerations 972 This document requires no IANA actions. RFC Editor: Please remove 973 this section before publication. 975 11. Acknowledgments 977 This work was supported by Institute for Information & communications 978 Technology Promotion (IITP) grant funded by the Korea government 979 (MSIT) (No. R-20160222-002755, Cloud based Security Intelligence 980 Technology Development for the Customized Security Service 981 Provisioning). 983 12. Contributors 985 This document is the work of I2NSF working group, greatly benefiting 986 from inputs and suggestions by Kunal Modasiya, Prakash T. Sehsadri 987 and Srinivas Nimmagadda from Juniper Networks. The authors sincerely 988 appreciate their contributions. 990 The following are contributing authors of this document, who are 991 considered co-authors: 993 o Eunsoo Kim (Sungkyunkwan University) 995 o Seungjin Lee (Sungkyunkwan University) 997 o Hyoungshick Kim (Sungkyunkwan University) 999 13. Informative References 1001 [I-D.ietf-i2nsf-capability] 1002 Xia, L., Strassner, J., Basile, C., and D. Lopez, 1003 "Information Model of NSFs Capabilities", draft-ietf- 1004 i2nsf-capability-02 (work in progress), July 2018. 1006 [I-D.ietf-i2nsf-client-facing-interface-req] 1007 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 1008 S., and L. Xia, "Requirements for Client-Facing Interface 1009 to Security Controller", draft-ietf-i2nsf-client-facing- 1010 interface-req-05 (work in progress), May 2018. 1012 [I-D.ietf-i2nsf-terminology] 1013 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1014 Birkholz, "Interface to Network Security Functions (I2NSF) 1015 Terminology", draft-ietf-i2nsf-terminology-06 (work in 1016 progress), July 2018. 1018 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1019 Information Models and Data Models", RFC 3444, 1020 DOI 10.17487/RFC3444, January 2003, 1021 . 1023 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1024 and J. Jeong, "Interface to Network Security Functions 1025 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1026 DOI 10.17487/RFC8192, July 2017, 1027 . 1029 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1030 Kumar, "Framework for Interface to Network Security 1031 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1032 . 1034 Appendix A. Changes from draft-kumar-i2nsf-client-facing-interface- 1035 im-06 1037 The following changes have been made from draft-kumar-i2nsf-client- 1038 facing-interface-im-06: 1040 o In Section 1, Figure 1 is added to show a diagram for a high-level 1041 abstraction of Consumer-Facing Interface. 1043 Authors' Addresses 1045 Rakesh Kumar 1046 Juniper Networks 1047 1133 Innovation Way 1048 Sunnyvale, CA 94089 1049 US 1051 Email: rakeshkumarcloud@gmail.com 1052 Anil Lohiya 1053 Juniper Networks 1054 1133 Innovation Way 1055 Sunnyvale, CA 94089 1056 US 1058 Email: alohiya@juniper.net 1060 Dave Qi 1061 Bloomberg 1062 731 Lexington Avenue 1063 New York, NY 10022 1064 US 1066 Email: DQI@bloomberg.net 1068 Nabil Bitar 1069 Nokia 1070 755 Ravendale Drive 1071 Mountain View, CA 94043 1072 US 1074 Email: nabil.bitar@nokia.com 1076 Senad Palislamovic 1077 Nokia 1078 755 Ravendale Drive 1079 Mountain View, CA 94043 1080 US 1082 Email: senad.palislamovic@nokia.com 1084 Liang Xia 1085 Huawei 1086 101 Software Avenue 1087 Nanjing, Jiangsu 210012 1088 China 1090 Email: Frank.Xialiang@huawei.com 1091 Jaehoon Paul Jeong 1092 Department of Software 1093 Sungkyunkwan University 1094 2066 Seobu-Ro, Jangan-Gu 1095 Suwon, Gyeonggi-Do 16419 1096 Republic of Korea 1098 Phone: +82 31 299 4957 1099 Fax: +82 31 290 7996 1100 Email: pauljeong@skku.edu 1101 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php