idnits 2.17.1 draft-zhang-i2nsf-info-model-monitoring-03.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 (March 13, 2017) is 2600 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 1113, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-04 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 L. Xia 3 Internet-Draft D. Zhang 4 Intended status: Experimental Huawei 5 Expires: September 14, 2017 Y. Wu 6 Aliababa Group 7 R. Kumar 8 A. Lohiya 9 Juniper Networks 10 H. Birkholz 11 Fraunhofer SIT 12 March 13, 2017 14 An Information Model for the Monitoring of Network Security Functions 15 (NSF) 16 draft-zhang-i2nsf-info-model-monitoring-03 18 Abstract 20 The Network Security Functions (NSF) NSF-facing interface exists 21 between the Service Provider's management system (or Security 22 Controller) and the NSFs to enforce the security policy provisioning 23 and network security status monitoring . This document focuses on the 24 monitoring part of it and proposes the 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 September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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. Exporting NSF Monitoring Data . . . . . . . . . . . . . . . . 6 67 6. Basic Information Model for All Monitoring Data . . . . . . . 7 68 7. Extended Information Model for Monitoring Data . . . . . . . 8 69 7.1. System Alarm . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 8 71 7.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 9 72 7.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 9 73 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 9 74 7.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 10 75 7.2. System Events . . . . . . . . . . . . . . . . . . . . . . 10 76 7.2.1. Access Violation . . . . . . . . . . . . . . . . . . 10 77 7.2.2. Configuration Change . . . . . . . . . . . . . . . . 10 78 7.3. System Log . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.3.1. Access Logs . . . . . . . . . . . . . . . . . . . . . 11 80 7.3.2. Resource Utilization Logs . . . . . . . . . . . . . . 11 81 7.3.3. User Activity Logs . . . . . . . . . . . . . . . . . 12 82 7.4. System Counters . . . . . . . . . . . . . . . . . . . . . 12 83 7.4.1. Interface counters . . . . . . . . . . . . . . . . . 12 84 7.5. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.5.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 13 86 7.5.2. Session Table Event . . . . . . . . . . . . . . . . . 14 87 7.5.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 14 88 7.5.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 15 89 7.5.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 16 90 7.5.6. Web Attack Event . . . . . . . . . . . . . . . . . . 17 91 7.6. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7.6.1. DDoS Logs . . . . . . . . . . . . . . . . . . . . . . 18 93 7.6.2. Virus Logs . . . . . . . . . . . . . . . . . . . . . 18 94 7.6.3. Intrusion Logs . . . . . . . . . . . . . . . . . . . 19 95 7.6.4. Botnet Logs . . . . . . . . . . . . . . . . . . . . . 19 96 7.6.5. DPI Logs . . . . . . . . . . . . . . . . . . . . . . 19 97 7.6.6. Vulnerabillity Scanning Logs . . . . . . . . . . . . 20 98 7.6.7. Web Attack Logs . . . . . . . . . . . . . . . . . . . 21 99 7.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 21 100 7.7.1. Firewall counters . . . . . . . . . . . . . . . . . . 21 101 7.7.2. Policy Hit Counters . . . . . . . . . . . . . . . . . 22 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 107 11.2. Informative References . . . . . . . . . . . . . . . . . 24 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 110 1. Introduction 112 According to [I-D.ietf-i2nsf-framework], the interface provided by a 113 NSF (e.g., FW, IPS, Anti-DDOS, or Anti-Virus) to administrative 114 entities (e.g., NMS, security controller) for configuring security 115 function in the NSF and monitoring the NSF is referred to as a 'I2NSF 116 customer-facing interface'. The monitoring part of it is meant to 117 monitor the NSF e.g. events, alerts, alarms, logs, counters. The 118 monitoring of the NSF plays a very important role in the overall 119 security framework if done in a timely and comprehensive way. The 120 monitoring information generated by a NSF could very well be an early 121 indication of malicious activity, or anomalous behavior, or a 122 potential sign of denial of service attacks. 124 This draft proposes a comprehensive NSF monitoring information model 125 that provide visibility into NSFs. This document will not go into 126 the design details of NSF-facing interface. Instead, this draft is 127 focused on specifying the information that a NSF needs to provide in 128 the monitoring part of the NSF-facing interface, as well as its 129 information model. Besides, [I-D.draft-xibassnez-i2nsf-capability ] 130 specifies the information model for the security policy provisioning 131 part of the NSF-facing interface. 133 2. Terminology 135 2.1. Key Words 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2.2. Definition of Terms 143 This document uses the terms defined in [I-D.draft-ietf-i2nsf- 144 terminology]. 146 3. Use cases for NSF Monitoring Data 148 As mentioned earlier, monitoring plays a very critical role in the 149 overall security framework. The monitoring of the NSF provides very 150 valuable information to the security controller in maintaining the 151 provisioned security posture. Besides this, there are various other 152 reasons to monitor the NSFs as listed below: 154 o The security administrator could configure a policy that is 155 triggered on a specific event happened in the NSF or the network. 156 The security controller would monitor for the specified event and 157 once it happens, it configures additional security functions as 158 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 etc. 171 o The events and activity logs from the NSF could aid in debugging 172 and root cause analysis of an operational issue. 174 o The activity logs from the NSF could be used to build historical 175 data for operational and business reasons. 177 4. Classification of NSF Monitoring Data 179 In order to maintain a strong security posture, it is not only 180 necessary to configure NSF security policies but also to continuously 181 monitor NSF by consuming acquirable monitoring data. This enables 182 security admins to assess what is happening in the network timely. 183 It is not possible to block all the internal and external threats 184 based on static security posture but requires a very dynamic posture 185 with constant visibility. This draft defines a set of information 186 elements (and their scope) that can be acquired from NSF and can be 187 used as monitoring data. In essence, these types of monitoring data 188 can be leveraged to support constant visibility on multiple levels of 189 granularity and can be consumed by corresponding functions. The 190 types of monitoring data as ordered below increase in expressiveness 191 by incorporating more information to the semantics of the monitoring 192 data. There are two categories of monitoring data. Information that 193 is produced and emitted by an NSF automatically (published data) and 194 information that is produced and retained by the NSF and has to be 195 collected in intervals (retained data): 197 Published Data: 199 o Events: the most generic type of monitoring data that can be 200 emitted by an NSF. An event is defined in [RFC3877] as "something 201 that happens which may be of interest. A fault, a change in 202 status, crossing a threshold, or an external input to the system, 203 for example. In the context of the I2NSF IMM, an event is a 204 representation of a change of state, configuration, or composition 205 of an NSF or an entity (e.g. an endpoint) or an activity (e.g. a 206 PDU flow) that can be observed by the NSF and can be interpreted 207 as a change of state or behavior by the NSF. An event can be 208 created without the use of an I2NSF Condition (declarative 209 guidance) available to the NSF. In the context of I2NSF, in some 210 cases an event can trigger low level I2NSF actions (which 211 constitutes an implicit escalation to alert via primate 212 assessment). 214 o Alert: an event that is annotated with a criticality assessment 215 due to non-compliance with I2NSF conditions (declarative guidance) 216 available to an I2NSF Consumer via I2NSF Actions. The Intrusion 217 Detection Message Exchange Format [RFC4765] defines a 218 representation that "systems can use to report alerts about events 219 that they deem suspicious" and also associates a severity ("an 220 estimate of the relative severity of the event") with the 221 corresponding alert. In the context of the I2NSF IMM, an alert is 222 derived from events that express changes indicating not to conform 223 with declarative guidance (e.g. an exceeded threshold of a value 224 or a pattern or signature found in a PDU stream - typically an 225 I2NSF condition) or due to imperative guidance (e.g. correlation 226 rules applied to streams of multiple events over time or a black- 227 list content of an event matches - typically an I2NSF Policy 228 Rule). An alert is created by an I2NSF Producer with respect to 229 I2NSF conditions (declarative guidance) or imperative guidance 230 available to the I2NSF Producer. An alert does not indicate an 231 immediate impact on operations and are not time-sensitive (but can 232 be escalated to an alarm nevertheless due to persistence via an 233 I2NSF Policy Rule). 235 o Alarms: an alarm that is annotated with the assertion of: 1.) 236 having immediate impact on operations, or 2.) a persistence that 237 in non-compliant in respect to I2NSF conditions (declarative 238 guidance), or 3.) a correlation result produced by a I2NSF Service 239 in respect to the result of I2NSF Policy Rules that process 240 alerts. Alarms are time-sensitive and must be reported to the 241 security admin as soon as possible. By processing alarms, the 242 administrator can rapidly locate the root-cause of faults and 243 rapidly deal with the faults to ensure normal operation of the 244 NSFs and avoid NSFs going into unknown state or potentially 245 exposing security vulnerabilities. An analyst can manage the NSF 246 with via I2NSF Policy Rules. The intend of alarms is to highlight 247 only critical information and to avoid continuous combing through 248 large amount alerts (or even events) by analysts. 250 Retained Data: 252 o Logs: Logs are information generated by NSF about its operational 253 and informational data, or various events such as user activities, 254 network/traffic status and network activity, etc. Logs are 255 important for debugging, auditing and security forensic. Unlike 256 events, logs do not require an immediate attention from an analyst 257 but may be useful for visibility and retroactive cyber forensic. 258 Hence, logs usually include less structures but potentially more 259 detailed information in regard to events. For example, the NSF 260 could generate a log when due to an I2NSF Policy Rule. Logs can 261 be continuously processed by I2NSF Agent that act as I2NSF 262 Producer and emit events via function specifically tailored to a 263 type of log. 265 o Counters: A specific representation of identical state changes 266 that potentially occur in high frequency. Examples include 267 network interface counters (packets, bytes), drop, error counters 268 etc. Counters are useful in debugging and visibility into 269 operational behavior of the NSF. An I2NSF Agent that observes the 270 progress of counters can act as an I2NSF Producer and emit Events 271 in respect to I2NSF Policy Rules. 273 5. Exporting NSF Monitoring Data 275 As per the use cases of NSF monitoring data, the data need to be sent 276 to various consumers based on the needs and requirements. There are 277 multiple things to be considered for exporting this data to needed 278 parties as listed below: 280 o Pull-Push model: A set of data could be pushed by a NSF to the 281 needed party or pulled by the needed party from a NSF. A specific 282 data might need both the models at the same time if there are 283 multiple consumers with varying requirements. It really depends 284 upon the need and its usages to the consumer. In general, any 285 alarm is considered to be of great importance and must be sent 286 immediately for any meaningful action so it should be sent using 287 push model but logs are not as critical so could be pulled by the 288 consumer. The I2NSF does not mandate a specific scheme for each 289 data set, it is up to each implementation. 291 o Export frequency: The monitoring data could be sent immediately 292 upon generation by a NSF to interested parties or pushed 293 periodically. The frequency of exporting the data depends upon 294 its size and timely usefulness. It is out of the scope of I2NSF 295 and left to each NSF implementation. 297 o Authentication: There may be a need for authentication between 298 monitoring data producer (NSF) and consumer to ensure that 299 critical information does not fall into wrong hands. This may be 300 necessary if the NSF directly export data to the consumer outside 301 its admin boundary. The I2NSF does not mandate when and how 302 specific authentication must be done. 304 o Subscription method: In order for the consumer to pull the data 305 from NSF or for NSF to push the data to a consumer, there must be 306 a mechanism for consumer to subscribe to the NSF data it is 307 interested in. There are few open source method available and it 308 is up to each implementation to decide the right one. 310 o Data transfer mode: The data could be pushed by NSF using a 311 connection-less model that does require a persistent connection or 312 streamed over a persistent connection. It depends upon the 313 requirement of the consumer and the nature of data. A particular 314 set of data can use either or both the mode based on 315 implementation. 317 o Transport method: There are lot of transport mechanism such as IP, 318 UDP, TCP. There are also open source implementations for specific 319 set of data such as systems counter. The I2NSF does not mandate 320 any specific method for a given data set, it is up to each 321 implementation. 323 6. Basic Information Model for All Monitoring Data 325 As explained in the above section, there is a wealth of data 326 available from the NSF that can be monitored. Firstly, there must be 327 some general information with each monitoring message sent from an 328 NSF that helps consumer in identifying meta data with that message, 329 which are listed as below: 331 o message_version: Indicate the version of the data format and is a 332 two-digit decimal numeral starting from 01 334 o message_type: Event, Alert, Alarm, Log, Counter, etc 336 o time_stamp: Indicate the time when the message is generated 338 o vendor_name: The name of the NSF vendor 340 o NSF_name: The name (or IP) of the NSF generating the message 342 o Module_name: The module name outputting the message 344 o Severity: Indicates the level of the logs. There are total eight 345 levels, from 0 to 7. The smaller the numeral is, the higher the 346 severity is. 348 7. Extended Information Model for Monitoring Data 350 This section covers the additional information associated with the 351 system messages. The extended information model is only for the 352 structured data such as alarm. Any unstructured data is specified 353 with basic information model only. 355 [Editors' note]: This section remains the same as -02 version, 356 although the classification of the monitoring data has been changed 357 from -02 version. The new inconsistency will be addressed in next 358 verion. 360 7.1. System Alarm 362 7.1.1. Memory Alarm 364 The following information should be included in a Memory Alarm: 366 o event_name: 'MEM_USAGE_ALARM' 368 o module_name: Indicate the NSF module responsible for generating 369 this alarm 371 o usage: specifies the amount of memory used 373 o threshold: The threshold triggering the alarm 375 o severity: The severity of the alarm such as critical, high, 376 medium, low 378 o message: 'The memory usage exceeded the threshold' 380 7.1.2. CPU Alarm 382 The following information should be included in a CPU Alarm: 384 o event_name: 'CPU_USAGE_ALARM' 386 o usage: Specifies the amount of CPU used 388 o threshold: The threshold triggering the event 390 o severity: The severity of the alarm such as critical, high, 391 medium, low 393 o message: 'The CPU usage exceeded the threshold' 395 7.1.3. Disk Alarm 397 The following information should be included in a Disk Alarm: 399 o event_name: 'DISK_USAGE_ALARM' 401 o usage: Specifies the amount of disk space used 403 o threshold: The threshold triggering the event 405 o severity: The severity of the alarm such as critical, high, 406 medium, low 408 o message: 'The disk usage exceeded the threshold' 410 7.1.4. Hardware Alarm 412 The following information should be included in a Hardware Alarm: 414 o event_name: 'HW_FAILURE_ALARM' 416 o component_name: Indicate the HW component responsible for 417 generating this alarm 419 o threshold: The threshold triggering the alarm 421 o severity: The severity of the alarm such as critical, high, 422 medium, low 424 o message: 'The HW component has failed or degraded' 426 7.1.5. Interface Alarm 428 The following information should be included in a Interface Alarm: 430 o event_name: 'IFNET_STATE_ALARM' 432 o interface_Name: The name of interface 434 o interface_state: 'UP', 'DOWN', 'CONGESTED' 436 o threshold: The threshold triggering the event 438 o severity: The severity of the alarm such as critical, high, 439 medium, low 441 o message: 'Current interface state' 443 7.2. System Events 445 7.2.1. Access Violation 447 The following information should be included in this event: 449 o event_name: 'ACCESS_DENIED' 451 o user: Name of a user 453 o group: Group to which a user belongs 455 o login_ip_address: Login IP address of a user 457 o authentication_mode: User authentication mode. e.g., Local 458 Authentication, Third-Party Server Authentication, Authentication 459 Exemption, SSO Authentication 461 o message: 'access denied' 463 7.2.2. Configuration Change 465 The following information should be included in this event: 467 o event_name: 'CONFIG_CHANGE' 469 o user: Name of a user 471 o group: Group to which a user belongs 473 o login_ip_address: Login IP address of a user 474 o authentication_mode: User authentication mode. e.g., Local 475 Authentication, Third-Party Server Authentication, Authentication 476 Exemption, SSO Authentication 478 o message: 'Configuration modified' 480 7.3. System Log 482 7.3.1. Access Logs 484 Access logs record administrators' login, logout, and operations on 485 the device. By analyzing them, security vulnerabilities can be 486 identified. The following information should be included in 487 operation report: 489 o Administrator: Administrator that operates on the device 491 o login_ip_address: IP address used by an administrator to log in 493 o login_mode: Specifies the administrator logs in mode e.g. root, 494 user 496 o operation_type: The operation type that the administrator execute, 497 e.g., login, logout, configuration, etc 499 o result: Command execution result 501 o content: Operation performed by an administrator after login. 503 7.3.2. Resource Utilization Logs 505 Running reports record the device system's running status, which is 506 useful for device monitoring. The following information should be 507 included in running report: 509 o system_status: The current system's running status 511 o CPU_usage: Specifies the CPU usage 513 o memory_usage: Specifies the memory usage 515 o disk_usage: Specifies the disk usage 517 o disk_left: Specifies the available disk space left 519 o session_number: Specifies total concurrent sessions 521 o process_number: Specifies total number of system processes 522 o in_traffic_rate: The total inbound traffic rate in pps 524 o out_traffic_rate: The total outbound traffic rate in pps 526 o in_traffic_speed: The total inbound traffic speed in bps 528 o out_traffic_speed: The total outbound traffic speed in bps 530 7.3.3. User Activity Logs 532 User activity logs provide visibility into users' online records 533 (such as login time, online/lockout duration, and login IP addresses) 534 and the actions users perform. User activity reports are helpful to 535 identify exceptions during user login and network access activities. 537 o user: Name of a user 539 o group: Group to which a user belongs 541 o login_ip_address: Login IP address of a user 543 o authentication_mode: User authentication mode. e.g., Local 544 Authentication, Third-Party Server Authentication, Authentication 545 Exemption, SSO Authentication 547 o access_mode: User access mode. e.g., PPP, SVN, LOCAL 549 o online_duration: Online duration 551 o lockout_duration: Lockout duration 553 o type: User activities. e.g., Successful User Login, Failed Login 554 attempts, User Logout, Successful User Password Change, Failed 555 User Password Change, User Lockout, User Unlocking, Unknown 557 o cause: Cause of a failed user activity 559 7.4. System Counters 561 7.4.1. Interface counters 563 Interface counters provide visibility into traffic into and out of 564 NSF, bandwidth usage. 566 o interface_name: Network interface name configured in NSF 568 o in_total_traffic_pkts: Total inbound packets 569 o out_total_traffic_pkts: Total outbound packets 571 o in_total_traffic_bytes: Total inbound bytes 573 o out_total_traffic_bytes: Total outbound bytes 575 o in_drop_traffic_pkts: Total inbound drop packets 577 o out_drop_traffic_pkts: Total outbound drop packets 579 o in_drop_traffic_bytes: Total inbound drop bytes 581 o out_drop_traffic_bytes: Total outbound drop bytes 583 o in_traffic_ave_rate: Inbound traffic average rate in pps 585 o in_traffic_peak_rate: Inbound traffic peak rate in pps 587 o in_traffic_ave_speed: Inbound traffic average speed in bps 589 o in_traffic_peak_speed: Inbound traffic peak speed in bps 591 o out_traffic_ave_rate: Outbound traffic average rate in pps 593 o out_traffic_peak_rate: Outbound traffic peak rate in pps 595 o out_traffic_ave_speed: Outbound traffic average speed in bps 597 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 599 7.5. NSF Events 601 7.5.1. DDoS Event 603 The following information should be included in a DDoS Event: 605 o event_name: 'SEC_EVENT_DDoS' 607 o sub_attack_type: Any one of Syn flood, ACK flood, SYN-ACK flood, 608 FIN/RST flood, TCP Connection flood, UDP flood, Icmp flood, HTTPS 609 flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 610 and etc. 612 o dst_ip: The IP address of a victum under attack 614 o dst_port: The port numbers that the attrack traffic aims at. 616 o start_time: The time stamp indicating when the attack started 617 o end_time: The time stamp indicating when the attack ended. If the 618 attack is still undergoing when sending out the alarm, this field 619 can be empty. 621 o attack_rate: The PPS of attack traffic 623 o attack_speed: the bps of attack traffic 625 o rule_id: The ID of the rule being triggered 627 o rule_name: The name of the rule being triggered 629 o profile: Security profile that traffic matches. 631 7.5.2. Session Table Event 633 The following information should be included in a Session 634 Table Event: 636 o event_name: 'SESSION_USAGE_HIGH' 638 o current: The number of concurrent sessions 640 o max: The maximum number of sessions that the session table can 641 support 643 o threshold: The threshold triggering the event 645 o message: 'The number of session table exceeded the threshold' 647 7.5.3. Virus Event 649 The following information should be included in a Virus Event: 651 o event_Name: 'SEC_EVENT_VIRUS' 653 o virus_type: Type of the virus, e.g., trojan, worm, macro Virus 654 type 656 o virus_name 658 o dst_ip: The destination IP address of the packet where the virus 659 is found 661 o src_ip: The source IP address of the packet where the virus is 662 found 664 o src_port: The source port of the packet where the virus is found 665 o dst_port: The destination port of the packet where the virus is 666 found 668 o src_zone: The source security zone of the packet where the virus 669 is found 671 o dst_zone: The destination security zone of the packet where the 672 virus is found 674 o file_type: The type of the file where the virus is hided within 676 o file_name: The name of the file where the virus is hided within 678 o virus_info: The brief introduction of virus 680 o raw_info: The information describing the packet triggering the 681 event. 683 o rule_id: The ID of the rule being triggered 685 o rule_name: The name of the rule being triggered 687 o profile: Security profile that traffic matches. 689 7.5.4. Intrusion Event 691 The following information should be included in a Intrustion Event: 693 o event_name: The name of event: 'SEC_EVENT_Intrusion' 695 o sub_attack_type: Attack type, e.g., brutal force, buffer overflow 697 o src_ip: The source IP address of the packet 699 o dst_ip: The destination IP address of the packet 701 o src_port:The source port number of the packet 703 o dst_port: The destination port number of the packet 705 o src_zone: The source security zone of the packet 707 o dst_zone: The destination security zone of the packet 709 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 711 o app: The employed application layer protocol, e.g.,HTTP, FTP 712 o rule_id: The ID of the rule being triggered 714 o rule_name: The name of the rule being triggered 716 o profile: Security profile that traffic matches 718 o intrusion_info: Simple description of intrusion 720 o raw_info: The information describing the packet triggering the 721 event. 723 7.5.5. Botnet Event 725 The following information should be included in a Botnet Event: 727 o event_name: the name of event: 'SEC_EVENT_Botnet' 729 o botnet_name: The name of the detected botnet 731 o src_ip: The source IP address of the packet 733 o dst_ip: The destination IP address of the packet 735 o src_port: The source port number of the packet 737 o dst_port: The destination port number of the packet 739 o src_zone: The source security zone of the packet 741 o dst_zone: The destination security zone of the packet 743 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 745 o app: The employed application layer protocol, e.g.,HTTP, FTP 747 o role: The role of the communicating parties within the botnet: 749 1. the packet from zombie host to the attacker 751 2. The packet from the attacker to the zombie host 753 3. The packet from the IRC/WEB server to the zombie host 755 4. The packet from the zombie host to the IRC/WEB server 757 5. The packet from the attacker to the IRC/WEB server 759 6. The packet from the IRC/WEB server to the attacker 760 7. The packet from the zombie host to the victim 762 o botnet_info: Simple description of Botnet 764 o rule_id: The ID of the rule being triggered 766 o rule_name: The name of the rule being triggered 768 o profile: Security profile that traffic matches 770 o raw_info: The information describing the packet triggering the 771 event. 773 7.5.6. Web Attack Event 775 The following information should be included in a Web Attack Alarm: 777 o event_name: the name of event: 'SEC_EVENT_WebAttack' 779 o sub_attack_type: Concret web attack type, e.g., sql injection, 780 command injection, XSS, CSRF 782 o src_ip: The source IP address of the packet 784 o dst_ip: The destination IP address of the packet 786 o src_port: The source port number of the packet 788 o dst_port: The destination port number of the packet 790 o src_zone: The source security zone of the packet 792 o dst_zone: The destination security zone of the packet 794 o req_method: The method of requirement. For instance, 'PUT' or 795 'GET' in HTTP 797 o req_url: Requested URL 799 o url_category: Matched URL category 801 o filtering_type: URL filtering type, e.g., Blacklist, Whitelist, 802 User-Defined, Predefined, Malicious Category, Unknown 804 o rule_id: The ID of the rule being triggered 806 o rule_name: The name of the rule being triggered 807 o profile: Security profile that traffic matches. 809 7.6. NSF Logs 811 7.6.1. DDoS Logs 813 Besides the fields in an DDoS Alarm, the following information should 814 be included in a DDoS Logs: 816 o attack_type: DDoS 818 o attack_ave_rate: The average pps of the attack traffic within the 819 recorded time 821 o attack_ave_speed: The average bps of the attack traffic within the 822 recorded time 824 o attack_pkt_num: The number attack packets within the recorded time 826 o attack_src_ip: The source IP addresses of attack traffics. If 827 there are a large amount of IP addresses, then pick a certain 828 number of resources according to different rules. 830 o action: Actions against DDoS attacks, e.g., Allow, Alert, Block, 831 Discard, Declare, Block-ip, Block-service. 833 7.6.2. Virus Logs 835 Besides the fields in an Virus Alarm, the following information 836 should be included in a Virus Logs: 838 o attack_type: Virus 840 o protocol: The transport layer protocol 842 o app: The name of the application layer protocol 844 o times: The time of detecting the virus 846 o action: The actions dealing with the virus, e.g., alert, block 848 o os: The OS that the virus will affect, e.g., all, android, ios, 849 unix, windows 851 7.6.3. Intrusion Logs 853 Besides the fields in an Intrusion Alarm, the following information 854 should be included in a Intrusion Logs: 856 o attack_type: Intrusion 858 o times: The times of intrusions happened in the recorded time 860 o os: The OS that the intrusion will affect, e.g., all, android, 861 ios, unix, windows 863 o action: The actions dealing with the intrusions, e.g., e.g., 864 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service 866 o attack_rate: NUM the pps of attack traffic 868 o attack_speed: NUM the bps of attack traffic 870 7.6.4. Botnet Logs 872 Besides the fields in an Botnet Alarm, the following information 873 should be included in a Botnet Logs: 875 o attack_type: Botnet 877 o botnet_pkt_num:The number of the packets sent to or from the 878 detected botnet 880 o action: The actions dealing with the detected packets, e.g., 881 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service, 882 etc 884 o os: The OS that the attack aiming at, e.g., all, android, ios, 885 unix, windows, etc. 887 7.6.5. DPI Logs 889 DPI Logs provide statistics on uploaded and downloaded files and 890 data, sent and received emails, and alert and block records on 891 websites. It's helpful to learn risky user behaviors and why access 892 to some URLs is blocked or allowed with an alert record. 894 o type: DPI action types. e.g., File Blocking, Data Filtering, 895 Application Behavior Control 897 o file_name: The file name 898 o file_type: The file type 900 o src_zone: Source security zone of traffic 902 o dst_zone: Destination security zone of traffic 904 o src_region: Source region of the traffic 906 o dst_region: Destination region of the traffic 908 o src_ip: Source IP address of traffic 910 o src_user: User who generates traffic 912 o dst_ip: Destination IP address of traffic 914 o src_port: Source port of traffic 916 o dst_port: Destination port of traffic 918 o protocol: Protocol type of traffic 920 o app: Application type of traffic 922 o policy_id: Security policy id that traffic matches 924 o policy_name: Security policy name that traffic matches 926 o action: Action defined in the file blocking rule, data filtering 927 rule, or application behavior control rule that traffic matches. 929 7.6.6. Vulnerabillity Scanning Logs 931 Vulnerability scanning logs record the victim host and its related 932 vulnerability information that should to be fixed. the following 933 information should be included in the report: 935 o victim_ip: IP address of the victim host which has vulnerabilities 937 o vulnerability_id: The vulnerability id 939 o vulnerability_level: The vulnerability level. e.g., high, middle, 940 low 942 o OS: The operating system of the victim host 944 o service: The service which has vulnerabillity in the victim host 945 o protocol: The protocol type. e.g., TCP, UDP 947 o port: The port number 949 o vulnerability_info: The information about the vulnerability 951 o fix_suggestion: The fix suggestion to the vulnerability. 953 7.6.7. Web Attack Logs 955 Besides the fields in an Web Attack Alarm, the following information 956 should be included in a Web Attack Report: 958 o attack_type: Web Attack 960 o rsp_code: Response code 962 o req_clientapp: The client application 964 o req_cookies: Cookies 966 o req_host: The domain name of the requested host 968 o raw_info: The information describing the packet triggering the 969 event. 971 7.7. NSF Counters 973 7.7.1. Firewall counters 975 Firewall counters provide visibility into traffic signatures, 976 bandwidth usage, and how the configured security and bandwidth 977 policies have been applied. 979 o src_zone: Source security zone of traffic 981 o dst_zone: Destination security zone of traffic 983 o src_region: Source region of the traffic 985 o dst_region: Destination region of the traffic 987 o src_ip: Source IP address of traffic 989 o src_user: User who generates traffic 991 o dst_ip: Destination IP address of traffic 992 o src_port: Source port of traffic 994 o dst_port: Destination port of traffic 996 o protocol: Protocol type of traffic 998 o app: Application type of traffic 1000 o policy_id: Security policy id that traffic matches 1002 o policy_name: Security policy name that traffic matches 1004 o in_interface: Inbound interface of traffic 1006 o out_interface: Outbound interface of traffic 1008 o total_traffic: Total traffic volume 1010 o in_traffic_ave_rate: Inbound traffic average rate in pps 1012 o in_traffic_peak_rate: Inbound traffic peak rate in pps 1014 o in_traffic_ave_speed: Inbound traffic average speed in bps 1016 o in_traffic_peak_speed: Inbound traffic peak speed in bps 1018 o out_traffic_ave_rate: Outbound traffic average rate in pps 1020 o out_traffic_peak_rate: Outbound traffic peak rate in pps 1022 o out_traffic_ave_speed: Outbound traffic average speed in bps 1024 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 1026 7.7.2. Policy Hit Counters 1028 Policy Hit Counters record the security policy that traffic matches 1029 and its hit count. It can check if policy configurations are 1030 correct. 1032 o src_zone: Source security zone of traffic 1034 o dst_zone: Destination security zone of traffic 1036 o src_region: Source region of the traffic 1038 o dst_region: Destination region of the traffic 1039 o src_ip: Source IP address of traffic 1041 o src_user: User who generates traffic 1043 o dst_ip: Destination IP address of traffic 1045 o src_port: Source port of traffic 1047 o dst_port: Destination port of traffic 1049 o protocol: Protocol type of traffic 1051 o app: Application type of traffic 1053 o policy_id: Security policy id that traffic matches 1055 o policy_name: Security policy name that traffic matches 1057 o hit_times: The hit times that the security policy matches the 1058 specified traffic. 1060 8. IANA Considerations 1062 This document makes no request of IANA. 1064 Note to RFC Editor: this section may be removed on publication as an 1065 RFC. 1067 9. Security Considerations 1069 The monitoring information of NSF should be protected by the secure 1070 communication channel, to ensure its confidentiality and integrity. 1071 In another side, the NSF and security controller can all be faked, 1072 which lead to undesireable results, i.e., leakage of NSF's important 1073 operational information, faked NSF sending false information to 1074 mislead security controller. The mutual authentication is essential 1075 to protected against this kind of attack. The current mainstream 1076 security technologies (i.e., TLS, DTLS, IPSEC, X.509 PKI) can be 1077 employed approriately to provide the above security functions. 1079 In addition, to defend against the DDoS attack caused by a lot of 1080 NSFs sending massive monitoring information to the security 1081 controller, the rate limiting or similar mechanisms should be 1082 considered in NSF and security controller, whether in advance or just 1083 in the process of DDoS attack. 1085 10. Acknowledgements 1087 11. References 1089 11.1. Normative References 1091 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1092 Requirement Levels", BCP 14, RFC 2119, 1093 DOI 10.17487/RFC2119, March 1997, 1094 . 1096 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 1097 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 1098 September 2004, . 1100 [RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion 1101 Detection Message Exchange Format (IDMEF)", RFC 4765, 1102 DOI 10.17487/RFC4765, March 2007, 1103 . 1105 11.2. Informative References 1107 [I-D.ietf-i2nsf-framework] 1108 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1109 Kumar, "Framework for Interface to Network Security 1110 Functions", draft-ietf-i2nsf-framework-04 (work in 1111 progress), October 2016. 1113 [I-D.xia-i2nsf-capability-interface-im] 1114 Xia, L., Strassner, J., Li, K., Zhang, D., Lopez, E., 1115 Bouthors, N., and L. Fang, "Information Model of Interface 1116 to Network Security Functions Capability Interface", 1117 draft-xia-i2nsf-capability-interface-im-06 (work in 1118 progress), July 2016. 1120 Authors' Addresses 1122 Liang Xia 1123 Huawei 1125 Email: frank.xialiang@huawei.com 1127 Dacheng Zhang 1128 Huawei 1130 Email: dacheng.zhang@huawei.com 1131 Yi Wu 1132 Aliababa Group 1134 Email: anren.wy@alibaba-inc.com 1136 Rakesh Kumar 1137 Juniper Networks 1139 Email: rkkumar@juniper.net 1141 Anil Lohiya 1142 Juniper Networks 1144 Email: alohiya@juniper.net 1146 Henk Birkholz 1147 Fraunhofer SIT 1149 Email: henk.birkholz@sit.fraunhofer.de