A method and system for automated policy deduction based on description logic

Abstract

This invention discloses a method and system for automated policy deduction based on descriptive logic, comprising: creating a structured policy; storing the structured policy as an XACML format policy; translating the XACML format policy into a formal policy; converting the formal policy into a concrete policy according to the policy objective interpretation environment to be implemented; instantiating the concrete policy, generating instances of policy objects, and distributing them to actual devices for execution. This invention, through formal security policy expression, utilizes a policy center to achieve automated deduction, decision-making, and execution of security policies, effectively reducing the difficulty of policy management for administrators and improving security management efficiency.

Description

Technical Field

[0001] This invention relates to the field of security policy management technology, specifically to a method and system for automated policy deduction based on descriptive logic. Background Technology

[0002] Security policies are behavioral standards and management principles established to ensure system security and prevent security threats from damaging the system. They are usually expressed in natural language and have a high level of abstraction. Typically, a security policy consists of conditions and operations; when the system state meets the conditions defined by the security policy, the corresponding operation is executed. Policy-based security management describes the system's security goals and requirements in the form of security policies. Then, the policy execution unit monitors and configures information access, transmission, and the behavior of network entities according to these security policies.

[0003] Managing security policies involves managing their entire lifecycle, including policy generation, storage, decision-making and interpretation, as well as policy implementation, auditing and monitoring of implementation status. The IETF comprehensively considers the application needs of policies in network management and security management. Figure 1A general policy management architecture is presented. This architecture mainly consists of the following components: Policy Management Tool (PMT): Provides administrators with a management interface, including creating, allocating, and storing policies, as well as monitoring their status. It also provides a simple verification mechanism to detect potential policy conflicts. Policy Repository (PR): A database system (such as an LDAP server) used to store policies, supporting policy retrieval. It typically also stores other network information, system parameters, or policy information. Policy Decision Point (PDP): Also known as the policy server, it is the decision-making center of the entire system. The PDP is responsible for accessing policies in the policy repository, combining current system information and network operating conditions, retrieving relevant policies from the policy repository based on policy requests submitted by policy execution points, interpreting the policies, and returning them to the policy execution points. Furthermore, the PDP can detect policy changes and conflicts, monitor policy execution results, and take countermeasures, thus functioning as a policy monitor. PDP deployment typically employs three architectures: centralized, weakly distributed, and strongly distributed. The Policy Enforcement Point (PEP) is the actual device that executes and enforces policies, such as routers, VPN gateways, and firewalls in network management. The PEP aggregates, collects, and caches the policy information required by the PDP, sends policy requests carrying policy information to the PDP as needed, and is responsible for executing policies allocated and distributed by the PDP. Simultaneously, it reports the execution results to the PDP, enabling the PDP to understand the policy execution status and the network state.

[0004] From a security management perspective, the understanding of policy levels differs among policy makers. System administrators formulate security policies based on management needs, typically defining and describing them in natural language. These administrator-oriented security policies merely reflect the security goals the system aims to achieve, shielding all underlying implementation details and technical nuances. They lack inherent executability; the system cannot parse these abstract policies or apply them to corresponding system objects or entities. Security policies for network security management, usually formulated and generated in natural language, possess high linguistic abstraction, low automation, and cannot be recognized and executed by computer systems. Currently, security policy management systems often employ conditional policy expressions using the "If...Then" structure, belonging to Type 2 grammar (context-free grammar) in the Chomsky family. This differs significantly from natural language at the linguistic level, resulting in insufficient policy expression capabilities. When defining policies, administrators are responsible for translating natural language security policies into conditional policy expressions, leading to low policy conversion efficiency, difficulty in detecting policy conflicts, and poor device compatibility.

[0005] In practical policy applications, security administrators and other professionals manually translate the security policies expressed in natural language into rules that security systems (such as VPNs, gateways, firewalls, etc.) can understand, and then configure the relevant systems. This process is complex, time-consuming, and prone to errors.

[0006] In the current stage of enterprise digital transformation, most strategy makers come from management positions and business departments, often lacking practical experience in security theory and practice. This leads to high labor costs for the transformation and implementation of security strategies. Security strategy writers typically have diverse technical backgrounds; some have legal or business backgrounds, while others have a stronger technical foundation. Summary of the Invention

[0007] Purpose of the invention: The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for automated policy deduction based on descriptive logic. Through formal security policy expression, the system utilizes a policy center to automate the deduction, decision-making, and execution of security policies, effectively reducing the difficulty of policy management for administrators and improving security management efficiency.

[0008] Technical solution: The automatic policy deduction method based on description logic described in this invention includes the following steps:

[0009] S1: Create a structured strategy and store the structured strategy as an XACML format strategy;

[0010] S2: Translate the XACML-formatted strategy into a formal strategy;

[0011] S3: Explain the environment according to the strategic objectives to be achieved, and transform the formal strategy into a concrete strategy;

[0012] S4: Instantiate a specific policy, generate an instance of the policy object, and distribute it to the actual device for execution.

[0013] To further improve the above technical solution, the structured format strategy is generated by obtaining user input strategies written in restricted natural language and then converting them, or by directly using a structured format for writing and generation.

[0014] Furthermore, the process of obtaining the strategy written in restricted natural language from user input and then converting it to generate a strategy includes: obtaining the strategy written in restricted natural language from the user input through a strategy editor under guidance, which satisfies the elements required to be included in the strategy rules and the order of the elements in the strategy rules; identifying and saving the elements in the strategy through a shallow parser; and marking the text in the strategy through multiple iterations.

[0015] Furthermore, the policy written in restricted natural language satisfies the following: each policy rule must be contained in a sentence, and the policy rule elements follow a fixed arrangement order.

[0016] Furthermore, S2 includes: automatically decomposing the XACML format strategy into actions and the execution times of the actions using an ontology library, and translating the actions and the execution times of the actions into logical sentences expressed by the relevant logical commands based on the logical commands of the action description language.

[0017] Furthermore, the logical commands based on the action description language represent the logical events implied in the authorization policy through commands and predicates, including: req is the input event of the policy system, corresponding to the access request event; do and deny are the response events of the policy system to the request; permitted and denied represent authorization status events; filedesc is used to assert the supply relationship between the file provider and the data file; and the time parameters in all commands and predicates are the execution time of the event.

[0018] Furthermore, S3 includes: performing reasoning analysis on the formal strategy through abductive logic to prove that the strategy does not have formal policy conflicts and whether it is consistent with the policy description; and generating an environment in which specific policy rules apply by specifying how actions and events change the system state.

[0019] Furthermore, a causal constraint logic programming system is employed to perform reasoning analysis on the formalized strategy, and event calculus is used to describe how system events and actions affect the system state. This invention uses causal constraint logic and event calculus for strategy deduction, employing computer reasoning to ensure the correctness of automated strategy deduction and reducing the workload of manual intervention.

[0020] The system for implementing the above-described descriptive logic-based automated policy deduction method includes a Policy Management Platform (PMT), a multi-level Policy Deployment Platform (PDP), and a Policy Application Block (PIB). The multi-level PDP includes at least one central PDP server and several autonomous system PDP servers. The central PDP server interacts with the PMT and PIB. The PIB stores digital policies and device information related to its domain. The PMT is used for policy definition to create policies. The central PDP server includes a decision control module, a policy parser, a policy translator, a policy analyzer, a policy compiler, a policy optimization module, a domain device management module, and a communication module. The decision control module is used to obtain the policies created by the PMT and access the digital policies and device information in the PIB. The system also controls the scheduling of worker threads on the PDP server. The policy parser is used to obtain policies written in restricted natural language and parse them to obtain policies in XACML format. The policy translator is used to translate the XACML-formatted policies into formal policies. The policy analyzer is used to perform reasoning analysis on the formal policies to prove that there are no formal policy conflicts to obtain specific policies. The policy compiler is used to instantiate specific policies to generate policy object instances, which are then distributed to the PEP for execution via the communication module. The policy optimization module is used to obtain monitoring events obtained during the PEP's policy execution process and optimize the policies based on these monitoring events. The domain device management module is used for device registration within the PEP.

[0021] Furthermore, the PEP communicates with the PDP server via COPS and related extended protocols to obtain the policies distributed by the PDP. The PEP includes a policy execution framework and an ontology policy library. The policy execution framework obtains PDP policies and categorizes them into SPPI policies and executable policies. SPPI policies are stored in the ontology policy library and distributed to devices that support SPPI policies for execution, while executable policies are distributed to devices that do not support SPPI policies for execution. Simultaneously, the PEP monitors the device status during policy execution and converts it into policy events, which are then submitted to the PDP. The PDP updates policy triggering and parameters based on these policy events.

[0022] Beneficial Effects: Compared with existing technologies, the advantages of this invention are as follows: This invention provides an automated policy deduction method based on descriptive logic through different levels of security policy expression. This method allows for continuous refinement, verification, distribution, and updating of policies. This method provides users with a policy editing interface through a restricted natural language template, allowing users to define security policies using constrained natural language, reducing the complexity of policy definition, and enabling business personnel without security expertise to easily define security policies.

[0023] The policy editor automatically translates restricted natural language policies into executable policies. During the translation process, ACLP logic is used for abductive reasoning to analyze formal conflicts, coverage, and other aspects of the policies to ensure they conform to the security policy description. Formal methods and automated reasoning can identify conflicts, inconsistencies, ambiguities, and gaps in the device's policy execution capabilities, thereby reducing errors associated with human interpretation.

[0024] The policy execution framework provided by this invention reduces the latency of policy issuance and deployment by automating policy processing and distribution of policy updates and related states, and provides near real-time policy deployment capabilities. It can adapt to policy configuration scenarios in specific network environments such as dynamic, power-constrained, and bandwidth-limited environments. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the general strategy management system;

[0026] Figure 2 This is the strategy conversion process adopted in this invention;

[0027] Figure 3 This is a schematic diagram of the functional structure of the PDP in this invention;

[0028] Figure 4 This is a schematic diagram of the PEP agent structure in this invention. Detailed Implementation

[0029] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings, but the scope of protection of the present invention is not limited to the embodiments described.

[0030] Terminology Explanation:

[0031] XACML: Extensible Access Control Markup Language is an OASIS specification that uses XML to express access control policies. It can be used by access control mechanisms to determine access to objects and properties.

[0032] Formal language: A language defined using precise mathematics or machine-processable formulas;

[0033] Ontology: It is a description of objects, relationships between objects, and constraints on relationships within a specific professional field;

[0034] COPS: Public Open Policy Service Protocol is a simple query and response protocol primarily used to exchange policy information between a policy server and its clients.

[0035] Different types of security policies have different mathematical models, such as authentication policies and access control policies. In specific business scenarios, due to differences in the control scenarios, granularity and conditions, security policies of the same type but in different domains (such as file access control and file flow control) will also have different specific expressions.

[0036] This invention addresses domain-specific access control scenarios by using a policy editor to automatically convert user-input natural language restricted natural language policies into machine-understandable and executable digital policies, which are then distributed to PEP components for execution through a policy management system.

[0037] like Figure 2 As shown, the policy editor implements an automated policy derivation and transformation process, including four steps: policy definition, policy translation, policy transformation, and policy execution. The main functions of each step include:

[0038] Policy Definition. This step provides users with policy definition capabilities in a restricted natural language format through the policy editor. This tool uses a restricted natural language syntax format to standardize policy definitions. After administrators create and edit policies using this structured format, policies in XACML format are automatically generated.

[0039] Policy Translation. This step translates the XACML-formatted policy into a formalized policy using a policy translator and ontology library. Various formalization methods are employed to automatically analyze the semantic correctness and consistency of the policy.

[0040] Policy Transformation. This step uses a policy transformer to automatically convert the formal policy set into concrete policies expressed in Java. Different PEP components support the execution of these concrete policies through a Java interpreter to achieve the policy objectives.

[0041] Policy execution. In this step, the policy management system (PDP) instantiates a specific policy, generates an instance of the policy object, and distributes it to the actual device (PEP) for execution.

[0042] (1) Strategy conversion process

[0043] The policy editor is the user interface provided by this invention, enabling the editing of restricted natural language security policies. To reduce the complexity of policy creation and editing and facilitate user management, the policy editor supports two policy creation methods. The first method allows users to write policy rules in restricted natural language or import and modify existing text policies, then convert the restricted natural language into a structured policy format. The second method allows users to directly define policy elements and rule relationships using a structured format. Finally, the policy editor stores the policy as XACML format policy rules. The policy editor provides guidance for policy editing, reminding users of the elements that need to be included in the policy rules and their order within the rules, so that the restricted natural language parser can accurately identify them. The policy structure used in this invention is as follows:

[0044] [User(s)] can take [Action(s)] on [Data(s)] for [Purpose(s)] if[(optional) Condition(s)] with [(optional) Obligations]

[0045] When parsing policy rules, the restricted natural language parser identifies and saves policy elements through a shallow parser. Policy elements are the components of a policy, including user category, action, data category, purpose, condition, and obligation.

[0046] Shallow parsers analyze and identify language structures in restricted natural language, but not the semantics of the text. During the recognition process, the shallow parser iterates through multiple iterations to tag the text. In the initial stage, limited language knowledge is used to identify syntactic structures such as nouns, noun phrases, verbs, phrasal verbs, and modifier phrases. Using these initial tags, the shallow parser then uses one or more grammatical structures to identify the desired text in the document based on part-of-speech patterns. To provide sufficiently high recognition accuracy, the tool is designed to use constrained restricted natural language, rather than full restricted natural language, including imposing two constraints on the policy rules: first, each policy rule must be contained within a sentence, allowing the parser to easily identify the beginning and end of each rule; second, the policy rule elements must follow a fixed permutation order.

[0047] The following example of a restricted natural language strategy illustrates the strategy conversion process of this invention.

[0048] Strategy 1: [Alice] can take [delete] on [classified files] from her device for [DLP] if [she notifies the supplier of the data 10 minutes in advance]

[0049] In Strategy 1, the policy can be divided into two clauses by the "if" condition. The condition after "if" is a natural language clause, which can be identified and marked iteratively by the shallow parser. When processing the restricted natural language policy input by the user, the policy parser first identifies and marks the policy elements in the policy (the parts in "[ ]"), and then converts and stores them as policy rules in XACML format (see Appendix 1).

[0050] Strategy 1 involves two operations: notify and delete. This invention uses algorithmic logic based on an action description language to describe the corresponding events in the analysis and processing of the strategy system, generating a formal strategy. This conversion process is automatically performed by a strategy translator using an ontology library to convert the XACML-form strategy into a formal strategy.

[0051] For simplicity, the following explanation only covers the formal description of the first half of Strategy 1 (i.e., the authorization part). This invention provides the following commands and predicates to represent the logical events implied in the authorization strategy:

[0052] 1) req(Subject, Target, Action, Time)

[0053] 2) do(Subject, Target, Action, Time)

[0054] 3) deny(Subject, Target, Action, Time)

[0055] 4)permitted(Subject, Target, Action, Time)

[0056] 5) denied(Subject, Target, Action, Time)

[0057] 6) filedesc(Supplier, Name, Type, Time)

[0058] Here, req is the input event of the policy system, corresponding to the "access request" event; do and deny are the response events of the policy system to the request; permitted and denied represent the authorization status events; the filedesc predicate is used to assert the supply relationship between the file provider and the data file; and the time parameters in all commands and predicates are the execution time of the event.

[0059] The first clause of Strategy 1 is an authorization statement, with Alice as the subject and the device where the file is located as the target. The action is `delete`, which has an associated parameter, the data file (F), and its provider is S. To implement the request and decision, the policy system uses the ontology library (created using Protégé) to automatically decompose the process into `req` and `do` actions, executed at times T0 and T1 respectively. The policy translator translates the above natural language policy into logical sentences expressed by relevant logical commands, with the formalized policy as follows:

[0060] Rule 1: do(Alice, S, notify(delete(F)), T0) & filedesc(S, F, class, T0)& not reqInBetween(S, F, retain(F), T0, T1) & T1 = T0 + 10mins à permitted(Alice, device, delete(F), T1);

[0061] Rule 2: req(Sub, Tar, Act, Tm) & Tl ≤ Tm ≤ T à reqInBtween(Sub, Tar,Act, Tl, T);

[0062] Rule 3: req(Sub, Tar, Act, T) & permitted(Sub, Tar, Act, T) à do(Sub,Tar, Act, T).

[0063] Of the rules mentioned above, rule 1 is the main component of strategy 1, rule 2 is used to check that the request time Tm is between the interval [Tl, T], and rule 3 is used to ensure that the permitted execution request must be executed.

[0064] After translating the policies, the policy analyzer uses abductive logic to reason about and analyze the policies, proving that there are no formal policy conflicts. For example, it checks whether responsibilities were acquired without authorization necessity, or whether there is a lack of correct response strategies for certain requests. This invention uses an inducement-constraint logic programming (ACLP) system as the basis for the analysis algorithm and implementation, and uses event calculus (EC) to describe how system events and actions affect the system state. EC allows us to specify how actions and events change the system state, thereby creating an environment in which specific policy rules apply.

[0065] The policy analysis method implemented in this invention determines the execution permissions acquired by the PDP / PEP in a specific request situation by proving through reasoning whether a given policy rule is consistent with the policy description. For example, in a given network / system configuration, it tests whether user Alice has the right to execute a given action.

[0066] (2) PDP architecture

[0067] Policy servers provide policy services for the security control facilities of enterprise networks. They typically employ multi-level PDP collaboration, providing policy services to subordinate devices within their domain while simultaneously requesting policies from their parent PDP. Therefore, a PDP acts as both a client and a server. In this invention, each level of PDP forms an independent autonomous domain, and an LDAP server stores digital policies and device information related to that domain. The PDP utilizes Java's JNDI interface to access the data in the LDAP server.

[0068] Figure 2 The logical structure of the PDP in this invention is presented. The central PDP and various autonomous system PDP servers can be tailored or expanded as needed. For example, domain-related algorithms and knowledge (IP Sec link control algorithms, network bandwidth allocation algorithms, event handling knowledge, etc.) may be used in policy decisions. Domain-related algorithms and knowledge components can be added to the PDP decision control module as needed to meet the diverse policy decision requirements of various network and security layers.

[0069] In this system's policy library, the policy library not only refers to the high-level abstract policy library but also includes the Policy Information Library (PIB) described using the Policy Configuration Information Structure (SPPI). SPPI is a policy information structure suitable for transmission to network devices, similar to the MIB concept in traditional network management, but PIB enhances the flexibility and scalability of policy management. The PIB is a tree-like library composed of a series of fully defined Provider Classes (PRCs) and their instances. PRCs are COPS-PR's encoded structure definition of network device configuration information, rather than policy rules in IF / THEN form. PRIs are instances of the corresponding PRCs, and each PRI has a policy rule identifier PRID uniquely associated with the policy rule. By extracting the PRID and its corresponding encoded instance object EPD from COPS-PR, the PEP can obtain all the necessary information for decoding and processing policy rules.

[0070] (3) PEP proxy implementation technology

[0071] Figure 3 The logical structure of the PEP agent in this invention is presented. To support diverse policy execution, a component-based architecture is adopted for the PEP logical architecture design. New policy communication methods and network device adaptation interfaces can be inserted into the framework as components. The PEP agent is developed using standard C and Java languages. Its main functions are to establish communication with the PDP, wait for and execute policy configuration and update decision messages from the PDP, and request policies or send event notifications to the PDP when network state changes.

[0072] Communication between the PEP and PDP uses COPS and related extended protocols. Depending on the policy processing method, the PEP must maintain a local policy library, implemented as a directory and file structure on the PEP's local file system. This library primarily stores digital policies and IETF SPPI structured policy information related to the PEP. Executable policies are stored in the PEP as Java objects (.class files). When issuing executable policies, the PDP is responsible for compiling these Java objects and distributing them to the PEP for execution. These policy objects are mainly used for policy management of devices and services that do not support IETF PIB. The PEP's policy execution framework loads and executes the policy objects, translating them into device instructions.

[0073] To assess the implementation status of policies and generate adaptive policy feedback, the PEP needs to monitor device performance. In this system, the PEP, referencing the IETF IPFIX standard, defines and implements performance detection interface protocols and services for network and security devices such as routers and firewalls. The PEP converts monitoring results into policy events and submits them to the PDP, which then determines when to trigger SLA renegotiation and parameter updates based on the policy definition.

[0074] Strategy 1—A strategy in XACML format generated by the strategy editor

[0075] / * Alice's file deletion strategy. * /

[0076] Rule 1 allows deletion if Alice notifies the provider of the confidential file 10 minutes in advance.

[0077] Rule 2: Reject everything except Rule 1.

[0078] <Policy PolicyId="file-delete-by-Alice "

[0079] RuleCombiningAlgId = "permit-overrides">

[0080] <target>

[0081] / * The policy's main component is user Alice, and the resource is all confidential files. * /

[0082] <anyof>

[0083] <allof>

[0084] <match matchid="string-equal">

[0085] <attributevalue>

[0086] Alice

[0087] < / attributevalue>

[0088] <AttributeDesignator Category="access-subject"

[0089] AttributeId="name-id" / >

[0090] < / match>

[0091] < / allof>

[0092] < / anyof>

[0093] <anyof>

[0094] <allof>

[0095] <match matchid="string-equal">

[0096] <attributevalue>

[0097] File

[0098] < / attributevalue>

[0099] <AttributeDesignator Category="resource"

[0100] AttributeId="resource-id" / >

[0101] < / match>

[0102] < / allof>

[0103] < / anyof>

[0104] <anyof>

[0105] / * Specifying action match action with deletevalue * /

[0106] <allof>

[0107] / * delete action * /

[0108] <match matchid="string-equal">

[0109] <attributevalue>

[0110] delete

[0111] < / attributevalue>

[0112] <AttributeDesignator Category="action"

[0113] AttributeId="action-id" / >

[0114] < / match>

[0115] < / allof>

[0116] < / anyof>

[0117] < / target>

[0118] <rule ruleid="Rule 1" effect="Allow">

[0119] / * Allow deletion if Alice notifies the provider of the confidential document 10 minutes in advance * /

[0120] <condition>

[0121] <apply functionid="and">

[0122] / * combines subject name value and status value* /

[0123] <apply functionid="string-one-and-only">

[0124] / * retrieves the subject role * /

[0125] <attributevalue>

[0126] Alice

[0127] < / attributevalue>

[0128] <AttributeDesignator Category="access-subject"

[0129] AttributeId="user-id " / >

[0130] < / apply>

[0131] <apply functionid=" req_time_later_notify_time">

[0132] <apply functionid="bigger ">

[0133] <attributevalue>

[0134] / *The difference between the request time and the access time must be greater than 600 seconds.* / 600

[0136] < / attributevalue>

[0137] < / apply>

[0138] <apply functionid="minus ">

[0139] / * Subtraction function * /

[0140] <apply functionid="req_time ">

[0141] / * retrieves the subject role * /

[0142] <attributevalue>

[0143] ReqTime

[0144] < / attributevalue>

[0145] <AttributeDesignator Category="Event-time"

[0146] AttributeId="req-time-id " / >

[0147] < / apply>

[0148] <apply functionid="notify_time ">

[0149] / * retrieves the subject role * /

[0150] <attributevalue>

[0151] NotifyTime

[0152] < / attributevalue>

[0153] <AttributeDesignator Category="Event-time"

[0154] AttributeId="notify-time-id " / >

[0155] < / apply>

[0156] < / apply>

[0157] < / apply>

[0158] < / apply>

[0159] < / condition>

[0160] < / rule>

[0161]

[0162] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A description logic based policy automation deduction method, characterized in that, Includes the following steps: S1: Create a structured strategy and store the structured strategy as an XACML format strategy; S2: Translate XACML-formatted strategies into formalized strategies, including: automatically decomposing XACML-formatted strategies into actions and their execution times using an ontology library; and translating actions and their execution times into logical sentences expressed by relevant logical commands based on the action description language. S3: Based on the required policy objectives, the formal policy is converted into a concrete policy, including: using an incentive-constraint logic programming system to perform reasoning analysis on the formal policy, proving that the policy does not have formal policy conflicts and whether it is consistent with the policy description; using event calculus to describe how system events and actions affect the system state, so as to generate an environment in which specific policy rules apply; S4: Instantiate the concrete policy, generate instances of policy objects, and distribute them to actual devices for execution.

2. The description logic based policy automation deduction method of claim 1, wherein: The structured format strategy is generated by obtaining user input in a restricted natural language and then converting it, or by directly using a structured format.

3. The description logic based policy automation deduction method of claim 2, wherein: The process of obtaining a strategy written in restricted natural language from user input and then converting it includes: obtaining a strategy written in restricted natural language from the user input via a strategy editor under guidance, which satisfies the elements required to be included in the strategy rules and the order of the elements in the strategy rules; identifying and saving the elements in the strategy through a shallow parser; and marking the text in the strategy through multiple iterations.

4. The description logic based policy automation deduction method of claim 3, wherein: The policy written in restricted natural language satisfies the following constraints: each policy rule must be contained in a sentence, and the policy rule elements follow a fixed order.

5. The description logic based policy automation deduction method of claim 4, wherein: The logical commands based on the action description language represent the logical events implied in the authorization policy through commands and predicates, including: req is the input event of the policy system, corresponding to the access request event; do and deny are the response events of the policy system to the request; permitted and denied represent authorization status events; filedesc is used to assert the supply relationship between the file provider and the data file; and the time parameters in all commands and predicates are the execution time of the event.

6. System for implementing the description logic based policy automation deduction method of claim 1, characterized in that: The system includes a Policy Management Platform (PMT), a multi-level PDP, and a Platform Institutional Builder (PIB). The multi-level PDP comprises at least one central PDP server and several autonomous system PDP servers. The central PDP server interacts with the PMT and PIB. The PIB stores digital policies and device information related to its domain. The PMT is used for policy definition to create policies. The central PDP server includes a decision control module, a policy parser, a policy translator, a policy analyzer, a policy compiler, a policy optimization module, a domain device management module, and a communication module. The decision control module is used to acquire policies created by the PMT, access the digital policies and device information of the PIB, and control the operation of the central PDP server. Thread scheduling; the policy parser is used to obtain policies written in restricted natural language and parse them to obtain policies in XACML format; the policy translator is used to translate the XACML format policies into formal policies; the policy analyzer is used to perform reasoning analysis on the formal policies to prove that there are no formal policy conflicts to obtain specific policies; the policy compiler is used to instantiate specific policies to generate policy object instances and distribute them to PEPs for execution through the communication module; the policy optimization module is used to obtain monitoring events obtained during the execution of policies by the PEPs and optimize the policies based on the monitoring events; the domain device management module is used for device registration of the PEPs.

7. The system of claim 6, wherein: The PEP communicates with the Autonomous System PDP server via COPS and related extended protocols to obtain policies distributed by the Autonomous System PDP server. The PEP includes a policy execution framework and an ontology policy library. The policy execution framework is used to obtain PDP policies and divide them into SPPI policies and executable policies. SPPI policies are stored in the ontology policy library and distributed to devices that support SPPI policies for execution, while executable policies are distributed to devices that do not support SPPI policies for execution. At the same time, the PEP monitors the device status during policy execution and converts it into policy events to submit to the PDP. The PDP updates the policy triggering and parameters according to the policy events.

Images