Just want to add a concrete example of Analyzer needing other network domain security intelligence. For example NSFs within AWS VPC needing Analytics from AWS Cloud Watch: AWS re:Inforce 2019: The Fundamentals of AWS Cloud Security (FND209-R) - YouTube<https://www.youtube.com/watch?v=-ObImxw1PmI>
[cid:[email protected]] My two cents. Linda Dunbar From: [email protected] <[email protected]> Sent: Wednesday, December 15, 2021 12:38 AM To: Diego R. Lopez <[email protected]>; Mr. Jaehoon Paul Jeong <[email protected]>; chenmeiling <[email protected]>; Patrick Lingga <[email protected]>; ANTONIO AGUSTIN PASTOR PERALES <[email protected]>; Linda Dunbar <[email protected]> Cc: skku-iotlab-members <[email protected]> Subject: Re: Proposed extended charter for I2NSF Hi Diego and all， Generally I think the outline of charter is fine, but three suggestions I think are useful for the development of NSF. * Cross-domain security intelligence sharing. Take the example of Analyzer, Analyzer may need other network domain's security intelligence as reference to make decision, or it wants to share its threat intelligence to cooperate with partner to promote the security capability of NSF. The requirements of this threat intelligence sharing mechanism should be auditable, undeniable and tamper-resistant. Block-chain based architecture is one of the proper solutions. Finally, the NSF architecture could be used and spread in a more wide range like cross-company, cross-domain, or even cross-country cooperation. And I do think NSF with this mechanism will be much more viable. In order to achieve that, we need to design the future NSF architecture with redundancy and flexibility that could be used to expand and develop. * New technologies keep emerging up, like confidential computing, homomorphic encryption, computing in network, etc. We don't have to adopt these new techs to NSF immediately, but pay attention to them maybe helpful. * Do we have to restrict the deliverables as the listed documents, or the listed documents are not used for ruling out other documents. BR Penglin From: Diego R. Lopez<mailto:[email protected]> Date: 2021-12-14 15:51 To: [email protected]<mailto:[email protected]>; Mr. Jaehoon Paul Jeong<mailto:[email protected]>; chenmeiling<mailto:[email protected]>; Patrick Lingga<mailto:[email protected]>; ANTONIO AGUSTIN PASTOR PERALES<mailto:[email protected]>; Linda Dunbar<mailto:[email protected]> CC: skku-iotlab-members<mailto:[email protected]> Subject: Proposed extended charter for I2NSF Hi, As mentioned during our call today, this is the extended charter we are planning to propose for I2NSF: 8< ------------------------------------------------------------------------------------------------------------------------------ <I2NSF WG Re-chartering Text> Interface to Network Security Functions (I2NSF) provides security function vendors, users, and operators with a standard framework and interfaces for cloud-based security services. I2NSF enables the enforcement of a high-level security policy, which is expressed according to a user's perspective of the target network. This security policy enforcement in I2NSF is a data-driven approach using NETCONF/YANG or RESTCONF/YANG, where a security policy is constructed based on a YANG data model. The current I2NSF framework consists of four components such as I2NSF User, Security Controller, Network Security Function (NSF), and Developer's Management System (DMS). The I2NSF User specifies a high-level security policy for a target network. The Security Controller is aware of the capabilities of the attached NSFs, using them to build the security service(s) satisfying the policy expressed by the I2NSF User. An NSF provides a set of specific security capabilities (e.g., firewalling, web filtering, packet inspection, and DDoS-attack mitigation), applying security policy rules. The DMS registers the capabilities of an NSF with the Security Controller. The current I2NSF framework has four interfaces such as Consumer-Facing Interface, NSF-Facing Interface, Registration Interface, and Monitoring Interface. Consumer-Facing Interface is used to deliver high-level security policies from the I2NSF User to the Security Controller. NSF-Facing Interface is used to deliver low-level security policies from the Security Controller to an NSF. The Registration Interface is used to register the capabilities of an NSF with the Security Controller. The Monitoring Interface is used to collect monitoring data from an NSF. The goal of I2NSF is to define a set of software interfaces and data models of such interfaces for configuring, maintaining, and monitoring NSFs in cloud environments, including NFV and edge deployments. For security management automation in an autonomous security system, I2NSF needs to have a feedback control loop consisting of security policy configuration in an NSF, monitoring for an NSF, data analysis for NSF monitoring data, feedback delivery, and security policy augmentation/generation. For this security management automation, the I2NSF framework requires a new component to collect NSF monitoring data and analyze them, which is called I2NSF Analyzer. Also, the I2NSF framework needs a new interface to deliver feedback messages for security policy adjustment from I2NSF Analyzer to Security Controller. A proper translation of the planned actions onto NSF capabilities requires a well-defined model for representing these actions. I2NSF is vulnerable to inside and supply chain attacks since it trusts NSF capability declarations as provided by DMS, assuming that NSFs work appropriately in all circumstances, as well as I2NSF User’s policy declarations and the actions of the Security Controller. The registration of NSF capabilities, the declaration of a security policy from either the I2NSF User or its enforcement by the Security Controller, and the monitoring data from an NSF are assumed to be genuine and non-malicious. If one of such activities is malicious, the security system based on I2NSF may collapse. To prevent this malicious activity from happening in the I2NSF framework or detect the root of a security attack, all the activities in the I2NSF framework should be logged in either a centralized or decentralized (e.g., blockchain) way. Also, the provenance and status of the I2NSF components (i.e., I2NSF User, Security Controller, NSF, DMS, and I2NSF Analyzer) need to be verified by remote attestation. In addition, the impact of new mechanisms for establishing roots of trust (like QKD), providing crypto capabilities (like PQC), modeling and recording events (like done with DLT) or implementing data paths and computational services (as supported by in-network computing) needs to be evaluated. When it comes to modeling, the current YANG data models for the I2NSF interfaces are designed on the basis of NSFs implemented as virtual machines, and therefore they need to be redesigned for the case where I2NSF components are instantiated by containers, and to address the implications of their deployment in cloud-native environments. Finally, an adaptation of the current capability model to this new environment, especially focused to support translation and automated management, will have to be considered. The I2NSF working group's deliverables include: o A single document for an extension of I2NSF framework for security management automation. This document will initially be produced for reference as a living list to track and record discussions: the working group may decide to not publish this document as an RFC. o A YANG data model document for I2NSF Application Interface to deliver feedback from I2NSF Analyzer to Security Controller. o A single document for applicability and use cases in I2NSF-based security management automation. o A single document for a framework for security policy translation to support the mapping between a high-level YANG module and a low-level YANG module: the working group may decide to not publish this document as an RFC. This document will apply the recommendations under discussion in NETMOD and OPSAWG on event modeling. o A single document for remote attestation for I2NSF components, based on the work of the RATS WG. o A single document for I2NSF on container deployments in a cloud native NFV architecture. o A single document providing an extended I2NSF capability model. -------------- Milestones o July 2022: Adopt applicability and use cases in I2NSF-based security management automation as WG document o July 2022: Adopt remote attestation for I2NSF components as WG document o March 2023: Adopt I2NSF on container deployments in a cloud native NFV architecture as WG document o November 2023: Adopt a framework for security policy translation as WG document o November 2023: Adopt a YANG data model for I2NSF Application Interface as WG document o March 2024: Adopt an extension of I2NSF framework for security management automation as WG document ------------------------------------------------------------------------------------------------------------------------------- >8 Let me know what you think. If you confirm you agree with it, my plan would be to share it on the I2NSF list before the Christmas break. You’d be expected to express your support. I hope that, if we can show our AD a sufficient number of support expressions, the WG will be rechartered and support the ongoing and future work on attestation, automation and cloud-nativeness. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fdr2lopez%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfa51c2dfd48f485f273608d9bf957f73%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637751471094324354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a09McbG3%2BswhSuv0f%2FJrpopCWHRO5obIydHD%2B6XKwww%3D&reserved=0> e-mail: [email protected]<mailto:[email protected]> Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
