idnits 2.17.1 draft-zhang-i2nsf-info-model-monitoring-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 28, 2016) is 2766 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.xia-i2nsf-capability-interface-im' is defined on line 1090, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft Huawei 4 Intended status: Experimental Y. Wu 5 Expires: April 1, 2017 Aliababa Group 6 L. Xia 7 Huawei 8 R. Kumar 9 A. Lohiya 10 Juniper Networks 11 September 28, 2016 13 An Information Model for the Monitoring of Network Security Functions 14 (NSF) 15 draft-zhang-i2nsf-info-model-monitoring-02 17 Abstract 19 The Network Security Functions (NSF) Capability interface exists 20 between the Service Provider's management system (or Security 21 Controller) and the NSFs to enforce the rule provisioning and 22 monitoring on the NSFs in the functional implementation level.This 23 document focuses on the monitoring part of it and proposes the 24 information model for it. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 1, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 64 3. Use cases for NSF monitoring data . . . . . . . . . . . . . . 4 65 4. Classification of NSF monitoring data . . . . . . . . . . . . 4 66 5. Structure of NSF monitoring data . . . . . . . . . . . . . . 6 67 6. Exporting NSF monitoring data . . . . . . . . . . . . . . . . 6 68 7. Basic Information model for all monitoring data . . . . . . . 7 69 8. Extended Information model for structured monitoring data . . 8 70 8.1. System Alarm . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 8 72 8.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 9 74 8.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 9 75 8.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 9 76 8.2. System Events . . . . . . . . . . . . . . . . . . . . . . 10 77 8.2.1. Access Violation . . . . . . . . . . . . . . . . . . 10 78 8.2.2. Configuration Change . . . . . . . . . . . . . . . . 10 79 8.3. System Log . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.3.1. Access Logs . . . . . . . . . . . . . . . . . . . . . 10 81 8.3.2. Resource Utilization Logs . . . . . . . . . . . . . . 11 82 8.3.3. User Activity Logs . . . . . . . . . . . . . . . . . 11 83 8.4. System Counters . . . . . . . . . . . . . . . . . . . . . 12 84 8.4.1. Interface counters . . . . . . . . . . . . . . . . . 12 85 8.5. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 13 86 8.5.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 13 87 8.5.2. Session Table Event . . . . . . . . . . . . . . . . . 14 88 8.5.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 14 89 8.5.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 15 90 8.5.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 16 91 8.5.6. Web Attack Event . . . . . . . . . . . . . . . . . . 17 92 8.6. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 17 93 8.6.1. DDoS Logs . . . . . . . . . . . . . . . . . . . . . . 17 94 8.6.2. Virus Logs . . . . . . . . . . . . . . . . . . . . . 18 95 8.6.3. Intrusion Logs . . . . . . . . . . . . . . . . . . . 18 96 8.6.4. Botnet Logs . . . . . . . . . . . . . . . . . . . . . 19 97 8.6.5. DPI Logs . . . . . . . . . . . . . . . . . . . . . . 19 98 8.6.6. Vulnerabillity Scanning Logs . . . . . . . . . . . . 20 99 8.6.7. Web Attack Logs . . . . . . . . . . . . . . . . . . . 20 100 8.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 21 101 8.7.1. Firewall counters . . . . . . . . . . . . . . . . . . 21 102 8.7.2. Policy Hit Counters . . . . . . . . . . . . . . . . . 22 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 108 12.2. Informative References . . . . . . . . . . . . . . . . . 23 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 According to [I-D.ietf-i2nsf-framework], the interface provided by a 114 NSF (e.g., FW, IPS, Anti-DDOS, or Anti-Virus) to administrative 115 entities (e.g., NMS, security controller) for configuring security 116 function in the NSF and monitoring the NSF is referred to as a 117 'capability interface'. The monitoring part of the capability 118 interface is meant to monitor the NSF e.g. events, logs, alarms, 119 operational state of the NSF. The monitoring of the NSF plays a very 120 important role in the overall security framework if done in a timely 121 and comprehensive way. The event generated by a NSF could very well 122 be an early indication of malicious activity or anomalous behavior. 123 The operational state of an NSF could also be a potential sign of 124 denial of service attacks or window into signature of an attack. 125 This draft proposes a comprehensive NSF monitoring informational 126 model that provide visibility into NSFs. This document will not go 127 into the design details of capability interface. Instead, this draft 128 is focused on specifying the information that a NSF needs to provide 129 in the monitoring part of the capability interface, as well as its 130 information model. Besides, [I-D.draft-xia-i2nsf-capability- 131 interface-im] specifies the information model for the rule 132 provisioning part of the capability interface. 134 2. Terminology 136 2.1. Key Words 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2.2. Definition of Terms 144 This document uses the terms defined in [I-D.draft-ietf-i2nsf- 145 terminology]. 147 3. Use cases for NSF monitoring data 149 As mentioned earlier, monitoring plays a very critical role in the 150 overall security framework. The monitoring of the NSF provides very 151 valuable information to the security controller in maintaining the 152 provisioned security posture. Besides this, there are various other 153 reasons to monitor the NSFs as listed below: 155 o The security administrator could configure a policy that is 156 triggered on a specific event. The security controller would 157 monitor for the specified event and once it happens, it configures 158 additional security functions as per the policy. 160 o The events triggered by NSFs as a result of security policy 161 violation could be used by SIEM to detect any suspicious activity. 163 o The events and activity logs from NSFs could be used to build 164 advanced analytics such as behavior and predictive to improve the 165 security posture. 167 o The security controller could use events from the NSF for 168 achieving high availability. It could take corrective actions 169 such as restarting a failed NSF, horizontally scaling the NSF 170 etcetra. 172 o The events and activity logs from the NSF could aid in debugging 173 and root cause analysis of an operational issue. 175 o The activity logs from the NSF could be used to build historical 176 data for operational and business reasons. 178 4. Classification of NSF monitoring data 180 In order to maintain a strong security posture, it is not only 181 necessary to configure security policies on NSF but also requires 182 constantly monitoring NSFs for events and comprehensive logs. This 183 gives ability to security admins regarding what is happening in the 184 network in realtime. It is not possible to block all the internal 185 and external threats based on static security posture but requires a 186 very dynamic posture with constant visibility. This draft proposes a 187 set of monitoring data needed for this purpose as listed below: 189 o System Alarms: This represents a set related to operational state 190 of the NSF. For example, the NSF could generate an alarm if NSF 191 experience an operational issue such as link failure and system 192 component failure or performance degradation. The operator could 193 configure the NSF with certain threshold and when those thresholds 194 are crossed, NSF would generate an alarm. The alarms usually 195 require immediate attention from the operator otherwise network 196 may go into unknown state and potentially exposing security 197 vulnerabilities. The set should only be used for sending critical 198 information to avoid operator constantly combing through large 199 amount of information. 201 o System Events: This represents a set of operational and 202 informational data from the NSF. For example, the NSF could 203 generate an event when a policy violation occurs in the NSF or 204 configuration change results into some issue. This kind of 205 information may not require an immediate attention from the 206 security admin but may be useful for visibility and security 207 analytics. Some vendors combine events and alarm into one 208 category. 210 o System Logs: This represents information generated by NSF systems 211 such as access and authorization activity logs, configuration 212 change logs and any other logs generated by NSFs. These logs are 213 important for debugging, auditing and security analytics. 215 o System counters: This represents set of counters generated by NSF 216 such as network interface counters (packets, bytes), drop, error 217 counters etc. These counters are useful in debugging and 218 visibility into operational behavior of the NSF. 220 o NSF Events: This represents events generated by a NSF for a 221 specific functionality such as generating event when IPS detects 222 attack signatures. 224 o NSF Logs: This represents logs generated by a NSF for a specific 225 functionality e.g. NAC device generating logs when it 226 authenticate a user session and the associated authorization 227 assigned to that user. Another example would be when a stateful 228 firewall generates log for each state created in the NSF and any 229 operation assigned such as traffic shaping or marking. These logs 230 provide window into the control and data path activities of a NSF. 232 o NSF Counters: This represents counters kept by NSF for a specific 233 functionality e.g. policy hits etc. 235 5. Structure of NSF monitoring data 237 As explained in the above section, there is a wealth of data 238 available from the NSF that can be monitored. Some of this data 239 generated by NSF is structured such as alarm and other may be 240 unstructured or structure may be very specific to that NSF. This 241 draft proposes common information model that is valid for the 242 monitoring data and extended information model for structured data. 243 The following guidelines can be used to classify monitoring data as 244 structured or unstructured: 246 o System Alarms: This is structured data. The draft proposes an 247 extended information model for this. 249 o System Events: This is structured data. The draft proposes an 250 extended information model for this. 252 o System Logs: This is unstructured data. The draft proposes a 253 basic information model for this. 255 o System Counters: This is structured data. The draft proposes an 256 extended information model for this. 258 o NSF Events: This is structured and structured data. The draft 259 proposes an extended information model for this. 261 o NSF Logs: This may have structured and unstructured data. The 262 draft proposes an basic information model for this. 264 o NSF Counters: This is structured data. The draft proposes an 265 extended information model for this. 267 6. Exporting NSF monitoring data 269 As per the use cases of NSF monitoring data, the data need to be sent 270 to various consumers based on the needs and requirements. There are 271 multiple things to be considered for exporting this data to needed 272 parties as listed below: 274 o Pull-Push model: A set of data could be pushed by a NSF to the 275 needed party or pulled by the needed party from a NSF. A specific 276 data might need both the models at the same time if there are 277 multiple consumers with varying requirements. It really depends 278 upon the need and its usages to the consumer. In general, any 279 alarm is considered to be of great importance and must be sent 280 immediately for any meaningful action so it should be sent using 281 push model but logs are not as critical so could be pulled by the 282 consumer. The I2NSF does not mandate a specific scheme for each 283 data set, it is up to each implementation. 285 o Export frequency: The monitoring data could be sent immediately 286 upon generation by a NSF to interested parties or pushed 287 periodically. The frequency of exporting the data depends upon 288 its size and timely usefulness. It is out of the scope of I2NSF 289 and left to each NSF implementation. 291 o Authentication: There may be a need for authentication between 292 monitoring data producer (NSF) and consumer to ensure that 293 critical information does not fall into wrong hands. This may be 294 necessary if the NSF directly export data to the consumer outside 295 its admin boundary. The I2NSF does not mandate when and how 296 specific authentication must be done. 298 o Subscription method: In order for the consumer to pull the data 299 from NSF or for NSF to push the data to a consumer, there must be 300 a mechanism for consumer to subscribe to the NSF data it is 301 interested in. There are few open source method available and it 302 is up to each implementation to decide the right one. 304 o Data transfer mode: The data could be pushed by NSF using a 305 connection-less model that does require a persistent connection or 306 streamed over a persistent connection. It depends upon the 307 requirement of the consumer and the nature of data. A particular 308 set of data can use either or both the mode based on 309 implementation. 311 o Transport method: There are lot of transport mechanism such as IP, 312 UDP, TCP. There are also open source implementations for specific 313 set of data such as systems counter. The I2NSF does not mandate 314 any specific method for a given data set, it is up to each 315 implementation. 317 7. Basic Information model for all monitoring data 319 There is must be some general information with each message sent from 320 a NSF that helps consumer in identifying meta data with that message. 322 o message_version: Indicate the version of the data format and is a 323 two-digit decimal numeral starting from 01 325 o message_type: Alarm, periodical report, etc 327 o time_stamp: Indicate the time when the message is generated 329 o vendor_name: The name of the NSF vendor 330 o NSF_name: The name (or IP) of the device generatign the message 332 o NSF_type: Indicate the NSF type e.g., firewall, WAF, IPS 334 o NSF_version: The software version of the NSF 336 8. Extended Information model for structured monitoring data 338 This section covers the additional information associated with the 339 system messages. The extended information model is only for the 340 structured data such as alarm. Any unstructured data is specified 341 with basic information model only. 343 8.1. System Alarm 345 8.1.1. Memory Alarm 347 The following information should be included in a Memory Alarm: 349 o event_name: 'MEM_USAGE_ALARM' 351 o module_name: Indicate the NSF module responsible for generating 352 this alarm 354 o usage: specifies the amount of memory used 356 o threshold: The threshold triggering the alarm 358 o severity: The severity of the alarm such as critical, high, 359 medium, low 361 o message: 'The memory usage exceeded the threshold' 363 8.1.2. CPU Alarm 365 The following information should be included in a CPU Alarm: 367 o event_name: 'CPU_USAGE_ALARM' 369 o usage: Specifies the amount of CPU used 371 o threshold: The threshold triggering the event 373 o severity: The severity of the alarm such as critical, high, 374 medium, low 376 o message: 'The CPU usage exceeded the threshold' 378 8.1.3. Disk Alarm 380 The following information should be included in a Disk Alarm: 382 o event_name: 'DISK_USAGE_ALARM' 384 o usage: Specifies the amount of disk space used 386 o threshold: The threshold triggering the event 388 o severity: The severity of the alarm such as critical, high, 389 medium, low 391 o message: 'The disk usage exceeded the threshold' 393 8.1.4. Hardware Alarm 395 The following information should be included in a Hardware Alarm: 397 o event_name: 'HW_FAILURE_ALARM' 399 o component_name: Indicate the HW component responsible for 400 generating this alarm 402 o threshold: The threshold triggering the alarm 404 o severity: The severity of the alarm such as critical, high, 405 medium, low 407 o message: 'The HW component has failed or degraded' 409 8.1.5. Interface Alarm 411 The following information should be included in a Interface Alarm: 413 o event_name: 'IFNET_STATE_ALARM' 415 o interface_Name: The name of interface 417 o interface_state: 'UP', 'DOWN', 'CONGESTED' 419 o threshold: The threshold triggering the event 421 o severity: The severity of the alarm such as critical, high, 422 medium, low 424 o message: 'Current interface state' 426 8.2. System Events 428 8.2.1. Access Violation 430 The following information should be included in this event: 432 o event_name: 'ACCESS_DENIED' 434 o user: Name of a user 436 o group: Group to which a user belongs 438 o login_ip_address: Login IP address of a user 440 o authentication_mode: User authentication mode. e.g., Local 441 Authentication, Third-Party Server Authentication, Authentication 442 Exemption, SSO Authentication 444 o message: 'access denied' 446 8.2.2. Configuration Change 448 The following information should be included in this event: 450 o event_name: 'CONFIG_CHANGE' 452 o user: Name of a user 454 o group: Group to which a user belongs 456 o login_ip_address: Login IP address of a user 458 o authentication_mode: User authentication mode. e.g., Local 459 Authentication, Third-Party Server Authentication, Authentication 460 Exemption, SSO Authentication 462 o message: 'Configuration modified' 464 8.3. System Log 466 8.3.1. Access Logs 468 Access logs record administrators' login, logout, and operations on 469 the device. By analyzing them, security vulnerabilities can be 470 identified. The following information should be included in 471 operation report: 473 o Administrator: Administrator that operates on the device 474 o login_ip_address: IP address used by an administrator to log in 476 o login_mode: Specifies the administrator logs in mode e.g. root, 477 user 479 o operation_type: The operation type that the administrator execute, 480 e.g., login, logout, configuration, etc 482 o result: Command execution result 484 o content: Operation performed by an administrator after login. 486 8.3.2. Resource Utilization Logs 488 Running reports record the device system's running status, which is 489 useful for device monitoring. The following information should be 490 included in running report: 492 o system_status: The current system's running status 494 o CPU_usage: Specifies the CPU usage 496 o memory_usage: Specifies the memory usage 498 o disk_usage: Specifies the disk usage 500 o disk_left: Specifies the available disk space left 502 o session_number: Specifies total concurrent sessions 504 o process_number: Specifies total number of system processes 506 o in_traffic_rate: The total inbound traffic rate in pps 508 o out_traffic_rate: The total outbound traffic rate in pps 510 o in_traffic_speed: The total inbound traffic speed in bps 512 o out_traffic_speed: The total outbound traffic speed in bps 514 8.3.3. User Activity Logs 516 User activity logs provide visibility into users' online records 517 (such as login time, online/lockout duration, and login IP addresses) 518 and the actions users perform. User activity reports are helpful to 519 identify exceptions during user login and network access activities. 521 o user: Name of a user 522 o group: Group to which a user belongs 524 o login_ip_address: Login IP address of a user 526 o authentication_mode: User authentication mode. e.g., Local 527 Authentication, Third-Party Server Authentication, Authentication 528 Exemption, SSO Authentication 530 o access_mode: User access mode. e.g., PPP, SVN, LOCAL 532 o online_duration: Online duration 534 o lockout_duration: Lockout duration 536 o type: User activities. e.g., Successful User Login, Failed Login 537 attempts, User Logout, Successful User Password Change, Failed 538 User Password Change, User Lockout, User Unlocking, Unknown 540 o cause: Cause of a failed user activity 542 8.4. System Counters 544 8.4.1. Interface counters 546 Interface counters provide visibility into traffic into and out of 547 NSF, bandwidth usage. 549 o interface_name: Network interface name configured in NSF 551 o in_total_traffic_pkts: Total inbound packets 553 o out_total_traffic_pkts: Total outbound packets 555 o in_total_traffic_bytes: Total inbound bytes 557 o out_total_traffic_bytes: Total outbound bytes 559 o in_drop_traffic_pkts: Total inbound drop packets 561 o out_drop_traffic_pkts: Total outbound drop packets 563 o in_drop_traffic_bytes: Total inbound drop bytes 565 o out_drop_traffic_bytes: Total outbound drop bytes 567 o in_traffic_ave_rate: Inbound traffic average rate in pps 569 o in_traffic_peak_rate: Inbound traffic peak rate in pps 570 o in_traffic_ave_speed: Inbound traffic average speed in bps 572 o in_traffic_peak_speed: Inbound traffic peak speed in bps 574 o out_traffic_ave_rate: Outbound traffic average rate in pps 576 o out_traffic_peak_rate: Outbound traffic peak rate in pps 578 o out_traffic_ave_speed: Outbound traffic average speed in bps 580 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 582 8.5. NSF Events 584 8.5.1. DDoS Event 586 The following information should be included in a DDoS Event: 588 o event_name: 'SEC_EVENT_DDoS' 590 o sub_attack_type: Any one of Syn flood, ACK flood, SYN-ACK flood, 591 FIN/RST flood, TCP Connection flood, UDP flood, Icmp flood, HTTPS 592 flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 593 and etc. 595 o dst_ip: The IP address of a victum under attack 597 o dst_port: The port numbers that the attrack traffic aims at. 599 o start_time: The time stamp indicating when the attack started 601 o end_time: The time stamp indicating when the attack ended. If the 602 attack is still undergoing when sending out the alarm, this field 603 can be empty. 605 o attack_rate: The PPS of attack traffic 607 o attack_speed: the bps of attack traffic 609 o rule_id: The ID of the rule being triggered 611 o rule_name: The name of the rule being triggered 613 o profile: Security profile that traffic matches. 615 8.5.2. Session Table Event 617 The following information should be included in a Session 618 Table Event: 620 o event_name: 'SESSION_USAGE_HIGH' 622 o current: The number of concurrent sessions 624 o max: The maximum number of sessions that the session table can 625 support 627 o threshold: The threshold triggering the event 629 o message: 'The number of session table exceeded the threshold' 631 8.5.3. Virus Event 633 The following information should be included in a Virus Event: 635 o event_Name: 'SEC_EVENT_VIRUS' 637 o virus_type: Type of the virus, e.g., trojan, worm, macro Virus 638 type 640 o virus_name 642 o dst_ip: The destination IP address of the packet where the virus 643 is found 645 o src_ip: The source IP address of the packet where the virus is 646 found 648 o src_port: The source port of the packet where the virus is found 650 o dst_port: The destination port of the packet where the virus is 651 found 653 o src_zone: The source security zone of the packet where the virus 654 is found 656 o dst_zone: The destination security zone of the packet where the 657 virus is found 659 o file_type: The type of the file where the virus is hided within 661 o file_name: The name of the file where the virus is hided within 662 o virus_info: The brief introduction of virus 664 o raw_info: The information describing the packet triggering the 665 event. 667 o rule_id: The ID of the rule being triggered 669 o rule_name: The name of the rule being triggered 671 o profile: Security profile that traffic matches. 673 8.5.4. Intrusion Event 675 The following information should be included in a Intrustion Event: 677 o event_name: The name of event: 'SEC_EVENT_Intrusion' 679 o sub_attack_type: Attack type, e.g., brutal force, buffer overflow 681 o src_ip: The source IP address of the packet 683 o dst_ip: The destination IP address of the packet 685 o src_port:The source port number of the packet 687 o dst_port: The destination port number of the packet 689 o src_zone: The source security zone of the packet 691 o dst_zone: The destination security zone of the packet 693 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 695 o app: The employed application layer protocol, e.g.,HTTP, FTP 697 o rule_id: The ID of the rule being triggered 699 o rule_name: The name of the rule being triggered 701 o profile: Security profile that traffic matches 703 o intrusion_info: Simple description of intrusion 705 o raw_info: The information describing the packet triggering the 706 event. 708 8.5.5. Botnet Event 710 The following information should be included in a Botnet Event: 712 o event_name: the name of event: 'SEC_EVENT_Botnet' 714 o botnet_name: The name of the detected botnet 716 o src_ip: The source IP address of the packet 718 o dst_ip: The destination IP address of the packet 720 o src_port: The source port number of the packet 722 o dst_port: The destination port number of the packet 724 o src_zone: The source security zone of the packet 726 o dst_zone: The destination security zone of the packet 728 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 730 o app: The employed application layer protocol, e.g.,HTTP, FTP 732 o role: The role of the communicating parties within the botnet: 734 1. the packet from zombie host to the attacker 736 2. The packet from the attacker to the zombie host 738 3. The packet from the IRC/WEB server to the zombie host 740 4. The packet from the zombie host to the IRC/WEB server 742 5. The packet from the attacker to the IRC/WEB server 744 6. The packet from the IRC/WEB server to the attacker 746 7. The packet from the zombie host to the victim 748 o botnet_info: Simple description of Botnet 750 o rule_id: The ID of the rule being triggered 752 o rule_name: The name of the rule being triggered 754 o profile: Security profile that traffic matches 755 o raw_info: The information describing the packet triggering the 756 event. 758 8.5.6. Web Attack Event 760 The following information should be included in a Web Attack Alarm: 762 o event_name: the name of event: 'SEC_EVENT_WebAttack' 764 o sub_attack_type: Concret web attack type, e.g., sql injection, 765 command injection, XSS, CSRF 767 o src_ip: The source IP address of the packet 769 o dst_ip: The destination IP address of the packet 771 o src_port: The source port number of the packet 773 o dst_port: The destination port number of the packet 775 o src_zone: The source security zone of the packet 777 o dst_zone: The destination security zone of the packet 779 o req_method: The method of requirement. For instance, 'PUT' or 780 'GET' in HTTP 782 o req_url: Requested URL 784 o url_category: Matched URL category 786 o filtering_type: URL filtering type, e.g., Blacklist, Whitelist, 787 User-Defined, Predefined, Malicious Category, Unknown 789 o rule_id: The ID of the rule being triggered 791 o rule_name: The name of the rule being triggered 793 o profile: Security profile that traffic matches. 795 8.6. NSF Logs 797 8.6.1. DDoS Logs 799 Besides the fields in an DDoS Alarm, the following information should 800 be included in a DDoS Logs: 802 o attack_type: DDoS 803 o attack_ave_rate: The average pps of the attack traffic within the 804 recorded time 806 o attack_ave_speed: The average bps of the attack traffic within the 807 recorded time 809 o attack_pkt_num: The number attack packets within the recorded time 811 o attack_src_ip: The source IP addresses of attack traffics. If 812 there are a large amount of IP addresses, then pick a certain 813 number of resources according to different rules. 815 o action: Actions against DDoS attacks, e.g., Allow, Alert, Block, 816 Discard, Declare, Block-ip, Block-service. 818 8.6.2. Virus Logs 820 Besides the fields in an Virus Alarm, the following information 821 should be included in a Virus Logs: 823 o attack_type: Virus 825 o protocol: The transport layer protocol 827 o app: The name of the application layer protocol 829 o times: The time of detecting the virus 831 o action: The actions dealing with the virus, e.g., alert, block 833 o os: The OS that the virus will affect, e.g., all, android, ios, 834 unix, windows 836 8.6.3. Intrusion Logs 838 Besides the fields in an Intrusion Alarm, the following information 839 should be included in a Intrusion Logs: 841 o attack_type: Intrusion 843 o times: The times of intrusions happened in the recorded time 845 o os: The OS that the intrusion will affect, e.g., all, android, 846 ios, unix, windows 848 o action: The actions dealing with the intrusions, e.g., e.g., 849 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service 851 o attack_rate: NUM the pps of attack traffic 853 o attack_speed: NUM the bps of attack traffic 855 8.6.4. Botnet Logs 857 Besides the fields in an Botnet Alarm, the following information 858 should be included in a Botnet Logs: 860 o attack_type: Botnet 862 o botnet_pkt_num:The number of the packets sent to or from the 863 detected botnet 865 o action: The actions dealing with the detected packets, e.g., 866 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service, 867 etc 869 o os: The OS that the attack aiming at, e.g., all, android, ios, 870 unix, windows, etc. 872 8.6.5. DPI Logs 874 DPI Logs provide statistics on uploaded and downloaded files and 875 data, sent and received emails, and alert and block records on 876 websites. It's helpful to learn risky user behaviors and why access 877 to some URLs is blocked or allowed with an alert record. 879 o type: DPI action types. e.g., File Blocking, Data Filtering, 880 Application Behavior Control 882 o file_name: The file name 884 o file_type: The file type 886 o src_zone: Source security zone of traffic 888 o dst_zone: Destination security zone of traffic 890 o src_region: Source region of the traffic 892 o dst_region: Destination region of the traffic 894 o src_ip: Source IP address of traffic 896 o src_user: User who generates traffic 898 o dst_ip: Destination IP address of traffic 899 o src_port: Source port of traffic 901 o dst_port: Destination port of traffic 903 o protocol: Protocol type of traffic 905 o app: Application type of traffic 907 o policy_id: Security policy id that traffic matches 909 o policy_name: Security policy name that traffic matches 911 o action: Action defined in the file blocking rule, data filtering 912 rule, or application behavior control rule that traffic matches. 914 8.6.6. Vulnerabillity Scanning Logs 916 Vulnerability scanning logs record the victim host and its related 917 vulnerability information that should to be fixed. the following 918 information should be included in the report: 920 o victim_ip: IP address of the victim host which has vulnerabilities 922 o vulnerability_id: The vulnerability id 924 o vulnerability_level: The vulnerability level. e.g., high, middle, 925 low 927 o OS: The operating system of the victim host 929 o service: The service which has vulnerabillity in the victim host 931 o protocol: The protocol type. e.g., TCP, UDP 933 o port: The port number 935 o vulnerability_info: The information about the vulnerability 937 o fix_suggestion: The fix suggestion to the vulnerability. 939 8.6.7. Web Attack Logs 941 Besides the fields in an Web Attack Alarm, the following information 942 should be included in a Web Attack Report: 944 o attack_type: Web Attack 946 o rsp_code: Response code 947 o req_clientapp: The client application 949 o req_cookies: Cookies 951 o req_host: The domain name of the requested host 953 o raw_info: The information describing the packet triggering the 954 event. 956 8.7. NSF Counters 958 8.7.1. Firewall counters 960 Firewall counters provide visibility into traffic signatures, 961 bandwidth usage, and how the configured security and bandwidth 962 policies have been applied. 964 o src_zone: Source security zone of traffic 966 o dst_zone: Destination security zone of traffic 968 o src_region: Source region of the traffic 970 o dst_region: Destination region of the traffic 972 o src_ip: Source IP address of traffic 974 o src_user: User who generates traffic 976 o dst_ip: Destination IP address of traffic 978 o src_port: Source port of traffic 980 o dst_port: Destination port of traffic 982 o protocol: Protocol type of traffic 984 o app: Application type of traffic 986 o policy_id: Security policy id that traffic matches 988 o policy_name: Security policy name that traffic matches 990 o in_interface: Inbound interface of traffic 992 o out_interface: Outbound interface of traffic 994 o total_traffic: Total traffic volume 995 o in_traffic_ave_rate: Inbound traffic average rate in pps 997 o in_traffic_peak_rate: Inbound traffic peak rate in pps 999 o in_traffic_ave_speed: Inbound traffic average speed in bps 1001 o in_traffic_peak_speed: Inbound traffic peak speed in bps 1003 o out_traffic_ave_rate: Outbound traffic average rate in pps 1005 o out_traffic_peak_rate: Outbound traffic peak rate in pps 1007 o out_traffic_ave_speed: Outbound traffic average speed in bps 1009 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 1011 8.7.2. Policy Hit Counters 1013 Policy Hit Counters record the security policy that traffic matches 1014 and its hit count. It can check if policy configurations are 1015 correct. 1017 o src_zone: Source security zone of traffic 1019 o dst_zone: Destination security zone of traffic 1021 o src_region: Source region of the traffic 1023 o dst_region: Destination region of the traffic 1025 o src_ip: Source IP address of traffic 1027 o src_user: User who generates traffic 1029 o dst_ip: Destination IP address of traffic 1031 o src_port: Source port of traffic 1033 o dst_port: Destination port of traffic 1035 o protocol: Protocol type of traffic 1037 o app: Application type of traffic 1039 o policy_id: Security policy id that traffic matches 1041 o policy_name: Security policy name that traffic matches 1042 o hit_times: The hit times that the security policy matches the 1043 specified traffic. 1045 9. IANA Considerations 1047 This document makes no request of IANA. 1049 Note to RFC Editor: this section may be removed on publication as an 1050 RFC. 1052 10. Security Considerations 1054 The monitoring information of NSF should be protected by the secure 1055 communication channel, to ensure its confidentiality and integrity. 1056 In another side, the NSF and security controller can all be faked, 1057 which lead to undesireable results, i.e., leakage of NSF's important 1058 operational information, faked NSF sending false information to 1059 mislead security controller. The mutual authentication is essential 1060 to protected against this kind of attack. The current mainstream 1061 security technologies (i.e., TLS, DTLS, IPSEC, X.509 PKI) can be 1062 employed approriately to provide the above security functions. 1064 In addition, to defend against the DDoS attack caused by a lot of 1065 NSFs sending massive monitoring information to the security 1066 controller, the rate limiting or similar mechanisms should be 1067 considered in NSF and security controller, whether in advance or just 1068 in the process of DDoS attack. 1070 11. Acknowledgements 1072 12. References 1074 12.1. Normative References 1076 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1077 Requirement Levels", BCP 14, RFC 2119, 1078 DOI 10.17487/RFC2119, March 1997, 1079 . 1081 12.2. Informative References 1083 [I-D.ietf-i2nsf-framework] 1084 Lopez, E., Lopez, D., Dunbar, L., Strassner, J., Zhuang, 1085 X., Parrott, J., Krishnan, R., Durbha, S., Kumar, R., and 1086 A. Lohiya, "Framework for Interface to Network Security 1087 Functions", draft-ietf-i2nsf-framework-03 (work in 1088 progress), August 2016. 1090 [I-D.xia-i2nsf-capability-interface-im] 1091 Xia, L., Strassner, J., Li, K., Zhang, D., Lopez, E., 1092 Bouthors, N., and L. Fang, "Information Model of Interface 1093 to Network Security Functions Capability Interface", 1094 draft-xia-i2nsf-capability-interface-im-06 (work in 1095 progress), July 2016. 1097 Authors' Addresses 1099 Dacheng Zhang 1100 Huawei 1102 Email: dacheng.zhang@huawei.com 1104 Yi Wu 1105 Aliababa Group 1107 Email: anren.wy@alibaba-inc.com 1109 Liang Xia 1110 Huawei 1112 Email: frank.xialiang@huawei.com 1114 Rakesh Kumar 1115 Juniper Networks 1117 Email: rkkumar@juniper.net 1119 Anil Lohiya 1120 Juniper Networks 1122 Email: alohiya@juniper.net