idnits 2.17.1 draft-jeong-i2nsf-security-management-automation-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 February 2022) is 794 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-16 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-20 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-14 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-14 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-06 == Outdated reference: A later version (-16) exists of draft-yang-i2nsf-security-policy-translation-10 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft P. Lingga 4 Intended status: Informational Sungkyunkwan University 5 Expires: 25 August 2022 J. Park 6 ETRI 7 21 February 2022 9 An Extension of I2NSF Framework for Security Management Automation in 10 Cloud-Based Security Services 11 draft-jeong-i2nsf-security-management-automation-03 13 Abstract 15 This document describes an extension of the framework of Interface to 16 Network Security Functions (I2NSF) for Security Management Automation 17 (SMA) in cloud-based security services. The security management 18 automation in this document deals with a security polity translation 19 and a feedback-based security service enforcement. To support these 20 two features in SMA, this document specifies an augmented 21 architecture of the I2NSF framework with a new system component and a 22 new interface. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 25 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. I2NSF Framework for Security Management Automation . . . . . 4 60 3.1. Components with I2NSF Framework for Security Management 61 Automation . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Interfaces with SMA-Based I2NSF Framework . . . . . . . . 5 63 4. Inter-Interface Automatic Policy Mapping . . . . . . . . . . 6 64 5. Security Audit System . . . . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 8.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 71 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 72 Appendix C. Changes from 73 draft-jeong-i2nsf-security-management-automation-02 . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Interface to Network Security Functions (I2NSF) defines a framework 79 and interfaces for interacting with Network Security Functions (NSFs) 80 [RFC8192][RFC8329]. Note that an NSF is defined as software that 81 provides a set of security-related services, such as (i) detecting 82 unwanted activity, (ii) blocking or mitigating the effect of such 83 unwanted activity in order to fulfill service requirements, and (iii) 84 supporting communication stream integrity and confidentiality 85 [RFC8329]. The NSF can be implemented as a Virtual Network Function 86 (VNF) in a Network Functions Virtualization (NFV) environment 87 [ETSI-NFV][I-D.ietf-i2nsf-applicability]. 89 This document describes an extension of the framework of Interface to 90 Network Security Functions (I2NSF) for Security Management Automation 91 (SMA) in cloud-based security services. The security management 92 automation includes a security polity translation and a feedback- 93 based security service enforcement. This document specifies an 94 augmented architecture of the I2NSF framework for the SMA services 95 with a new system component and a new interface. 97 For reliable management for networked security services, this 98 document proposes a network management and verification facility 99 using a decentralized audit system (e.g., blockchain [Bitcoin]). 100 This audit system can facilitate the non-repudiation of configuration 101 commands and monitoring data generated in the I2NSF framework. 103 Therefore, with the security service automation, this document 104 facilitates the foundation of Intent-Based Networking (IBN) for 105 intelligent security services 106 [I-D.irtf-nmrg-ibn-concepts-definitions]. 108 2. Terminology 110 This document uses the terminology described in [RFC8329] and 111 [I-D.ietf-i2nsf-applicability]. In addition, the following terms are 112 defined below: 114 * Security Management Automation (SMA): It means that a high-level 115 security policy from a user (or administrator) is well-enforced in 116 a target I2NSF system. The high-level security policy can be 117 translated into the corresponding low-level security policy by a 118 security policy translator and dispatched to appropriate NSFs. 119 Through the monitoring of the NSFs, the activity and performace of 120 the NSFs is monitored and analyzed. If needed, the security rules 121 of the low-level security policy are augmented or new security 122 rules are generated and configured to appropriate NSFs. 124 * Security Policy Translation (SPT): It means that a high-level 125 security policy is translated to a low-level security policy that 126 can be understood and configured by an NSF for a specific security 127 service, such as firewall, web filter, deep packet inspection, 128 DDoS-attack mitigation, and anti-virus. 130 * Feedback-Based Security Management (FSM): It means that a security 131 service is evolved by updating a security policy (having security 132 rules) and adding new security rules for detected security attacks 133 by processing and analzing the monitoring data of NSFs. 135 +------------+ 136 | I2NSF User | 137 +------------+ 138 ^ 139 | Consumer-Facing Interface 140 v 141 +-------------------+ Registration +-----------------------+ 142 |Security Controller|<-------------------->|Developer's Mgmt System| 143 +-------------------+ Interface +-----------------------+ 144 ^ ^ 145 | | 146 | | Application Interface +-----------------------+ 147 | +------------------------>| I2NSF Analyzer | 148 | +-----------------------+ 149 | NSF-Facing Interface ^ ^ ^ 150 | | | | 151 | | | | 152 | +------------------------------+ | | 153 | | +-----------------------+ | 154 | | | Monitoring Interface | 155 v v v v 156 +----------------+ +---------------+ +-----------------------+ 157 | NSF-1 |-| NSF-2 |...| NSF-n | 158 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 159 +----------------+ +---------------+ +-----------------------+ 161 Figure 1: I2NSF Framework for Security Management Automation 163 3. I2NSF Framework for Security Management Automation 165 This section summarizes the I2NSF framework as defined in [RFC8329]. 166 As shown in Figure 1, an I2NSF User can use security functions by 167 delivering high-level security policies, which specify security 168 requirements that the I2NSF user wants to enforce, to the Security 169 Controller via the Consumer-Facing Interface (CFI) 170 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 172 3.1. Components with I2NSF Framework for Security Management Automation 174 The following are the system components for the SMA-based I2NSF 175 framework. 177 * I2NSF User: An entity that delivers a high-level security policy 178 to Security Controller. 180 * Security Controller: An entity that controls and manages other 181 system components in the I2NSF framework. It translates a high- 182 level security policy into the corresponding low-level security 183 policy and selects appropriate NSFs to execute the security rules 184 of the low-level security policy. 186 * Developer's Management System (DMS): An entity that provides an 187 image of of a virtualized NSF for a security service to the I2NSF 188 framework, and registers the capability and access information of 189 an NSF with Security Controller. 191 * Network Security Function (NSF): An entity that is a Virtual 192 Network Function (VNF) for a specific network security service 193 such as firewall, web filter, deep packet inspection, DDoS-attack 194 mitigation, and anti-virus. 196 * I2NSF Analyzer: An entity that collects monitoring data from NSFs 197 and analyzes such data for checking the activity and performance 198 of the NSFs using machine learning techniques (e.g., Deep Learning 199 [Deep-Learning]). If there is a suspicious attack activity for 200 the target network or NSF, I2NSF Analyzer delivers a report of the 201 augmentation or generation of security rules to Security 202 Controller. 204 For SMA-based security services with Feedback-Based Security 205 Management (FSM), I2NSF Analyzer as a new I2NSF component is required 206 for the legacy I2NSF framework [RFC8329] to collect monitoring data 207 of NSFs and analyzing them. The actual implementation of monitoring 208 data analysis is out of the scope of this document. 210 3.2. Interfaces with SMA-Based I2NSF Framework 212 The following are the interfaces for the SMA-based I2NSF framework. 213 Note that the interfaces are modeled with YANG [RFC6020] and security 214 policies are delivered through either RESTCONF [RFC8040] or NETCONF 215 [RFC6241]. 217 * Consumer-Facing Interface: An interface between I2NSF User and 218 Security Controller for the delivery of a high-level security 219 policy [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 221 * NSF-Facing Interface: An interface between Security Controller and 222 an NSF for the delivery of a low-level security policy 223 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 225 * Registration Interface: An interface between a DMS and Security 226 Controller for the registration of an NSF's capability and access 227 information with the Security Controller or the query of an NSF 228 for a required low-level security policy 229 [I-D.ietf-i2nsf-registration-interface-dm]. 231 * Monitoring Interface: An interface between an NSF and I2NSF 232 Analyzer for collecting monitoring data from an NSF to check the 233 activity and performance of an NSF for a possible malicious 234 traffic [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 236 * Application Interface: An interface between I2NSF Analyzer and 237 Security Controller for the delivery of a report of the 238 augmentation or generation of security rules to Security 239 Controller, which lets Security Controller apply the report for 240 security rules to its security policy management. 242 For SMA-based security services with FSM, Application Interface as a 243 new I2NSF interface is required for the legacy I2NSF framework 244 [RFC8329] to deliver a report of the augmentation or generation of 245 security rules to Security Controller on the basis of the analyzed 246 monitoring data of NSFs. 248 4. Inter-Interface Automatic Policy Mapping 250 To facilitate Security Policy Translation (SPT), Security Controller 251 needs to have a security policy translator that performs the 252 translation of a high-level security policy into the corresponding 253 low-level security policy. For the automatic SPT services, the I2NSF 254 framework needs to bridge a high-level YANG data model and a low- 255 level YANG data model in an automatic manner [I-D.ietf-i2nsf-applicab 256 ility][I-D.yang-i2nsf-security-policy-translation]. Note that a 257 high-level YANG data model is for the I2NSF Consumer-Facing Interface 258 [I-D.ietf-i2nsf-consumer-facing-interface-dm], and a low-level YANG 259 data model is for the I2NSF NSF-Facing Interface 260 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 262 Figure 2 shows automatic mapping of high-level and low-level data 263 models. Automatic Data Model Mapper takes a high-level YANG data 264 module for the Consumer-Facing Inteface and a low-level YANG data 265 module for the NSF-Facing Interface. It then constructs a mapping 266 table associating the data attributes (or variables) of the high- 267 level YANG data module with the corresponding data attributes (or 268 variables) of the low-level YANG data module. Also, it generates a 269 set of production rules of the grammar for the construction of an XML 270 file of low-level security policy rules. 272 Figure 3 shows high-to-low security policy translation. A security 273 policy translator is a component of Security Controller. The 274 translator consists of three components such as Policy Data 275 Extractor, Policy Attribute Mapper, and Policy Constructor. 277 High-level YANG Data Module Low-level YANG Data Model 278 | | 279 V V 280 +---------+------------------------------+---------+ 281 | Automatic Data Model Mapper | 282 +------------------------+-------------------------+ 283 | 284 V 285 Data Model Mapping Table 287 Figure 2: Automatic Mapping of High-level and Low-level Data Models 288 +--------------------------------------------------+ 289 | | 290 | I2NSF User | 291 | | 292 +------------------------+-------------------------+ 293 | Consumer-Facing Interface 294 | 295 High-level Security Policy 296 Security | 297 Controller V 298 +------------------------+-------------------------+ 299 | Security Policy | | 300 | Translator V | 301 | +---------------------+----------------------+ | 302 | | | | 303 | | +-------------------------+ | | 304 | | | Policy Data Extractor | | | 305 | | +-------------------------+ | | 306 | | | | 307 | | +-------------------------+ | | 308 | | | Policy Attribute Mapper | | | 309 | | +-------------------------+ | | 310 | | | | 311 | | +-------------------------+ | | 312 | | | Policy Constructor | | | 313 | | +-------------------------+ | | 314 | | | | 315 | +---------------------+----------------------+ | 316 | | | 317 | V | 318 +------------------------+-------------------------+ 319 | NSF-Facing Interface 320 | 321 Low-level Security Policy 322 | 323 V 324 +------------------------+-------------------------+ 325 | | 326 | NSF(s) | 327 | | 328 +--------------------------------------------------+ 330 Figure 3: High-to-Low Security Policy Translation 332 Policy Data Extractor extracts attributes related to a security 333 policy from a high-level security policy XML file that is delivered 334 from an I2NSF User to a Security Controller 335 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 337 Policy Attribute Mapper maps the attributes and their values of a 338 high-level security policy to the corresponding attributes and their 339 values of a low-level security policy. Note that the values of a 340 high-level security policy may involve a human language and must be 341 converted to an appropriate value for a low-level security policy 342 (e.g., employees -> 192.0.1.0/24). 344 Policy Constructor constructs a low-level security policy XML file 345 that is delivered from the Security Controller to an appropriate NSF 346 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 348 5. Security Audit System 350 The I2NSF framework is weak to both an inside attack and a supply 351 chain attack since it trusts in NSFs provided by Developer's 352 Management System (DMS) and assumes that NSFs work for their security 353 services appropriately. [I-D.ietf-i2nsf-applicability]. 355 To detect the malicious activity of either an insider attacker with 356 its DMS or a supply chain attacker with its compromised DMS, a 357 security audit system is required for the I2NSF framework. For this 358 audit service in the I2NSF framework, a decentralized security audit 359 system (e.g., blockchain [Bitcoin]) is required. This audit system 360 can facilitate the non-repudiation of configuration commands and 361 monitoring data generated in the I2NSF framework. 363 A security audit system has four main objectives such as follows: 365 * To check the existence of a security policy, a management system 366 and its procedures; 368 * To identify and understand the existing vulnerabilities and risks 369 of a supply chain attacker; 371 * To review existing security controls on operational, 372 administrative and managerial issues; 374 * To provide recommendations and corrective actions for further 375 improvement. 377 +-----------------------------+ +----------------+ 378 | I2NSF User | |Developer's Mgmt| 379 | +------------+ | System | 380 +--------------+--------------+ | +--------+-------+ 381 | Consumer-Facing Interface | | 382 | | | 383 High-level Security Policy | | 384 | | | 385 | | | 386 V | V 387 +--------------+--------------+ | +---------+--------+ 388 | | V | Security | 389 | Security Controller +------------+---->| Audit | 390 | | ^ | System | 391 +--------------+--------------+ | |(e.g., Blockchain)| 392 | NSF-Facing Interface | +---------+--------+ 393 | | ^ 394 Low-level Security Policy | | 395 | | | 396 V | | 397 +--------------+--------------+ | +--------+-------+ 398 | NSF(s) | | | I2NSF Analyzer | 399 | +------------+ | | 400 +-----------------------------+ +----------------+ 402 Figure 4: Activity Auditing with Security Audit System 404 Figure 4 shows activity auditing with a security audit system in the 405 I2NSF framework. All the components in the I2NSF framwork report its 406 activities (such as configuration commands and monitoring data) to 407 Security Audit System (e.g., Blockchain) as transactions. The 408 security audit system can analyze the reported activities from the 409 I2NSF components to detect malicious activities such as supply chain 410 attack. 412 In order to determine a minimum set of controls required to reduce 413 the risks from a supply chain attacker, the security audit system 414 should analyze the activities of all the components in the I2NSF 415 framework periodically, evaluate possible risks, and take an action 416 to such risks since vulnerabilities and threats may change in 417 different environments over time. 419 6. Security Considerations 421 The same security considerations for the I2NSF framework [RFC8329] 422 are applicable to this document. 424 The development and introduction of I2NSF Analyzer in the I2NSF 425 Framework will create new security concerns that have to be 426 anticipated at the design and specification time. The usage of 427 machine learning to analyze the data add a risk of its model to be 428 attacked (e.g., adversarial attack) and can result in a bad security 429 policy being deployed. 431 7. IANA Considerations 433 This document does not require any IANA actions. 435 8. References 437 8.1. Normative References 439 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 440 and J. Jeong, "Interface to Network Security Functions 441 (I2NSF): Problem Statement and Use Cases", RFC 8192, 442 DOI 10.17487/RFC8192, July 2017, 443 . 445 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 446 Kumar, "Framework for Interface to Network Security 447 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 448 . 450 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 451 the Network Configuration Protocol (NETCONF)", RFC 6020, 452 DOI 10.17487/RFC6020, October 2010, 453 . 455 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 456 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 457 . 459 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 460 and A. Bierman, Ed., "Network Configuration Protocol 461 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 462 . 464 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 465 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 466 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 467 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 468 facing-interface-dm-16, 28 January 2022, 469 . 472 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 473 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 474 "I2NSF Network Security Function-Facing Interface YANG 475 Data Model", Work in Progress, Internet-Draft, draft-ietf- 476 i2nsf-nsf-facing-interface-dm-20, 31 January 2022, 477 . 480 [I-D.ietf-i2nsf-registration-interface-dm] 481 Hyun, S., Jeong, J. (., Roh, T., Wi, S., and J. Park, 482 "I2NSF Registration Interface YANG Data Model", Work in 483 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 484 interface-dm-14, 28 January 2022, 485 . 488 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 489 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 490 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 491 Model", Work in Progress, Internet-Draft, draft-ietf- 492 i2nsf-nsf-monitoring-data-model-14, 28 January 2022, 493 . 496 8.2. Informative References 498 [I-D.ietf-i2nsf-applicability] 499 Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. R. 500 Lopez, "Applicability of Interfaces to Network Security 501 Functions to Network-Based Security Services", Work in 502 Progress, Internet-Draft, draft-ietf-i2nsf-applicability- 503 18, 16 September 2019, . 506 [I-D.irtf-nmrg-ibn-concepts-definitions] 507 Clemm, A., Ciavaglia, L., Granville, L. Z., and J. 508 Tantsura, "Intent-Based Networking - Concepts and 509 Definitions", Work in Progress, Internet-Draft, draft- 510 irtf-nmrg-ibn-concepts-definitions-06, 15 December 2021, 511 . 514 [I-D.yang-i2nsf-security-policy-translation] 515 Jeong, J. (., Lingga, P., Yang, J., and C. Chung, 516 "Security Policy Translation in Interface to Network 517 Security Functions", Work in Progress, Internet-Draft, 518 draft-yang-i2nsf-security-policy-translation-10, 21 519 February 2022, . 522 [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural 523 Framework", Available: 524 https://www.etsi.org/deliver/etsi_gs/ 525 nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October 526 2013. 528 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 529 System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. 531 [Deep-Learning] 532 Goodfellow, I., Bengio, Y., and A. Courville, "Deep 533 Learning", Publisher: The MIT Press, 534 URL: https://www.deeplearningbook.org/, November 2016. 536 Appendix A. Acknowledgments 538 This work was supported in part by Institute of Information & 539 Communications Technology Planning & Evaluation (IITP) grant funded 540 by the Korea Ministry of Science and ICT (MSIT) (2020-0-00395, 541 Standard Development of Blockchain based Network Management 542 Automation Technology). This work was supported by the IITP grant 543 funded by the Korea MSIT (R-20160222-002755, Cloud based Security 544 Intelligence Technology Development for the Customized Security 545 Service Provisioning). 547 Appendix B. Contributors 549 This document is made by the group effort of I2NSF working group. 550 Many people actively contributed to this document, such as Linda 551 Dunbar, Yoav Nir, and Qin Wu. The authors sincerely appreciate their 552 contributions. 554 The following are co-authors of this document: 556 Yunchul Choi Electronics and Telecommunications Research Institute 557 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 558 cyc79@etri.re.kr 559 Younghan Kim School of Electronic Engineering Soongsil University 560 369, Sangdo-ro, Dongjak-gu Seoul 06978 Republic of Korea EMail: 561 younghak@ssu.ac.kr 563 Appendix C. Changes from draft-jeong-i2nsf-security-management- 564 automation-02 566 The following changes are made from draft-jeong-i2nsf-security- 567 management-automation-02: 569 * This version is updated to fix the typos and clarify the text 570 explaining Policy Attribute Mapper. 572 * Add a new Security Consideration for machine learning usage to 573 produce a security policy. 575 Authors' Addresses 577 Jaehoon (Paul) Jeong 578 Department of Computer Science and Engineering 579 Sungkyunkwan University 580 2066 Seobu-Ro, Jangan-Gu 581 Suwon 582 Gyeonggi-Do 583 16419 584 Republic of Korea 585 Phone: +82 31 299 4957 586 Email: pauljeong@skku.edu 587 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 589 Patrick Lingga 590 Department of Electronic, Electrical and Computer Engineering 591 Sungkyunkwan University 592 2066 Seobu-Ro, Jangan-Gu 593 Suwon 594 Gyeonggi-Do 595 16419 596 Republic of Korea 597 Phone: +82 31 299 4957 598 Email: patricklink@skku.edu 599 Jung-Soo Park 600 Electronics and Telecommunications Research Institute 601 218 Gajeong-Ro, Yuseong-Gu 602 Daejeon 603 305-700 604 Republic of Korea 605 Phone: +82 42 860 6514 606 Email: pjs@etri.re.kr