Method for generating security policy, and communication device

Abstract

The present application provides a method for generating a security policy, and a communication device. The method comprises: a security policy network element generates a security policy, the security policy being associated with a service of a terminal device; and the security policy network element sends the security policy to a policy enforcement network element.

Description

Method and communication device for generating security policy Technical Field

[0001] The present application relates to the field of communication technology, and more particularly, to a method for generating a security policy and a communication device. Background Art

[0002] To ensure the security of the communication system, devices in the communication system can use security policies to communicate. Security policies can be generated by network elements in the zero trust architecture (such as security policy network elements).

[0003] Currently, security policy network elements generate security policies based on network status. However, with the continuous evolution of communication systems, this generation method can no longer meet the security requirements of communication systems.

[0004] Summary of the Invention

[0005] The present application provides a method and communication device for generating a security policy. The following describes several aspects of the present application in detail.

[0006] In a first aspect, a method for generating a security policy is provided, comprising: a security policy network element generating a security policy, wherein the security policy is associated with a service of a terminal device; and the security policy network element sending the security policy to a policy execution network element.

[0007] According to a second aspect, a method for generating a security policy is provided, comprising: a policy execution network element sends a first request message to a first network element, wherein the first request message is used to request a security policy, wherein the security policy is associated with the service of the terminal device, and the first network element includes a security policy network element and / or a policy detection network element; and the policy execution network element receives the security policy from the security policy network element.

[0008] According to a third aspect, a method for generating a security policy is provided, including: a policy detection network element receives a first request message from a policy execution network element, the first request message being used to request a security policy; in response to the first request message, the policy detection network element generates a security requirement corresponding to the service of the terminal device; the policy detection network element sends the security requirement to a security policy network element, and the security requirement is used by the security policy network element to generate the security policy.

[0009] In a fourth aspect, a method for generating a security policy is provided, comprising: a terminal device sends a first indication message to a policy execution network element, wherein the first indication message is used to indicate that a service of the terminal device has changed; the terminal device receives a security policy from the policy execution network element, wherein the security policy is associated with the service of the terminal device.

[0010] In a fifth aspect, a communication device is provided, which is a security policy network element, and includes: a generation unit for generating a security policy, wherein the security policy is associated with the service of the terminal device; and a sending unit for sending the security policy to the policy execution network element.

[0011] In the sixth aspect, a communication device is provided, which is a policy execution network element, and the communication device includes: a sending unit, used to send a first request message to a first network element, the first request message is used to request a security policy, the security policy is associated with the service of the terminal device, and the first network element includes a security policy network element and / or a policy detection network element; a receiving unit, used to receive the security policy from the security policy network element.

[0012] In the seventh aspect, a communication device is provided, which is a policy detection network element, and the communication device includes: a receiving unit, used to receive a first request message from a policy execution network element, the first request message is used to request a security policy; a generating unit, used to generate a security requirement corresponding to the service of the terminal device in response to the first request message; and a sending unit, used to send the security requirement to the security policy network element, the security requirement is used by the security policy network element to generate the security policy.

[0013] In the eighth aspect, a communication device is provided, which is a terminal device, and the communication device includes: a sending unit, used to send first indication information to a policy execution network element, the first indication information is used to indicate that the service of the terminal device has changed; a receiving unit, used to receive a security policy from the policy execution network element, the security policy is associated with the service of the terminal device.

[0014] With the continuous evolution of communication systems, the business scenarios in communication systems are becoming more and more abundant. This application can generate security policies associated with the business of terminal devices, so that the generated security policies can match the business of terminal devices to meet the security requirements of communication systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG1 is a wireless communication system 100 used in an embodiment of the present application.

[0016] Figure 2 is a schematic diagram of the structure of a traditional zero-trust architecture.

[0017] Figure 3 is a structural diagram of an intelligent zero-trust architecture.

[0018] FIG4 is a schematic flowchart for generating a security policy provided in an embodiment of the present application.

[0019] FIG5 is another schematic flowchart for generating a security policy provided in an embodiment of the present application.

[0020] FIG6 is another schematic flowchart for generating a security policy provided in an embodiment of the present application.

[0021] FIG7 is another schematic flowchart for generating a security policy provided in an embodiment of the present application.

[0022] FIG8 is a structural diagram of a zero-trust architecture provided in an embodiment of the present application.

[0023] FIG9 is a schematic diagram of the structure of another zero-trust architecture provided in an embodiment of the present application.

[0024] FIG10 is a schematic flowchart of generating a security policy provided in an embodiment of the present application.

[0025] FIG11 is a schematic flowchart of another method for generating a security policy according to an embodiment of the present application.

[0026] FIG12 is a schematic block diagram of a communication device provided in an embodiment of the present application.

[0027] FIG13 is a schematic block diagram of another communication device provided in an embodiment of the present application.

[0028] FIG14 is a schematic block diagram of another communication device provided in an embodiment of the present application.

[0029] Figure 15 is a schematic block diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] The technical solution in this application will be described below with reference to the accompanying drawings.

[0031] Figure 1 illustrates a wireless communication system 100 used in an embodiment of the present application. The wireless communication system 100 may include a network device 110 and a terminal device 120. The network device 110 may be a device that communicates with the terminal device 120. The network device 110 may provide communication coverage for a specific geographic area and may communicate with the terminal device 120 within the coverage area.

[0032] FIG1 exemplarily shows a network device and two terminal devices. Optionally, the wireless communication system 100 may include multiple network devices and each network device may include another number of terminal devices within its coverage area, which is not limited in this embodiment of the present application.

[0033] Optionally, the wireless communication system 100 may further include other network entities such as a network controller and a mobility management entity, which is not limited in the embodiment of the present application.

[0034] It should be understood that the technical solutions of the embodiments of the present application can be applied to various communication systems, such as: fifth generation (5G) system or new radio (NR), long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD), etc. The technical solutions provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system, satellite communication system, etc.

[0035] The terminal device in the embodiments of the present application may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device. The terminal device in the embodiments of the present application may refer to a device that provides voice and / or data connectivity to a user and can be used to connect people, objects and machines, such as a handheld device with wireless connection function, a vehicle-mounted device, etc. The terminal device in the embodiments of the present application can be a mobile phone, a tablet computer, a laptop computer, a PDA, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. Optionally, the UE can be used to act as a base station. For example, the UE can act as a scheduling entity that provides sidelink signals between UEs in vehicle-to-everything (V2X) or device-to-device (D2D). For example, a cellular phone and a car communicate with each other using sidelink signals. The cellular phone and smart home devices communicate without relaying the communication signal through a base station.

[0036] The network device in the embodiment of the present application may be a device for communicating with a terminal device, and the network device may also be referred to as an access network device or a wireless access network device, such as a network device may be a base station. The network device in the embodiment of the present application may refer to a radio access network (RAN) node (or device) that connects a terminal device to a wireless network. A base station may broadly cover various names as follows, or be replaced with the following names, such as: Node B (NodeB), evolved NodeB (eNB), next generation NodeB (gNB), relay station, transmission point (TRP), transmitting point (TP), master station MeNB, auxiliary station SeNB, multi-standard radio (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, etc. A base station may be a macro base station, a micro base station, a relay node, a donor node or the like, or a combination thereof. A base station may also refer to a communication module, a modem or a chip for being arranged in the aforementioned device or apparatus. The base station can also be a mobile switching center and a device that performs base station functions in device-to-device (D2D), V2X, and machine-to-machine (M2M) communications, a network-side device in a 6G network, or a device that performs base station functions in future communication systems. The base station can support networks with the same or different access technologies. The embodiments of this application do not limit the specific technology and specific device form used by the network device.

[0037] Base stations can be fixed or mobile. For example, a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move based on the location of the mobile base station. In other examples, a helicopter or drone can be configured to act as a device that communicates with another base station.

[0038] In some deployments, the network device in the embodiments of the present application may refer to a CU or a DU, or the network device may include a CU and a DU. The gNB may also include an AAU.

[0039] The network equipment and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on the water; they can also be deployed in the air on aircraft, balloons, or satellites. The embodiments of this application do not limit the scenarios in which the network equipment and terminal devices are located.

[0040] It should be understood that all or part of the functions of the communication device in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (such as a cloud platform).

[0041] Zero Trust Architecture

[0042] Zero trust architecture (ZTA) can be referred to as the National Institute of Standards and Technology (NIST) Zero Trust Architecture. The purpose of Zero Trust Architecture is to ensure secure access to network resources by implementing strict access controls and monitoring to respond to the ever-changing threat landscape. This architecture is designed to improve security, reduce reliance on traditional network perimeters, and ensure that data and resources remain secure even in highly dynamic and distributed network environments. The concept of Zero Trust Architecture is that every request in the network is not trusted by default, and every access requires strict authorization and monitoring.

[0043] Referring to Figure 2, the network elements or components in the NIST zero trust architecture may include a policy engine (PE), a policy administrator (PA), and a policy enforcement point (PEP).

[0044] The policy engine is responsible for making the final decision regarding resource access for a given subject. The policy engine can use trust algorithms to grant, deny, or revoke access to resources based on enterprise policy and input from external sources such as continuous diagnostics and mitigation (CDM) systems and threat intelligence services. The policy engine and policy administrators can work together. The policy engine makes decisions and records the results (approval or rejection), and the policy administrator can enforce them.

[0045] A policy administrator may be responsible for establishing and / or closing communication paths between entities and resources. For example, a policy administrator may send commands to a policy enforcement point to establish or close a communication path between a entity and a resource. In some implementations, the policy administrator may communicate with the policy enforcement point to establish the communication path. Communication between the policy administrator and the policy enforcement point may occur via the control plane.

[0046] Policy administrators can generate per-session authentication tokens or credentials that clients can use to access enterprise resources. Policy administrators are closely tied to the policy engine, allowing or denying sessions based on the policy engine's decisions. If the session is authorized and the request is authenticated, the policy administrator can send a command to the policy enforcement point to allow the session to begin. If the session is denied or previous approval is revoked, the policy administrator can send a command to the policy enforcement point to close the connection.

[0047] In some implementations, the policy administrator and the policy engine are two independent components, or the policy administrator and the policy engine are integrated into one component.

[0048] A policy enforcement point can be responsible for enabling, monitoring, and terminating connections between principals and resources. A policy enforcement point can communicate with a policy administrator. A policy enforcement point can forward requests and / or receive policy updates from a policy administrator.

[0049] In a zero-trust architecture, the policy enforcement point is a single logical component, but it can also be divided into two components. For example, the policy enforcement point can include the client and the resource. The client, for example, can be an agent on a terminal device, and the resource, for example, can be a resource front-end gateway component that controls access.

[0050] The above components can communicate through a separate control plane, while application data can be transmitted on the data plane.

[0051] Continuing with Figure 2, the Zero Trust architecture can also include other components. For example, the Zero Trust architecture can also include one or more of the following components: CDM system, industry compliance system, threat intelligence feeds, network and system activity logs, data access policies, identity management system, security information and event management (SIEM) system, and enterprise public key infrastructure (PKI).

[0052] Intelligent Zero Trust Architecture

[0053] Referring to FIG. 3 , components in an intelligent zero trust architecture (i-ZTA) may include an intelligent policy engine (IPE) and an intelligent agent portal (IAP).

[0054] The IPE can be responsible for dynamically authorizing access requests. The IPE can use reinforcement learning algorithms to maximize assurance scores, evaluating and adjusting trust policies in response to real-time observed user or device behavior, network resource access events, and newly detected abnormal behavior. The IAP can support federated learning (FL), a distributed learning method that can share and update models across multiple agents to provide a comprehensive model of the network environment.

[0055] Continuing with Figure 3, the intelligent zero-trust architecture can also include Intelligent Network Security State Analysis (INSSA). INSSA uses a graph neural network (GNN) to model the network and employs adversarial learning for risk assessment. This approach dynamically monitors the security status of network assets and assesses their compliance with security policy rules in real time.

[0056] The operational process of the Intelligent Zero Trust Architecture involves multiple interacting layers. When a device or user attempts to access a network resource, the IPE evaluates the request and decides whether to authorize it based on the current network environment and historical behavioral data. If the device lacks computing power, the IAP intervenes, evaluating and processing the request through a federated learning mechanism. Simultaneously, the INSSA continuously monitors the network status to ensure that all communication behavior complies with security policies. The interaction of these components ensures that security policies are updated and enforced in real time, even as the network environment changes.

[0057] Communication system architecture

[0058] With technological advancements, people are placing increasing demands on communication systems. On the one hand, they hope for higher performance, while on the other hand, they also want a minimalist system to reduce deployment and operating costs. A viable solution is to design multiple subsystems based on a minimalist, common technology core. These subsystems can be decoupled and optimized independently, thus achieving a "minimalist, versatile" communication system with on-demand capabilities and flexible functional combinations.

[0059] The above communication system can be provided with common capabilities by a minimized and simple core, such as endogenous intelligent strategies, security, and flexible spectrum management.

[0060] The above communication system can be specifically optimized for four capability directions: clouding, critical IoT, ubiquitous IoT, and sensing.

[0061] One or more subsystems can be designed for each capability. In some implementations, corresponding key technologies can be selected based on the application scenario, spectrum, interface type, etc., and hardware system design can be performed separately. For example, the subsystems may include one or more of the following: broadband cellular, D2D, ultra reliable low latency communication (URLLC), positioning and perception, large-scale Internet of Things, and space communications.

[0062] The subsystems can choose whether to maintain air interface compatibility as needed, and determine the degree of sharing air interface technology and hardware design with the broadband cellular subsystem as needed.

[0063] This communication system can replace general and complex traditional software algorithms with a black-box, specialized artificial intelligence (AI) algorithm library, achieving relative independence and independent optimization of each subsystem and significantly simplifying the communication protocol. By switching and combining multiple AI algorithms, multiple subsystems can be switched and combined.

[0064] The above communication system can be applied to any communication system, such as a 6G system or a future communication system.

[0065] To ensure the security of the communication system, devices in the communication system can communicate using security policies. Security policies can be generated by network elements in a zero-trust architecture. For example, security policies can be generated by PEs. Furthermore, if security policies need to be updated, PEs can also update them.

[0066] Some communication systems, such as 6G, have introduced a wide variety of services. For example, these scenarios can include smart homes, smart wearables, zero-power devices, the telepathic internet, twin-body area networks, intelligent interaction, intelligent agriculture, intelligent industry, super-energy transportation, precision medicine, universal education, virtual travel, instant rescue, and "no-man's land" detection. This diverse range of service scenarios also poses new challenges to the security of communication systems. Currently, the security policies and service data in zero-trust architectures are insufficiently integrated, and can no longer meet the security requirements of diverse services within communication systems.

[0067] Taking 6G systems as an example, the 6G network environment is expected to achieve deep awareness of service data and network status. This requires security policies to be seamlessly integrated with real-time service data and network status information to achieve accurate risk assessment and policy deployment. While ZTA and i-ZTA allow for data-driven security policy implementation, they have not yet fully achieved in-depth integration with the rich service data and network status information in the 6G network environment. Therefore, in a rapidly changing network environment, current security policies may not fully utilize real-time data for effective risk prediction and response, resulting in inaccurate or ineffective security responses, and failing to fully realize the potential of data-driven security policies.

[0068] In the NIST Zero Trust Architecture, security policy generation and updates rely on pre-set conditions and manual intervention, making security policy deployment and adjustment reactive and lagging, unable to meet dynamically changing business needs. For example, security policies are updated or generated only when pre-set conditions are met. In another example, when security policy updates are necessary, they are performed manually. Although i-ZTA incorporates intelligent components, it does not integrate with business data and only updates security policies based on changes in the network environment.

[0069] In order to solve one or more of the above problems, an embodiment of the present application provides a method for generating a security policy. By associating the security policy with the service of the terminal device, when generating the security policy, a security policy associated with the service of the terminal device can be generated, thereby meeting the security requirements of different services in the communication system.

[0070] The solution of the embodiment of the present application is described in detail below with reference to FIG4 .

[0071] 4 , in step S410 , a security policy network element generates a security policy. The security policy network element may be, for example, a PE. In some embodiments, the security policy network element may be an AI Sec PE.

[0072] It should be noted that, in some implementations, the security policy network element may also be replaced by other terms, such as the security policy network element may be replaced by a policy engine or a policy engine network element.

[0073] In some embodiments, security policies can be associated with the services of terminal devices. For example, a security policy network element can generate a security policy corresponding to the services of the terminal device based on the services of the terminal device. In some implementations, different services can correspond to different security policies. Of course, different services can also correspond to the same security policy, which is not specifically limited in the embodiments of the present application. By integrating service data with security policies, the embodiments of the present application can achieve accurate risk assessment and policy deployment.

[0074] In some implementations, security policies can be updated based on business changes of terminal devices to improve the real-time nature of security policies. For example, a security policy network element can update security policies when the business of a terminal device changes. By triggering the update of security policies by business changes of terminal devices, security policies can respond to changes in business in real time and meet the latency requirements of the communication system. Taking the 6G system as an example, the 6G network is expected to support higher data rates and lower latency, which means that the network environment and business needs will be more dynamic and changeable. The embodiment of the present application updates the security policy based on changes in the business of the terminal device, so that it can respond to dynamic changes in business in real time and generate security policies corresponding to the business of the terminal device.

[0075] Whether the service of the terminal device has changed can be detected by the policy execution network element. In some embodiments, the policy execution network element can detect whether the service of the terminal device has changed. If the service of the terminal device has changed, the policy execution network element can send an indication to the security policy network element to indicate that the service of the terminal device has changed. In some implementations, if the service of the terminal device has changed, the policy execution network element can send a first request message to the security policy network element (such as step S510 in Figure 5), where the first request message is used to request a security policy. After receiving the first request message, the security policy network element can generate a security policy.

[0076] The embodiments of the present application do not specifically limit the policy execution network element, which may also be referred to as a service function network element. The policy execution network element may be a PEP. In some implementations, the policy execution network element may include one or more of the following: application function (AF), network exposure function (NEF), network repository function (NRF), policy control function (PCF), access and mobility management function (AMF), authentication server function (AUSF), base station, user plane function (UPF), edge node, etc.

[0077] In some embodiments, security policies can be updated based on changes in network status. For example, a security policy network element can update or generate a new security policy when network status changes. By integrating security policies with network status information, accurate risk assessment and policy deployment can be achieved.

[0078] In some implementations, the policy execution network element may send the first request message to the security policy network element through the policy management network element. For example, the policy execution network element may send the first request message to the policy management network element, and after receiving the first request message, the policy management network element may forward the first request message to the security policy network element.

[0079] The policy management network element in the embodiment of the present application may be a PA.

[0080] The embodiments of the present application do not specifically limit the manner in which the policy execution network element determines whether a service of a terminal device has changed. As an example, the policy execution network element may monitor the service of the terminal device to determine whether the service of the terminal device has changed. As another example, when a service has changed, the terminal device may send first indication information to the policy execution network element, where the first indication information is used to indicate that the service of the terminal device has changed. In other words, the policy execution network element may determine whether the service of the terminal device has changed based on the indication of the terminal device.

[0081] In some embodiments, although the services of a terminal device have changed, the security policies required for the services before and after the change may be the same. In this case, the security policy network element may not generate or update the security policy to reduce overhead. That is, before generating a security policy, the security policy network element may determine whether a security policy needs to be generated, for example, whether a new security policy is needed or whether an update is needed. If a security policy needs to be generated, the security policy network element generates the security policy; if a security policy does not need to be generated, the security policy network element may not generate the security policy. For example, if the security policy network element determines that a new security policy is needed, the security policy network element generates the new security policy; if the security policy network element determines that a new security policy is not needed, the security policy network element may not generate the new security policy. Alternatively, if the security policy network element determines that a security policy update is needed, the security policy network element updates the security policy; if the security policy network element determines that a security policy update is not needed, the security policy network element may not update the security policy.

[0082] In some embodiments, the business change may include one or more of the following situations: a new business is added, and the current business conditions are changed.

[0083] In some embodiments, the security policy network element may generate a security policy based on a first model. The first model may be any neural network model. For example, the first model may be an AI model or a machine learning (ML) model. In some implementations, the first model may be a deep forest model.

[0084] Deep forest (DF) is a decision tree integration method with a cascade structure, which includes two parts: multi-granularity scanning and cascade forest. Among them, multi-granularity scanning scans the original input features to generate a new feature vector by setting sliding windows of different granularities; cascade forest processes the output of the previous cascade and the original input features to generate the input data of the next cascade. This application can use measure-aware feature reuse (MAFR) and measure-aware layer growth (MALG) to achieve the multi-label output task goal of deep forest. Among them, MAFR selects the input of the next cascade based on the confidence of the output of the previous cascade, and MALG determines whether the cascade layer training is completed based on the optimal evaluation index. Since the deep forest model has a fast training speed and can be easily parallelized and can process large-scale data sets, by using the deep forest model to generate security policies, the speed of generating security policies can be improved and the accuracy of security policies can be guaranteed.

[0085] In some embodiments, the input parameters of the first model may include a system type. This system type may correspond to the services of the terminal device, or in other words, the system type may be determined based on the services of the terminal device. By using the system type as an input parameter of the first model, the generated security policy can be aligned with the system type, thereby meeting the security requirements of different systems. For example, if the system type changes, the security policy network element can generate a new security policy or update the security policy.

[0086] In some implementations, the system type may also be referred to as system capability. For example, the system type may be system capability or subsystem capability in a 6G system.

[0087] In some implementations, the communication system may include one or more of the following system types: broadband cellular, D2D, URLLC, positioning and sensing, massive Internet of Things, and space communications. In other implementations, the communication system may include one or more of the following system types: integrated sensing and communication (ISAC), zero-power communication, terahertz, AI / ML, reconfigurable intelligent surface (RIS), and multiple-input multiple-output (MIMO).

[0088] For example, a zero-power communication system, due to its limited computing power, needs to implement security functions within resource constraints. For example, security policies require that terminal devices execute them with minimal resource consumption. Therefore, the security policies of a zero-power communication system can include one or more of the following sub-policies: lightweight security credential management, lightweight authentication, and physical layer key protection.

[0089] In some embodiments, the input parameters of the first model may include security requirements. The security requirements may correspond to the services of the terminal device, or in other words, the security requirements may be determined based on the services of the terminal device. By using the security requirements as input parameters of the first model, the generated security policy can be aligned with the security requirements, thereby generating security policies for different security requirements. For example, if the security requirements change, the security policy network element can generate a new security policy or update the security policy.

[0090] In some embodiments, a security requirement may include multiple sub-requirements. These sub-requirements may be combined to form a final security requirement. By dividing a security requirement into multiple sub-requirements, the sub-requirements can be flexibly combined based on the service needs of the terminal device to meet the service needs of the terminal device, thereby making the generation of security policies more flexible.

[0091] In some embodiments, security requirements may include security requirements of different protocol layers. For example, security requirements may include one or more of the following: security requirements of the non-access layer, security requirements of the radio resource control (RRC) layer, security requirements of the physical layer, and security requirements of the application layer. The security requirements of the non-access layer may include one or more of the following: authentication and key negotiation, data confidentiality, data integrity, and exception handling mechanisms. The security requirements of the RRC layer may include one or more of the following: data confidentiality, data integrity, security mode command setting, sequence number synchronization mechanism, and exception handling mechanism. The security requirements of the physical layer may include one or more of the following: encryption, channel coding and modulation, physical layer identity authentication, and fingerprint recognition. The security requirements of the application layer may include one or more of the following: network slicing security, user privacy protection, and security of open interfaces.

[0092] In some embodiments, security requirements may include one or more of the following sub-requirements: business domain, data type, data flow, security level, network environment, interaction mode, business priority, latency requirements, privacy level, identity and authorization mechanism, degree of network isolation, encryption key strength, etc.

[0093] In some embodiments, different security requirements may correspond to different security policies. For example, different security levels may correspond to different encryption strengths and access control strictness. For example, different data types (such as user data, machine data, and model data) may require different protection levels and processing methods.

[0094] In some embodiments, a sub-requirement in a security requirement may be a sub-requirement in a security requirement list. In other words, a security requirement may include multiple sub-requirements in the security requirement list. The security requirement list may be a preset security requirement list. By selecting a security requirement from the security requirement list, the process of determining the security requirement can be simplified, making the generated security requirements more standardized, thereby reducing the difficulty of generating a security policy.

[0095] In some implementations, the security requirement list may be used as input to the first model. The first model may establish a correspondence between services of the terminal device and sub-requirements, and may select corresponding sub-requirements based on the services of the terminal device.

[0096] In some embodiments, a security policy may include multiple sub-policies, or in other words, a security policy may be composed of multiple sub-policies. Through the design of sub-policies, when generating a security policy, different sub-policies can be flexibly combined according to the business needs of the terminal device, thereby increasing the flexibility of generating security policies.

[0097] In some embodiments, a security policy may include multiple sub-policies, each of which may correspond to multiple sub-requirements. In other words, the multiple sub-policies may correspond one-to-one with the multiple sub-requirements. One sub-policy corresponds to one sub-requirement. When generating a security policy, multiple sub-policies corresponding to the multiple sub-requirements may be generated, and the multiple sub-policies may be combined to form the final security policy.

[0098] For example, assuming that security requirements include lightweight authentication, distributed security, data authorization and low-level security protection, the generated security policy may include the following sub-policies: sub-policy corresponding to lightweight authentication, sub-policy corresponding to distributed security, sub-policy corresponding to data authorization and sub-policy corresponding to low-level security protection.

[0099] In some embodiments, the input parameters of the first model may include security capabilities. These security capabilities may correspond to the services of the terminal device, or in other words, they may be determined based on the services of the terminal device. In some embodiments, security capabilities may also be referred to as security functions. By using security capabilities as input parameters of the first model, the generated security policy can be aligned with the security capabilities, thereby meeting the security requirements of different security capabilities. For example, if the security capabilities change, the security policy network element can generate a new security policy or update the security policy.

[0100] In some implementations, the security capability may also be referred to as a security mechanism or a 3rd Generation Partnership Project (3GPP) security mechanism.

[0101] In some implementations, a security capability can include multiple sub-capabilities, or in other words, a modular security capability. By modularizing security capabilities, when generating security policies, different security modules can be quickly selected and combined based on specific security requirements to effectively implement the predetermined security policy.

[0102] In some implementations, the sub-capabilities may be sub-capabilities in a security capability library. For example, the security capability library may be a 3GPP security capability library. The security capability library includes multiple sub-capabilities. When generating a security policy, the corresponding sub-capabilities may be selected based on actual business needs.

[0103] In some implementations, the security capability library may also be referred to as a modular security capability library.

[0104] In some implementations, the security capability library can be used as input to the first model. The first model can establish a correspondence between services of the terminal device and sub-capabilities, and can select corresponding sub-capabilities based on the services of the terminal device.

[0105] For example, a security capability (or security capability library) may include one or more of the following sub-capabilities: 128-bit keys, authentication and key agreement (AKA), identity-based authorization, PKI, quantum-resistant keys, distributed authentication, attribute-based authorization, authorization (OAuth), physical layer keys, lightweight authentication, data-based authorization, blockchain, etc.

[0106] In some embodiments, AKA may include one or more of the following: 5G-AKA, AES-AKA, EAP-AKA, BEST-AKA, EPS-AKA, EAP-TLS, EAP-AKA', etc.

[0107] It is understandable that the finer the granularity of the sub-capability division, the more flexible the combination of sub-capabilities will be, and the generated security policy will be more in line with the business needs of the terminal device.

[0108] In some embodiments, security capabilities can span multiple security domains from the physical layer to the application layer and can include mechanisms such as authentication, authorization, data encryption, integrity verification, and replay attack protection.

[0109] In some implementations, the security capabilities may include security capabilities corresponding to security requirements. For example, the security capabilities may include security capabilities of different protocol layers. For example, the security capabilities may include one or more of the following: security capabilities of the non-access layer, security capabilities of the RRC layer, security capabilities of the physical layer, and security capabilities of the application layer. The security capabilities of the non-access layer may include security capabilities corresponding to one or more of the following security requirements: authentication and key agreement, data confidentiality, data integrity, and exception handling mechanism. The security capabilities of the RRC layer may include security capabilities corresponding to one or more of the following security requirements: data confidentiality, data integrity, security mode command setting, sequence number synchronization mechanism, and exception handling mechanism. The security capabilities of the physical layer may include security capabilities corresponding to one or more of the following security requirements: encryption, channel coding and modulation, and physical layer identity authentication and fingerprint recognition. The security capabilities of the application layer may include security capabilities corresponding to one or more of the following security requirements: network slicing security, user privacy protection, and security of open interfaces.

[0110] In some implementations, taking the non-access layer as an example, the security capabilities corresponding to authentication and key agreement may include one or more of the following: EPS-AKA, 5G-AKA, EAP-AKA, EAP-AKA', EAP-TLS, lightweight authentication protocol (such as BEST-AKA), and ultra-lightweight authentication protocol. The security capabilities corresponding to data confidentiality may include one or more of the following: EEA0, EEA1, EEA2, EEA3, NEA0, NEA1, and NEA2. The security capabilities corresponding to data integrity may include one or more of the following: EIA0, EIA1, EIA2, EIA3, NEA0, NEA1, and NEA2. The security capabilities corresponding to the exception handling mechanism may include one or more of the following: authentication exception handling, network failure and recovery, security mode command error handling, and distributed denial of service (DDOS) handling.

[0111] In some implementations, taking the RRC layer as an example, the security capabilities corresponding to data confidentiality may include one or more of the following: EEA0, EEA1, EEA2, EEA3, NEA0, NEA1, NEA2. The security capabilities corresponding to data integrity may include one or more of the following: EIA0, EIA1, EIA2, EIA3, NEA0, NEA1, NEA2. The security capabilities corresponding to the security mode command setting may include specifying the encryption algorithm and / or integrity algorithm to be used. The security capabilities corresponding to the exception handling mechanism may include one or more of the following: security mode failure, connection loss, and re-establishment loss.

[0112] In some implementations, taking the physical layer as an example, security capabilities corresponding to encryption may include data scrambling. Security capabilities corresponding to channel coding and modulation may include one or more of the following: low-density parity-check (LDPC), turbo codes, and polar codes. Security capabilities corresponding to physical layer authentication and fingerprinting may include one or more of the following: device-specific radio frequency signature recognition, time and frequency analysis, signal waveform analysis, and environmental and channel characteristics.

[0113] In some implementations, taking the application layer as an example, the security capabilities corresponding to network slicing security may include one or more of the following: slice isolation, slice secondary authentication. The security capabilities corresponding to user privacy protection may include one or more of the following: subscription concealed identifier (SUCI), temporary mobile subscriber identity (TMSI), globally unique temporary UE identity (GUTI) (such as 5G-GUTI), user consent, subscriber data management and exposure. The security capabilities corresponding to the security of open interfaces may include one or more of the following: OAuth 2.0, OpenID Connect, and authentication and key management for application (AKMA).

[0114] Through modular security capability design, security capabilities can be compatible with the security mechanisms of different communication networks (such as 4G networks, 5G networks, etc.) and provide necessary scalability for future network environments, ensuring that as network technology develops, the security measures provided in the embodiments of this application can still remain forward-looking and flexible.

[0115] In some embodiments, a security capability may include multiple sub-capabilities, and a security policy may include multiple sub-policies. Each of these sub-policies may correspond to each of the multiple sub-capabilities. In other words, each of the multiple sub-policies may correspond one-to-one with each of the multiple sub-capabilities. One sub-policy corresponds to one sub-capability. When generating a security policy, multiple sub-policies corresponding to each of the multiple sub-capabilities may be generated, and the multiple sub-policies may be combined to form a final security policy.

[0116] Taking the Industrial Internet as an example, terminal device services require data collection and processing across the entire industry chain. Therefore, the required security capabilities may include distributed authentication and authorization based on business data. When generating security policies, sub-policies corresponding to distributed authentication and authorization based on business data can be generated.

[0117] In some embodiments, to enable security policies to adapt to dynamic changes in the network, the input parameters of the first model may include security rules and / or security posture. The security posture may include system security posture and / or network security posture. The security posture may include, for example, one or more of the following: network behavior monitoring, security operation and maintenance management, and system event logs.

[0118] Security rules may include compliance requirements and / or threat analysis. In some implementations, security rules may include static rules and / or dynamic rules. Static rules may include a set of rules that do not change frequently. Static rules may include one or more of the following: data access policies, public key infrastructure, identity management rules, and security information and event management configuration. Dynamic rules may include one or more of the following: real-time feedback from data monitoring, compliance detection, threat intelligence updates, and activity logs. This information helps the core network understand the current security environment and ongoing events.

[0119] When security rules and / or security situations change, the security policy network element can update the security policy or generate a new security policy so that the generated security policy can adapt to the rapidly changing network environment and emerging threats.

[0120] The input parameters of the first model may include any one of the above parameters, or may include multiple of the above parameters. For example, the input parameters of the first model may include system type, security requirements, security capabilities, security rules, and security posture, as shown in Figure 8. For another example, the input parameters of the first model may include system type, security requirements, and security capabilities, as shown in Figure 9.

[0121] The embodiments of this application do not specifically limit the method for determining security requirements. As an example, the security requirements may be preset security requirements. The security requirements may be manually determined by a staff member. After the staff member determines the security requirements, they may input the security requirements into the first model. In some implementations, the staff member may determine the security requirements based on a security requirements list. For example, the staff member may select one or more sub-requirements from the security requirements list based on the services of the terminal device to form the final security requirements.

[0122] As another example, the security requirements may be generated based on the second model. Generating the security requirements through the second model may make the generation of the security requirements more intelligent.

[0123] The second model can be any neural network model. For example, the second model can be an AI model or an ML model. In some implementations, the second model can be a deep forest model.

[0124] In some implementations, security requirements can be generated by network elements other than the security policy network element. For example, security requirements can be generated by a policy detection network element. The policy detection network element can be, for example, a PD. By having other network elements generate security policies, the flexibility and dynamic adaptability of the security policy generation process can be increased.

[0125] In some implementations, the policy detection network element may generate security requirements based on the second model. After generating the security requirements, the policy detection network element may send the security requirements to the security policy network element, as shown in Figure 9. In some implementations, the policy detection network element may send the security requirements to the security policy network element via the policy management network element.

[0126] After receiving the security requirement from the policy detection network element, the security policy network element may consider that the service of the terminal device has changed. In this case, the security policy network element may generate a security policy.

[0127] In some embodiments, the input parameters of the second model may include one or more of the following: security rules and service data. Service data may include one or more of the following: network traffic, device status, and quality of service parameters. Changes in service data may reflect changes in service requirements. For example, if a terminal device transitions from a service with low security requirements to a service with high security requirements, the corresponding service data will also change.

[0128] Security rules can include static rules and / or dynamic rules. Static rules include sets of rules that change infrequently. Static rules can include one or more of the following: data access policies, public key infrastructure, identity management rules, and security information and event management configuration. Dynamic rules can include one or more of the following: real-time feedback from data monitoring, compliance detection, threat intelligence updates, and activity logs. This information helps the core network understand the current security environment and ongoing events.

[0129] The output of the policy detection network element (or the second model) includes security requirements. Security requirements can be generated based on service data and / or security rules. Security requirements can be security requirements from a security requirements list. The policy detection network element can have intelligent analysis and prediction capabilities and can utilize the second model and data analysis techniques to process and interpret input data to generate accurate security requirements.

[0130] In some embodiments, the policy detection network element may generate security requirements when the service of the terminal device changes. In some implementations, the policy execution network element may detect whether the service of the terminal device changes. When the service of the terminal device changes, the policy execution network element may send a first request message to the policy detection network element (such as step S510 in Figure 5 or step S610 in Figure 6), and the first request message is used to request a security policy. In response to the first request message, the policy detection network element generates security requirements (such as step S620 in Figure 6). For example, the policy detection network element may generate security requirements based on the second model. After generating the security requirements, the policy detection network element may send the security requirements to the security policy network element (such as step S630 in Figure 6).

[0131] In some implementations, the policy execution network element may send the first request message to the policy detection network element through the policy management network element. For example, the policy execution network element may send the first request message to the policy management network element, and after receiving the first request message, the policy management network element may forward the first request message to the policy detection network element.

[0132] The embodiment of the present application does not specifically limit the manner in which the policy execution network element determines whether the service of the terminal device has changed. As an example, the policy execution network element may monitor the service of the terminal device to determine whether the service of the terminal device has changed. As another example, the terminal device may send first indication information to the policy execution network element when the service has changed (such as step S710 in Figure 7), and the first indication information is used to indicate that the service of the terminal device has changed. In other words, the policy execution network element may determine whether the service of the terminal device has changed based on the indication of the terminal device.

[0133] In some embodiments, the policy detection network element may also generate security requirements based on instructions from the security policy network element. For example, the security policy network element may determine whether a security policy needs to be generated or updated based on certain rules (such as a calculated trust value). If it is determined that a security policy needs to be generated or updated, the security policy network element may send an instruction to the policy detection network element to instruct the policy detection network element to generate a new security requirement.

[0134] The following describes the security architecture involved in the embodiments of the present application in conjunction with Figures 8 and 9.

[0135] The solutions of the embodiments of the present application may include two security architectures. One security architecture includes a security policy network element. The security policy network element can be an engine component, and therefore, this architecture can also be called a single-engine architecture, as shown in Figure 8. The other security architecture includes a security policy network element and a policy detection network element. The security policy network element and the policy detection network element can both be engine components, and therefore, this architecture can also be called a dual-engine architecture, as shown in Figure 9. The solutions shown in Figures 8 and 9 are described below.

[0136] 8 , the security policy network element may generate a security policy based on the first model. Input parameters of the first model may include one or more of the following: security requirements, security capabilities, system type, security rules, and security posture.

[0137] 9 , the policy detection network element may generate security requirements based on the second model. The policy detection network element may send the generated security requirements to the security policy network element. The input parameters of the second model may include one or more of the following: service data and security rules.

[0138] The security policy network element may generate a security policy based on the first model. Input parameters of the first model may include one or more of the following: security requirements, security capabilities, and system type.

[0139] It should be noted that, in FIG8 and FIG9 , the security policy network element and the policy management network element are introduced as two network elements. However, in some embodiments, the security policy network element and the policy management network element may also be integrated into one network element.

[0140] In some implementations, the security policy network element sends the security policy to the policy execution network element (see step S420 in Figure 4 and step S520 in Figure 5). After generating the security policy, the security policy network element may send the security policy to the policy execution network element so that the policy execution network element can execute the security policy.

[0141] In some embodiments, the security policy network element may send the security policy to the policy execution network element via the policy management network element. For example, the security policy network element sends the security policy to the policy management network element, and the policy management network element may forward the security policy to the policy execution network element.

[0142] In some embodiments, the policy enforcement network element may send a security policy to the terminal device (such as step S720 in FIG. 7 ) so that the security policies in the terminal device and the policy enforcement network element are the same. The terminal device and the policy enforcement network element may then communicate securely based on the same security policy. For example, the terminal device and the policy enforcement network element may use the same physical layer key for secure transmission protection.

[0143] The following two specific examples are used to describe the embodiments of the present application in detail. It should be noted that the examples below are only for ease of understanding and are provided to explain the embodiments of the present application. The embodiments of the present application should not be limited to the following examples.

[0144] Example 1

[0145] The solution of Example 1 is applicable to the architecture shown in FIG8 .

[0146] Referring to Figure 10, in step S1010, the PEP sends a request message to the PE. Before sending the request message, the PEP may first determine whether the terminal device's service has changed. If the terminal device's service has changed, the PEP sends a request message to the PE, requesting a security policy.

[0147] In some implementations, step S1010 may include step S1010a and step S1010b. In step S1010a, the PEP sends a request message to the PA. In step S1010b, the PA forwards the request message to the PE.

[0148] In some implementations, before step S1010, the method shown in Figure 10 may further include step S1005. In step S1005, the PEP may receive indication information sent by the UE, where the indication information is used to indicate that a service of the UE has changed.

[0149] In step S1020, the PE determines whether a new security policy is needed. If a new security policy is needed, step S1030 is executed; if not, the process ends.

[0150] In step S1030, the PE generates a security policy using a first model, which is a deep forest model.

[0151] In step S1040, the PE sends the security policy to the PA.

[0152] In step S1050, the PA forwards the security policy to the PEP.

[0153] In step S1060, the PEP sends the security policy to the UE.

[0154] Through the above process, the PE can trigger a security policy update when the UE's service changes. Furthermore, the PEP and UE can obtain the same security policy, allowing them to subsequently provide security protection based on the same security policy and security features. For example, the PEP and UE can use the same physical layer key mechanism for secure transmission.

[0155] Example 2

[0156] The solution of Example 2 is applicable to the architecture shown in FIG9 .

[0157] Referring to Figure 11, in step S1110, the PEP sends a request message to the PD. Before sending the request message, the PEP may first determine whether the terminal device's service has changed. If the terminal device's service has changed, the PEP sends a request message to the PD, requesting a security policy.

[0158] In some implementations, step S1110 may include step S1110a and step S1110b. In step S1110a, the PEP sends a request message to the PA. In step S1110b, the PA forwards the request message to the PD.

[0159] In some implementations, before step S1110, the method shown in Figure 11 further includes step S1105. In step S1105, the PEP may receive indication information sent by the UE, where the indication information is used to indicate that a service of the UE has changed.

[0160] In step S1120, the PD generates security requirements using the second model, which may be a deep forest model.

[0161] In step S1130 , the PD sends a first message to the PE, where the first message includes security requirements.

[0162] In some implementations, step S1130 may include step S1130a and step S1130b. In step S1130a, the PD sends a first message to the PA. In step S1130b, the PA forwards the first message to the PE.

[0163] In step S1140, the PE determines whether a new security policy is needed. If a new security policy is needed, step S1150 is executed; if not, the process ends.

[0164] At step S1150, the PE generates a security policy using a first model. The first model is a deep forest model. The input parameters of the first model may include security requirements generated by the PD.

[0165] In step S1160 , the PE sends the security policy to the PA.

[0166] In step S1170 , the PA forwards the security policy to the PEP.

[0167] In step S1180 , the PEP sends the security policy to the UE.

[0168] The difference between Example 2 and Example 1 is that the security requirements in Example 2 are generated by PD. By generating security requirements by PD, the flexibility of security policy generation can be improved.

[0169] Through the above process, the PE can trigger a security policy update when the UE's service changes. Furthermore, the PEP and UE can obtain the same security policy, allowing them to subsequently provide security protection based on the same security policy and security features. For example, the PEP and UE can use the same physical layer key mechanism for secure transmission.

[0170] This application does not specifically limit the training process of the first model and the second model. In some embodiments, PE can train the first model. Taking the architecture shown in Figure 8 as an example, PE can request relevant data from the core network network element (such as the network data analytics function (NWDAF) network element), and PE can use the relevant data to train the first model. The relevant data may include security requirements, security rules, security situation, system type, security capabilities, etc. Taking the architecture shown in Figure 9 as an example, PE can request relevant data from the core network network element (such as the NWDAF network element), and PE can use the relevant data to train the first model. The relevant data may include security requirements, security rules, security situation, system type, security capabilities, etc.

[0171] In some embodiments, the PD can train the second model. Taking the architecture shown in Figure 9 as an example, the PD can request relevant data from a core network element (such as an NWDAF element), and the PD can use the relevant data to train the second model. The relevant data may include business data, dynamic security rules, and static security rules. Business data may include, for example, network activity data, device behavior data, user interaction data, and security event data.

[0172] The following three application examples demonstrate the efficient orchestration and implementation of the security policies in this application.

[0173] Scenario 1: Smart Home Scenario

[0174] Take a modern home, for example. Numerous smart home devices and sensing sensors are deployed within it, creating a comprehensive smart home system. This system responds to residents' needs in real time. For example, when a resident wakes up in the morning, the system uses sensing technology to automatically identify their location and behavior, adjusting curtains and lights to create an optimal indoor environment. Sensing technology can also identify daily activities, such as fitness. Using wireless signals, the system can sense and analyze resident movements, such as sit-ups or running, in real time, providing appropriate exercise feedback. For example, considering that residents may be away from home for extended periods, the system incorporates intrusion detection. If an outsider attempts unauthorized entry, the system uses the 6G network's precise sensing to analyze changes in the collected signals and determine the presence of an intruder. Once an abnormality is detected, the system immediately sends an alert to the resident's mobile device, ensuring the safety of their property.

[0175] After in-depth analysis of various scenarios, we found that each business scenario, due to its unique characteristics, presents unique security requirements. Whether it's routine home operations, real-time monitoring of user behavior, or instant alerts for unauthorized intrusions, the underlying security challenges and requirements are unique and differentiated. Specific security requirements can be seen in Table 1.

[0176] Table 1

[0177] Scenario 2: Smart Wearable Scenario

[0178] Take a user's life as an example. Their smart bracelet, smart shoes, smart glasses, and smart wristband can all communicate with the network (such as a 6G network), forming a complete smart health and fitness management system. As the user begins their day, the smart bracelet automatically activates and, leveraging advanced sensing technology, monitors key health indicators such as heart rate, blood pressure, and respiratory rate in real time. As the user begins their daily exercise, such as badminton training, the smart shoes accurately capture their movement data, such as their pace, speed, and jumps. Meanwhile, the smart glasses analyze the data on the field in real time via a high-speed network, providing instant feedback and guidance. If the user experiences an unexpected event during exercise, such as a sprained ankle, their wearable devices immediately detect the anomaly and activate emergency mode. The smart bracelet uses augmented reality technology to demonstrate the steps to treat the injury, while the wristband's built-in low-frequency electrical pain therapy device rapidly alleviates the pain. During this time, all data is transmitted in real time via the network, ensuring that the user receives optimal medical advice and assistance immediately.

[0179] With the widespread adoption of smart wearable devices across various applications, the services they support are becoming increasingly complex. These services not only impact users' daily health and fitness, but also involve emergency medical rescue, sports feedback guidance, and even real-time injury management. Each service has its own unique data and operational processes, and therefore, their security requirements vary. Daily health monitoring may prioritize data integrity and privacy protection; athletic performance testing, on the other hand, focuses on data real-timeness and accuracy; and AR-based injury management requires ensuring data availability and emergency response capabilities. Table 2 shows the security requirements for three smart wearable device usage scenarios.

[0180] Table 2

[0181] Scenario 3: Smart IoT Device Scenario

[0182] Smart IoT devices are being used in a variety of scenarios, with shopping malls being a prime example. For example, 3GPP IoT devices can be deployed on store shelves and storage areas to monitor inventory status in real time and adjust supply and marketing strategies accordingly, ensuring a balanced supply and demand and preventing inventory overstocking. Another example is that IoT devices can sense and adapt to changes in foot traffic and temperature within a shopping mall in real time. For example, lighting and air conditioning systems can be automatically adjusted to create a more comfortable shopping environment, while also reducing energy consumption and effectively optimizing operating costs. Another example is that shopping malls have introduced indoor navigation systems powered by ambient IoT, providing customers with precise indoor navigation services, easily guiding them to parking spaces and their desired stores.

[0183] The above different scenarios can correspond to different security requirements, as shown in Table 3.

[0184] Table 3

[0185] The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 11. The device embodiment of the present application is described in detail below in conjunction with Figures 12 to 15. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment. Therefore, for parts not described in detail, reference can be made to the above method embodiment.

[0186] FIG12 is a schematic block diagram of a communication device provided in an embodiment of the present application. The communication device 1200 shown in FIG12 can be any of the security policy network elements described above. The communication device shown in FIG12 includes a generating unit 1210 and a sending unit 1220.

[0187] In some embodiments, the generating unit 1210 and the determining unit may be processors, and the sending unit 1220 and the receiving unit may be transceivers. In some implementations, the communication device 1200 may further include a memory.

[0188] The generating unit 1210 is configured to generate a security policy, where the security policy is associated with a service of the terminal device.

[0189] The sending unit 1220 is configured to send the security policy to a policy execution network element.

[0190] In some possible implementations, the generating unit is configured to generate the security policy based on a first model.

[0191] In some possible implementations, the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, a security requirement corresponding to the service of the terminal device, and a security capability corresponding to the service of the terminal device.

[0192] In some possible implementations, the security capability includes multiple sub-capabilities, and the security policy includes multiple sub-policies, and the multiple sub-policies correspond to the multiple sub-capabilities respectively.

[0193] In some possible implementations, the security requirement includes multiple sub-requirements in a security requirement list.

[0194] In some possible implementations, the input parameters of the first model further include at least one of the following: security rules, network security situation, and system security situation.

[0195] In some possible implementations, the communication device further includes: a receiving unit, configured to receive the security requirement from a policy detection network element.

[0196] In some possible implementations, the security requirement is generated when the service of the terminal device changes.

[0197] In some possible implementations, the security requirements are generated based on a second model.

[0198] In some possible implementations, before generating a security policy, the communication device further includes: a receiving unit, configured to receive a first request message sent by the policy execution network element, wherein the first request message is used to request the security policy, and the first request message is sent when the service of the terminal device changes.

[0199] In some possible implementations, the communication device further includes a judgment unit, configured to judge whether the security policy needs to be generated; and the generation unit, configured to generate the security policy if the security policy needs to be generated.

[0200] FIG13 is a schematic block diagram of a communication device provided in an embodiment of the present application. The communication device 1300 shown in FIG13 can be any of the policy execution network elements described above. The communication device shown in FIG13 includes a sending unit 1310 and a receiving unit 1320.

[0201] In some embodiments, the transmitting unit 1310 and the receiving unit 1320 may be transceivers. In some implementations, the communication device 1300 may further include a memory and a processor.

[0202] The sending unit 1310 is used to send a first request message to a first network element, where the first request message is used to request a security policy, where the security policy is associated with the service of the terminal device, and the first network element includes a security policy network element and / or a policy detection network element.

[0203] The receiving unit 1320 is configured to receive the security policy from the security policy network element.

[0204] In some possible implementations, the security policy is generated based on a first model.

[0205] In some possible implementations, the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, a security requirement corresponding to the service of the terminal device, and a security capability corresponding to the service of the terminal device.

[0206] In some possible implementations, the security capability includes multiple sub-capabilities, and the security policy includes multiple sub-policies, and the multiple sub-policies correspond to the multiple sub-capabilities respectively.

[0207] In some possible implementations, the security requirement includes multiple sub-requirements in a security requirement list.

[0208] In some possible implementations, the input parameters of the first model further include at least one of the following: security rules, network security situation, and system security situation.

[0209] In some possible implementations, the security requirement is sent by the policy detection network element to the security policy network element.

[0210] In some possible implementations, the security requirement is generated when a service of the terminal device changes.

[0211] In some possible implementations, the security requirements are generated based on a second model.

[0212] In some possible implementations, before sending the first request message to the first network element, the receiving unit is further used to: receive first indication information from the terminal device, where the first indication information is used to indicate that a service of the terminal device has changed.

[0213] Figure 14 is a schematic block diagram of a communication device provided in an embodiment of the present application. The communication device 1400 shown in Figure 14 can be any of the policy detection network elements described above. The communication device shown in Figure 14 includes a receiving unit 1410, a generating unit 1420, and a sending unit 1430.

[0214] In some embodiments, the receiving unit 1410 and the sending unit 1430 may be transceivers, and the generating unit 1420 may be a processor. In some implementations, the communication device 1400 may further include a memory.

[0215] The receiving unit 1410 is configured to receive a first request message from a policy execution network element, where the first request message is used to request a security policy.

[0216] The generating unit 1420 is configured to generate, in response to the first request message, a security requirement corresponding to the service of the terminal device.

[0217] The sending unit 1430 is configured to send the security requirement to the security policy network element, where the security requirement is used by the security policy network element to generate the security policy.

[0218] In some possible implementations, the security policy is generated based on a first model.

[0219] In some possible implementations, the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, the security requirements, and a security capability corresponding to the service of the terminal device.

[0220] In some possible implementations, the security capability includes multiple sub-capabilities, and the security policy includes multiple sub-policies, and the multiple sub-policies correspond to the multiple sub-capabilities respectively.

[0221] In some possible implementations, the security requirement includes multiple sub-requirements in a security requirement list.

[0222] In some possible implementations, the security requirements are generated based on a second model.

[0223] FIG15 is a schematic block diagram of a communication device provided in an embodiment of the present application. The communication device 1500 shown in FIG15 can be any terminal device described above. The communication device shown in FIG15 includes a sending unit 1510 and a receiving unit 1520.

[0224] In some embodiments, the transmitting unit 1510 and the receiving unit 1520 may be transceivers. In some implementations, the communication device 1500 may further include a memory and a processor.

[0225] The sending unit 1510 is configured to send first indication information to a policy execution network element, where the first indication information is used to indicate that a service of the terminal device has changed;

[0226] The receiving unit 1520 is configured to receive a security policy from the policy execution network element, where the security policy is associated with a service of the terminal device.

[0227] In some possible implementations, the security policy is generated based on a first model.

[0228] In some possible implementations, the input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, a security requirement corresponding to the service of the terminal device, and a security capability corresponding to the service of the terminal device.

[0229] In some possible implementations, the security capability includes multiple sub-capabilities, and the security policy includes multiple sub-policies, and the multiple sub-policies correspond to the multiple sub-capabilities respectively.

[0230] In some possible implementations, the security requirement belongs to multiple sub-requirements in a security requirement list.

[0231] In some possible implementations, the input parameters of the first model further include at least one of the following: security rules, network security situation, and system security situation.

[0232] In some possible implementations, the security requirement is sent by a policy detection network element to the security policy network element.

[0233] In some possible implementations, the security requirement is generated when a service of the terminal device changes.

[0234] In some possible implementations, the security requirements are generated based on a second model.

[0235] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0236] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0237] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0238] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0239] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0240] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for generating a security policy, characterized in that, The method includes: A security policy network element generates a security policy, and the security policy is associated with the service of the terminal device; The security policy network element sends the security policy to a policy enforcement network element.

2. The method according to claim 1, wherein The security policy network element generates a security policy, including: The security policy network element generates the security policy based on a first model.

3. The method according to claim 2, wherein The input parameters of the first model include at least one of the following: the system type corresponding to the service of the terminal device, the security requirements corresponding to the service of the terminal device, and the security capabilities corresponding to the service of the terminal device.

4. The method according to claim 3, characterized in that, The security capabilities include multiple sub-capabilities, the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

5. The method according to claim 3 or 4, characterized in that, The security requirements include multiple sub-requirements in a security requirement list.

6. The method according to any one of claims 3 to 5, characterized in that, The input parameters of the first model further include at least one of the following: security rules, network security posture, and system security posture.

7. The method according to claim 3 or 4, characterized in that, The method further includes: The security policy network element receives the security requirements from a policy detection network element.

8. The method according to claim 7, wherein The security requirements are generated when the service of the terminal device changes.

9. The method according to claim 8, wherein The security requirements are generated based on a second model.

10. The method according to any one of claims 1-9, characterized in that, Before the security policy network element generates a security policy, the method further includes: The security policy network element receives a first request message sent by the policy enforcement network element, and the first request message is used to request the security policy. The first request message is sent when the service of the terminal device changes.

11. The method according to any one of claims 1 to 10, characterized in that, Before the security policy network element generates a security policy, the method further includes: The security policy network element determines whether it is necessary to generate the security policy; The security policy network element generates a security policy, including: In the case where it is necessary to generate the security policy, the security policy network element generates the security policy.

12. A method for generating a security policy, characterized in that, Including: A policy enforcement network element sends a first request message to a first network element, and the first request message is used to request a security policy. The security policy is associated with the service of the terminal device. The first network element includes a security policy network element and / or a policy detection network element; The policy enforcement network element receives the security policy from the security policy network element.

13. The method according to claim 12, wherein The security policy is generated based on a first model.

14. The method according to claim 13, wherein The input parameters of the first model include at least one of the following: the system type corresponding to the service of the terminal device, the security requirements corresponding to the service of the terminal device, and the security capabilities corresponding to the service of the terminal device.

15. The method according to claim 14, wherein The security capabilities include multiple sub-capabilities, the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

16. The method according to claim 14 or 15, characterized in that, The security requirements include multiple sub-requirements in a security requirement list.

17. The method according to any one of claims 14-16, characterized in that, The input parameters of the first model further include at least one of the following: security rules, network security posture, and system security posture.

18. The method according to claim 14 or 15, characterized in that, The security requirements are sent by the policy detection network element to the security policy network element.

19. The method according to claim 18, wherein The security requirements are generated when the service of the terminal device changes.

20. The method according to claim 18 or 19, characterized in that, The security requirements are generated based on a second model.

21. The method according to any one of claims 12 - 20, characterized in that, Before the policy enforcement network element sends the first request message to the first network element, the method further includes: The policy enforcement network element receives first indication information from the terminal device, and the first indication information is used to indicate that the service of the terminal device has changed.

22. A method for generating a security policy, characterized in that, Including: The policy detection network element receives a first request message from the policy enforcement network element, and the first request message is used to request a security policy. In response to the first request message, the policy detection network element generates security requirements corresponding to the service of the terminal device. The policy detection network element sends the security requirements to the security policy network element, and the security requirements are used for the security policy network element to generate the security policy.

23. The method according to claim 22, wherein The security policy is generated based on a first model.

24. The method according to claim 23, wherein The input parameters of the first model include at least one of the following: the system type corresponding to the service of the terminal device, the security requirements, and the security capabilities corresponding to the service of the terminal device.

25. The method according to claim 24, wherein The security capabilities include multiple sub-capabilities, the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

26. The method according to claim 24 or 25, characterized in that, The security requirements include multiple sub-requirements in a security requirement list.

27. The method according to any one of claims 22-26, characterized in that, The security requirements are generated based on a second model.

28. A method for generating a security policy, characterized in that, Including: The terminal device sends first indication information to the policy enforcement network element, and the first indication information is used to indicate that the service of the terminal device has changed. The terminal device receives the security policy from the policy enforcement network element, and the security policy is associated with the service of the terminal device.

29. The method according to claim 28, wherein The security policy is generated based on a first model.

30. The method according to claim 29, wherein The input parameters of the first model include at least one of the following: the system type corresponding to the service of the terminal device, the security requirements corresponding to the service of the terminal device, and the security capabilities corresponding to the service of the terminal device.

31. The method according to claim 30, characterized in that, The security capabilities include multiple sub-capabilities, the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

32. The method according to claim 30, characterized in that, The security requirements belong to multiple sub-requirements in a security requirement list.

33. The method according to any one of claims 30-32, characterized in that, The input parameters of the first model further include at least one of the following: security rules, network security posture, and system security posture.

34. The method according to claim 30 or 31, characterized in that, The security requirements are sent by the policy detection network element to the security policy network element.

35. The method according to claim 34, characterized in that, The security requirements are generated when the service of the terminal device changes.

36. The method according to claim 35, characterized in that, The security requirements are generated based on a second model.

37. A communication device, characterized in that, The communication device is a security policy network element, and the communication device includes: A generating unit, configured to generate a security policy, and the security policy is associated with the service of the terminal device. A sending unit, configured to send the security policy to the policy enforcement network element.

38. The communication device according to claim 37, wherein The generating unit is configured to: Generate the security policy based on a first model.

39. The communication device according to claim 38, characterized in that, The input parameters of the first model include at least one of the following: the system type corresponding to the service of the terminal device, the security requirements corresponding to the service of the terminal device, and the security capabilities corresponding to the service of the terminal device.

40. The communication device according to claim 39, characterized in that, The security capabilities include multiple sub-capabilities, the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

41. The communication device according to claim 39 or 40, characterized in that, The security requirements include multiple sub-requirements in a security requirement list.

42. The communication device according to any one of claims 39 - 41, characterized in that, The input parameters of the first model further include at least one of the following: security rules, network security posture, and system security posture.

43. The communication device according to claim 39 or 40, characterized in that, The communication device further includes: a receiving unit, configured to receive the security requirements from a policy detection network element.

44. The communication device according to claim 43, wherein, The security requirements are generated when the service of the terminal device changes.

45. The communication device according to claim 44, wherein The security requirements are generated based on a second model.

46. The communication device according to any one of claims 37 to 45, characterized in that, Before generating a security policy, the communication device further includes: a receiving unit, configured to receive a first request message sent by the policy enforcement network element, where the first request message is used to request the security policy, and the first request message is sent when the service of the terminal device changes.

47. The communication device according to any one of claims 37-46, characterized in that, The communication device further includes a judging unit. The judging unit is configured to judge whether it is necessary to generate the security policy. a generating unit, configured to generate the security policy when it is necessary to generate the security policy.

48. A communication device, characterized in that, The communication device is a policy enforcement network element, and the communication device includes: a sending unit, configured to send a first request message to a first network element, where the first request message is used to request a security policy, the security policy is associated with the service of the terminal device, and the first network element includes a security policy network element and / or a policy detection network element. a receiving unit, configured to receive the security policy from the security policy network element.

49. The communication device according to claim 48, characterized in that, The security policy is generated based on a first model.

50. The communication device according to claim 49, characterized in that, The input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, security requirements corresponding to the service of the terminal device, and security capabilities corresponding to the service of the terminal device.

51. The communication device according to claim 50, wherein, The security capabilities include multiple sub-capabilities, and the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

52. The communication device according to claim 50 or 51, characterized in that, The security requirements include multiple sub-requirements in a security requirement list.

53. The communication device according to any one of claims 50-52, characterized in that, The input parameters of the first model further include at least one of the following: security rules, network security postures, and system security postures.

54. The communication device according to claim 50 or 51, characterized in that, The security requirements are sent by the policy detection network element to the security policy network element.

55. The communication device according to claim 54, characterized in that, The security requirements are generated when the service of the terminal device changes.

56. The communication device according to claim 54 or 55, characterized in that, The security requirements are generated based on a second model.

57. The communication device according to any one of claims 48 - 56, characterized in that, Before sending the first request message to the first network element, the receiving unit is further configured to: receive first indication information from the terminal device, where the first indication information is used to indicate that the service of the terminal device has changed.

58. A communication device, characterized in that, The communication device is a policy detection network element, and the communication device includes: a receiving unit, configured to receive a first request message sent by the policy enforcement network element, where the first request message is used to request a security policy. a generating unit, configured to generate security requirements corresponding to the service of the terminal device in response to the first request message. a sending unit, configured to send the security requirements to the security policy network element, where the security requirements are used by the security policy network element to generate the security policy.

59. The communication device according to claim 58, wherein The security policy is generated based on a first model.

60. The communication device according to claim 59, wherein, The input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, the security requirements, and security capabilities corresponding to the service of the terminal device.

61. The communication device according to claim 60, characterized in that, The security capabilities include multiple sub-capabilities, and the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

62. The communication device according to claim 60 or 61, characterized in that, The security requirements include multiple sub-requirements in a security requirement list.

63. The communication device according to any one of claims 58 - 62, characterized in that, The security requirements are generated based on a second model.

64. A communication device, characterized in that, The communication device is a terminal device, and the communication device includes: A sending unit, configured to send first indication information to a policy enforcement network element, where the first indication information is used to indicate that the service of the terminal device has changed; A receiving unit, configured to receive a security policy from the policy enforcement network element, where the security policy is associated with the service of the terminal device.

65. The communication device according to claim 64, characterized in that, The security policy is generated based on a first model.

66. The communication device according to claim 65, wherein, The input parameters of the first model include at least one of the following: a system type corresponding to the service of the terminal device, security requirements corresponding to the service of the terminal device, and security capabilities corresponding to the service of the terminal device.

67. The communication device according to claim 66, wherein The security capabilities include multiple sub-capabilities, the security policy includes multiple sub-policies, and the multiple sub-policies respectively correspond to the multiple sub-capabilities.

68. The communication device according to claim 66, characterized in that, The security requirements belong to multiple sub-requirements in a security requirement list.

69. The communication device according to any one of claims 66-68, characterized in that, The input parameters of the first model further include at least one of the following: security rules, network security situation, and system security situation.

70. The communication device according to claim 66 or 67, characterized in that, The security requirements are sent by a policy detection network element to the security policy network element.

71. The communication device according to claim 70, wherein, The security requirements are generated when the service of the terminal device changes.

72. The communication device according to claim 71, characterized in that, The security requirements are generated based on a second model.

Images