DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 12/30/2025. Claims 1- 20 are appending of which claims 1, 8 and 15 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Objections
Claims 1-20 are objected to because of the following informalities: Claims 1, 8 and 15 recite amended limitations with suspected typographical errors. Claims 1 and 15 recite:
determining, by the computing device, that the security policy is approved based on registration for auto-approval of the security policy with a registration system by the control plane owner prior to the receiving prior to the receiving of the security policy;
and claim 6 recites:
determine that the security policy is approved based on registration for auto-approval of the security policy with a registration system by the control plane owner prior to the receiving prior the security policy being received
Such claim amendments appear to include grammatical/typographical errors. Appropriate correction is required. Claims 2-7, 9-14 and 16-20 are objected based upon their dependence to claims 1, 8 and 15.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claims 1, 8, and 15 recites determining, by the computing device, that the security policy is approved based on registration for auto-approval of the security policy with a registration system by the control plane owner prior to the receiving prior to the receiving of the security policy;
There is no support for registration for auto -approval of the security policy by the owner prior to receiving the security policy. While the specification describes auto-approval of a policy where is no language with respect to such auto-approval being prior to the receiving of the security policy. Such claims thus do not clearly define the metes and bounds of the claimed invention and is thus indefinite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a method, system and non-transitory CRM for receiving a security policy, generating security configurations and rules from the policy and configuring security rules an configurations to a security component without significantly more. Such limitations correspond to abstract idea in the category of 2) Certain methods of organizing human activity. In particular, the claims recites recite general steps with respect to IT security deployment practices performed by IT personnel receiving general security policies and generating security rules and requirement documents, receiving change request approval and final the deployment of security applications or configuring to security appliances by IT personnel. This judicial exception is not integrated into a practical application because the claims recite with broad general language steps such as generating a representation from a Domain security policy based security policy. The claim generally recites a device/system to perform such a function with great generality and not provide limitations beyond generally linking to a device for performing the function. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because steps such the determination of approval of the security policy or determining a differential correspond to extra solution activities that do not directly relate to the generating of security configurations from a policy and deployment of the configurations. Claims limitation with respect registration for auto-approval of the security policy by an owner does not recite limitation that would be significantly more. Such limitation amount to no more than generally linking the function approving a security policy that can be performed by a human to a computing device for performing such a function.
Double Patenting
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 17/961,743 in view of Lang US 2015/0269383. 18/426,650 recites a method ,system and non-transitory CRM generates a representation from a security policy. 17/961,743 teaches a similarly method, system and non-transitroy CRM that receives a file(security police) and generates a policy domain model(represenation. 18/426,650 further recites additional steps of updating a configuration bundle, determining a policy is approved, generating a rule set, determining a difference and configuring a security component based on the difference. 17/961,743 do not explicitly claim such limitations. However, Lang in the same field of endeavor teaches such limitations as shown in the table below. It would have been obvious to a person of ordinary skill at the time of the invention modify 17/961,743 with the steps of Lang. The motivation for such a modification would be to provide a method to deploy and update security rules in computing network.
This is a provisional nonstatutory double patenting rejection.
18/426,650
17/961,743
1. A computer-implemented method comprising: receiving, at a computing device, a security policy written using a Domain Specific Language (DSL) for network security, the security policy associated with a service owner and a control plane;
generating, by the computing device, from the security policy, a representation of the security policy;
updating, by the computing device, a configuration bundle of the service owner with the representation of the security policy;
determining, by the computing device, that the security policy is approved determining, by the computing device, that the security policy is approved based on registration for auto-approval of the security policy with a registration system by the control plane owner prior to the receiving prior to the receiving of the security policy;
generating, by the computing device, a rule set from the representation of the security policy;
determining, by the computing device, a differential between the rule set and a current rule set; and configuring, by the computing device, a security component associated with the control plane based on the differential.
1. A computer-implemented method comprising: receiving, at a computing device, at least one file comprising code written using a Domain Specific Language (DSL) for network security;
generating, by the computing device, from the code written using DSL in the file, at least one cloud native enforcement artifact;
generating, by the computing device, from the code written using DSL in the file and the at least one cloud native enforcement artifact, a policy domain model comprising one or more of hierarchical data, relational data, and graph data for a network security policy;
Lang ¶s414,476,477
Lang ¶s 452,553
Lang ¶278
Lang ¶481,1250
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 8-12 and 15-29 are rejected under 35 U.S.C. 102a1,a2 as being anticipated by Lang US 2015/0269383.
Regarding claims 1, 8 and 15, Lang teaches a system computer-implemented method comprising: receiving, at a computing device, a security policy written using a Domain Specific Language (DSL) for network security, the security policy associated with a service owner and a control plane(receiving policy input… i.e policy file, ¶69)
[0069] Another embodiment of the present invention is directed to an information technologies (IT) policy management system including at least one memory that stores at least one policy function, at least one refinement template, or at least one available policy function, and a processor that is configured to receive the at least one policy function, the at least one refinement template, and the at least one available policy function from the at least one memory, receive a policy input indicating a high-level policy for the IT system, the policy input being compliant with the at least one policy function, and being received in a format that is not machine-enforceable at an enforcement entity of the IT system, based on the received policy input, automatically or semi-automatically generates a machine-enforceable rule and/or configuration by filling the at least one refinement template, the machine-enforceable rule and/or configuration including the at least one available policy function and being compliant with the received policy input, and distributes the machine-enforceable rule and/or configuration to the at least one memory of the IT system or another at least one memory to thereby enable implementation of the policies.
generating, by the computing device, from the security policy, a representation of the security policy(high level human understandable policy documents are transformed into metamodels as a first step of transforming the policy into low-level enforceable rules, metamodel is a representation of the parts of a policy ¶25,32, 213)
[0025] Model-driven security originates from research work since 2002 and is related to the well-accepted concepts of the OMG Model Driven Architecture (MDA). As an example implementation, full model-driven security has been implemented by the authors since 2002 in their OpenPMF product, which uses model-driven approaches (i.e. the top-down MDS part) to automate the process of translating human-understandable security & compliance requirements into the corresponding numerous and ever-changing technical authorization policy rules and configurations. This model-driven security policy automation approach forms for example a critical part of an effective least privilege implementation for agile IT landscapes.
[0032] The resulting application/system model provides valuable, reliable information about the application with its interactions to the model-driven security process, including a security metamodel or meta-model (metamodeling or meta-modeling) 110, a security model 111, a security (policy-generation) workflow (model transformation) 120, security rules 130, and enforcement points 170. It works as follows:
[0213] "Metamodel" (or "Meta-model") may define the language and processes from which to form a model. Metamodeling may be the construction of a collection of "concepts" (things, terms, etc.) within a certain domain. A model may be an abstraction of phenomena in the real world. A metamodel may yet be another abstraction, highlighting properties of the model itself. Meta-models may be closely related to ontologies. Both are often used to describe and analyze the relations between concepts, and to express additional semantics of existing information. The metamodel may capture the semantic relationships between policies and their constituent parts, including (but not limited to) attributes/mappers/calculations, and mapping templates (policies, rules, rule elements etc.). There are many ways to structure the metamodel to best meet the requirements. For the sake of simplicity, the present patent application inclusively uses the term "metamodel" to avoid listing many overlapping terms that have a similar purpose. The use of this term does not limit the application to the use of one particular kind of metamodeling approach (e.g. the Object Management Group's). Also, similar information modeling concepts such as ontologies, semantic web, semantic wiki, semantic databases etc. can be used, as long as syntax and semantics can be flexibly captured. To make the document more readable, all these approaches are collectively referred to as "metamodel". A metamodel in the MDS System may include some or all of the information required for the MDS System's components to work, for example: entities and their semantic associations for: PFFs (e.g. attributes, calculations, mappers, actions etc.), PSFs (e.g. policy structure, rule structure, rule element structure etc.), "available" associations for PFFs and/or PSFs (e.g. indicating machine-enforceability), "required" associations for PFFs and/or PSFs (e.g. indicating selectability in the editor, input into calculation functions etc.), refinement templates (e.g. transformation templates, associations between PFFs/PSFs), metadata references, metadata itself, semantic descriptors, associations between information elements etc.
updating, by the computing device, a configuration bundle of the service owner with the representation of the security policy(changes to policies are update to the data store of policy configuration policy access point, CMP-PAP, ¶s414,476,477)
[0414] In accordance with certain embodiments of the present patent application, when triggered (S6500) by trigger events (e.g. explicit user commands, deployment/launch of the Protected SoS), the MDS System first reads inputs about "Policy Feature Function(s) and/or Policy Structure Function(s)" (S6510) (abbreviated PFFs and PSFs, and may collectively be referred to as "policy functions") from a memory or storage device, a network location (push or pull), internal memory storage, hardcoded software etc. PFFs may for example include attribute services CMP-ASS, calculation services CMP-CS, mapping services CMP-MS, and other functions used to express and calculate policies (e.g. functional system description from CMP-FDS). Inputs about PFFs may include metamodel elements relating to the policy feature function (e.g. semantic information about what the service is/does, how it relates semantically to other metamodel elements etc.). Inputs about PFFs may also include metadata elements relating to the PFFs (e.g. syntactic information about data, communication protocols, interfaces etc.) Inputs about PFFs may also include bootstrap metamodel(s) and bootstrap metadata information. A PFF may itself provide the metamodel and metadata input pertaining to it (to CMP-MMR and CMP-MDS, respectively). Alternatively, an administrator may provide the metamodel and metadata input pertaining to it. Inputs about PFFs may include "available" PFFs (i.e. sources that provide/implement the feature, e.g. CMP-ASS, CMP-CS, CMP-MS, CMP-FDS). Inputs about PFFs may also include "required" PFFs (i.e. policy features that policy authors wish to author policies with, or that are inputs into calculations). In certain embodiments, the consolidated inputs about PFFs can be read from metamodel and metadata repositories (implemented by CMP-MMR and CMP-MDR, respectively), which implement the functionality of collecting and consolidating information about the MDS System's various policy feature functions. Inputs about PSFs may (similarly to PFFs) include information about policies, rules, and rule elements, including metamodel information, metadata information, bootstrap metamodel/metadata information, information about available PSFs, information about required PSFs etc.
[0476] When the security policy metamodel changes (e.g. because of manual CMP-MMR edits, or changes to the available services and templates, such as PFFs, PSFs, refinement templates etc.), CMP-MDS reads in the new metamodel from CMP-MMR, and if necessary, uses a different set of needed model transformation templates (an example of refinement templates) in the transformation workflow to be able to handle the new metamodel (or: manual customization of the model transformation workflow may be required). CMP-MDS then generates new rules/configurations and transmits to CMP-PAP (which updates CMP-PDPs) & CMP-OSC configurations.
[0477] When the security policy model changes (e.g. via edits in CMP-PE or CMP-MMR), CMP-MDS reads in the new policy model from CMP-MMR, and generates new rules/configurations and transmits to CMP-PAP (which updates CMP-PDPs) & CMP-OSC configurations.
determining, by the computing device, that the security policy is approved based on registration for auto-approval of the security policy with a registration system by the control plane owner prior to the receiving of the security policy;(user/author of a policy via a policy editor creates the policy on the system, the creation of the policy registers the policy, the system verifies the policies for errors/inconsistencies ,(i.e. auto approval of the policy), ¶452,553 )
[0452] In an embodiment, the launcher launches CMP-PE, or CMP-PE automatically launches (it is noted that CMP-PE can be used without CMP-AEC in some cases), reads configurations (e.g. selectable policy features) and executes the user interface (e.g. software on a web app server that provides a browser-based policy editor GUI). During the policy authoring phase, when the user completes policy entry (e.g. on a web page provided by CMP-PE), CMP-PE generates the corresponding policy model (this step is obvious, because the features selectable in the editor are based on the metamodel/metadata).
[0553] In yet another embodiment, CMP-PSV verifies the correct integration of the correct PFF/PSF services (e.g. attribute services, mappers, and calculations). This is absolutely critical for the overall correctness of the MDS system. The integration has to be done correctly (by CMP-RSC or manually), or otherwise there can be many unintended consequences, such as a non-working system, or (worse) a system that enforces an incorrect security policy (related to the `garbage-in-garbage-out` problem). Based on the models/metamodels and metadata in CMP-MMR and CMP-MDR, respectively, CMP-PSV automatically checks the various models for inconsistencies, errors, omissions etc. Furthermore, CMP-PSV automatically checks log files from CMP-RSC indicating the current situation of actually installed runtime MDS System components. Additionally, CMP-PSV can check alerts about missing heartbeats (regular "I am up and running" messages produced by all MDS System components) to further assess the current situation. Based on all this information, CMP-PSV can determine whether there are any inconsistencies, errors, omissions, and whether there are any issues with the deployment and/or runtime behavior of each component.
generating, by the computing device, a rule set from the representation of the security policy( low level rules are created that can be implement at, and enforced by the policy enforcement point, ¶278)
[0278] COMPONENT "CMP-PAP" (Policy Access Point (PAP)): A Policy Access Point (CMP-PAP) component is simply a policy rule repository, which holds machine-enforceable rules and transmits them to the PDPs where the rules are relevant. In an embodiment of the MDS System, the PAP receives (potentially, but not necessarily, all) the machine-enforceable ("low-level") policy rules from the MDS transformation engine, which generates the low-level rules from high-level policies using MDS (described in the background section and in the present application). It is noted that a PAP can in some embodiments also hold specific configurations and code for other security components ("CMP-OSC", described below). It is noted that the definition of PAPs in this MDS System is not limited to ABAC, or a particular ABAC architecture (described in the background section, e.g. OASIS XACML PAPs)--CMP-PAPs can hold any machine-enforceable policy rules, configurations, and even code.
determining, by the computing device, a differential between the rule set and a current rule set; and configuring, by the computing device, a security component associated with the control plane based on the differential(changes to polices can be deployed by only transmitting and updating differences/deltas of rules that have changed, ¶481,1250) .
[0481] It is obvious to anyone skilled in the art that such changes simply trigger the same process as if the MDS System was run for the first time (after installation/configuration/launching). A potential complexity is introduced if transmitted updates should only include the differences (deltas) from the current state. In that case where only the differences to the prior versions need to be transmitted, change detection requires normalizing/sorting of rules and configurations, and storing prior normalized versions to compare with the new version. Change detection is described in depth in the MDSA patent (in a slightly different context) and applies here. If updates are fast and the system is smaller, then it may also be possible to simply run through the entire process (including rule and security configuration distribution), making the process practically identical with an initial run-through.
[1250] It is obvious to anyone skilled in the art that the described examples of changes simply trigger the same process as if the MDS System was run for the first time (after installation/configuration/launching). A potential complexity is introduced if transmitted updates should only include the differences from the current state. In that case where only the differences to the prior versions need to be transmitted, change detection requires normalizing/sorting of rules and configurations, and storing prior normalized versions to compare with the new version. Change detection is described in depth in one of the inventors' prior patent applications (in a slightly different context) and applies here. If updates are fast, then it is also possible to simply distribute the entire newly generated rule set to the relevant CMP-PDPs, making the process practically identical with an initial run-through.
Regarding claims 2, 9 and 16, Lang teaches wherein the computing device comprises a configuration realization control plane, and wherein control owner agents run in the configuration realization control plane, and further comprising: monitoring, by the control owner agents, the configuration bundles to detect changes to the configuration bundles(agents perform task to include monitoring changes to policy configurations, ¶s 403,635-637).
[0403] In another embodiment, where no explicit functional system description is available, CMP-FDS automatically determines a functional system description of a deployed Protected SoS using information from a combination of IT landscape monitoring and management tools (well-known to anyone skilled in the art), such as: network topology mapping tools, network management tools, asset monitoring/management tools, information flow monitoring tools, discovery service tools and registries, user identity management tools, single sign-on tools, configuration management tools, application management tools, process orchestration tools (e.g. BPMS/BPEL web service orchestration tools), audit tools, monitoring tools, SIM/SIEM tools etc. In some cases, CMP-FDS's automatic detection feature needs to run for a while, while the deployed "system of systems" is in full operation, in order to "learn" which systems, interactions etc. happen. CMP-FDS "normalizes" all the different information from these various tools into a coherent form (e.g. a model such as UML) that includes all (esp. functional) aspects required by CMP-MDS during rule generation (and also during CMP-PSV during compliance automation). CMP-FDS structures this information in a form that matches with the metamodel of the functional system description in CMP-MMR. This is necessary so it can be used by CMP-MDS.
[0635] FIG. 33 depicts a partly appliance-based embodiment of the MDS System (called "TrustWand" by the inventors), showing three layers:
[0636] Agents (bottom of FIG. 33): Detect process health; monitor incidents; monitor assets, networks, and information flows; and enforce access policies. Agents also have advanced features of the MDS System, such as process health notification, data tagging, redaction/filtering etc. Agents can be network-based (security appliance) (3330 and 3334), or locally tied in with a Protected SoS node system (including virtual machine) or application (3320 and 3322 and 3324).
[0637] Processors (middle of FIG. 33): Analyze and process the information received from the Agents and Admin Interfaces. The "Model-Driven Security & ABAC" system (3344) generates machine-enforceable technical access policy rules (e.g. implemented as CMP-MDS), using security policies from the Security Policies (3352) administrator interface (e.g. implemented as CMP-PE and CMP-AEC), the functional system description from the Asset Description (3350) administrator interface, and other information sources--using the operation of CMP-MDS (optionally with the operation disclosed in the MDS Patent). It distributes the generated rules to the Agents (3330 and 3334, as well as 3320 and 3322 and 3324), where they are enforced at runtime. The Asset Management system (3340) collects, aggregates, and analyzes information about IT assets (hardware and software) and information flows (e.g. across the network) detected by the Agents (3330 and 3334, as well as 3320 and 3322 and 3324), and provides an asset description to the "Asset Description" (3350) administration user interface. The "Information Flow & Incident Monitoring/Alerting" system (3342) collects, aggregates, and analyzes incident information created by the Agents (3330 and 3334, as well as 3320 and 3322 and 3324), and provides an incident information to the "Alerts" (3354) administration user interface, as well as to the "Model-Driven Compliance" (3346) system. The "Model-Driven Compliance" (3346) system aggregates, normalizes, and analyzes the provided incident information and other information sources (as described in the MDSA Patent and the present patent application) and, based on compliance policies administered via the "Compliance Policies" system (3356), produces a compliance report, which is presented to the user via the "Compliance Report" (3358) administrator interface. [0638] Admin Interfaces (top): allow security administrators to configure and monitor the system based on a generic policy model that is "undistorted by the idiosyncrasies of the technologies in which it will be implemented" (cf. Object Management Group). The "Compliance Policies" system (3356) and the "Security Policies" system (3352) allow users to manage compliance and security policy information, respectively. The Compliance Report (3358) system provides compliance reporting information to the administrator(s). The Alerts (3354) system provides incident alert information to the administrator(s). The Asset Description (3350) system provides the asset and information flow information to the administrator(s).
Regarding claims 3, 10 and 17, Lang teaches wherein the computing device further comprises control configuration control planes which are associated with control owners and security components of the computing device, wherein the security components include the security component(security components are part of the elementsupon which security rules are applied , ¶309).
[0309] Of course only technologies supported by CMP-OSC can be connected to. Examples of other security components that may be connected to include MS SharePoint, firewalls, IPS, operating systems (e.g. SELinux, MS Windows), SAP etc.
Regarding claims 4, 11 and 18, Lang teaches wherein the control configuration control planes further comprise provisioning agents, and wherein configuring, by the computing device, a security component associated with the control plane based on the differential is performed by one of the provisioning agents(CMP-PAP are the policy access points that store the rules and push the rules(i.e provision them) to the policy enforcement points, ¶278)
[0278] COMPONENT "CMP-PAP" (Policy Access Point (PAP)): A Policy Access Point (CMP-PAP) component is simply a policy rule repository, which holds machine-enforceable rules and transmits them to the PDPs where the rules are relevant. In an embodiment of the MDS System, the PAP receives (potentially, but not necessarily, all) the machine-enforceable ("low-level") policy rules from the MDS transformation engine, which generates the low-level rules from high-level policies using MDS (described in the background section and in the present application). It is noted that a PAP can in some embodiments also hold specific configurations and code for other security components ("CMP-OSC", described below). It is noted that the definition of PAPs in this MDS System is not limited to ABAC, or a particular ABAC architecture (described in the background section, e.g. OASIS XACML PAPs)--CMP-PAPs can hold any machine-enforceable policy rules, configurations, and even code.
Regarding claims 5, 12 and 10, Lang teaches wherein the control configuration control planes further comprise worker agents, and wherein determining, by the computing device, a differential between the rule set and a current rule set is performed by one of the worker agents(MDSA is the service(agent) in the management that detects policy changes and determines of changes are compliant, ¶51,52,57).
[0051] The purpose of this model-driven security approach is to correlate the inverse direction ("bottom-up"), where "undistorted" models are specified for checking, verification and/or compliance, certification & accreditation purposes: The correspondence between security characteristics of the actual IT landscape with the specified compliance/accreditation models is verified. The original term used by ObjectSecurity for this is "model-driven security accreditation" ("MDSA"). In other words, MDSA analyses and documents the traceable correspondence between technical security implementation, security policy models, and "undistorted" accreditation models.
[0052] Model-Driven Security Accreditation Automation ("MDSA") automates the analysis of traceable correspondence between technical security policy implementation (e.g. ABAC) and the information assurance requirements captured in "undistorted" requirements models (e.g. Common Criteria, control objectives). MDSA also documents "supporting evidence" for accreditation based on various information (esp. design-time system/security models, system/security artefacts, system/security model transformations, and runtime system/security incident logs). Furthermore, MDSA enables the automated change detection and analysis to determine whether the accreditation is still valid. MDSA also acts as a decision support tool.
[0057] One feature of MDSA is that whenever applications or security policies change, the accreditation/compliance evidence report can be automatically re-generated and compared for differences (based on change policies that specify allowable change paths).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 6, 13, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lang as applied to claims 1, 10 and 15 above, and further in view of Kandel US 2021/0264021
Regarding claims 6, 13 and 20, Lang teaches receiving, at the computing device, a second security policy written using the Domain Specific Language (DSL) for network security, the second security policy associated with the service owner and the control plane(receiving policy input… i.e policy file, ¶69)
[0069] Another embodiment of the present invention is directed to an information technologies (IT) policy management system including at least one memory that stores at least one policy function, at least one refinement template, or at least one available policy function, and a processor that is configured to receive the at least one policy function, the at least one refinement template, and the at least one available policy function from the at least one memory, receive a policy input indicating a high-level policy for the IT system, the policy input being compliant with the at least one policy function, and being received in a format that is not machine-enforceable at an enforcement entity of the IT system, based on the received policy input, automatically or semi-automatically generates a machine-enforceable rule and/or configuration by filling the at least one refinement template, the machine-enforceable rule and/or configuration including the at least one available policy function and being compliant with the received policy input, and distributes the machine-enforceable rule and/or configuration to the at least one memory of the IT system or another at least one memory to thereby enable implementation of the policies.
generating, by the computing device, from the second security policy, a representation of the second security policy(high level human understandable policy documents are transformed into metamodels as a first step of transforming the policy into low-level enforceable rules, metamodel is a representation of the parts of a policy ¶25,32, 213)
[0025] Model-driven security originates from research work since 2002 and is related to the well-accepted concepts of the OMG Model Driven Architecture (MDA). As an example implementation, full model-driven security has been implemented by the authors since 2002 in their OpenPMF product, which uses model-driven approaches (i.e. the top-down MDS part) to automate the process of translating human-understandable security & compliance requirements into the corresponding numerous and ever-changing technical authorization policy rules and configurations. This model-driven security policy automation approach forms for example a critical part of an effective least privilege implementation for agile IT landscapes.
[0032] The resulting application/system model provides valuable, reliable information about the application with its interactions to the model-driven security process, including a security metamodel or meta-model (metamodeling or meta-modeling) 110, a security model 111, a security (policy-generation) workflow (model transformation) 120, security rules 130, and enforcement points 170. It works as follows:
[0213] "Metamodel" (or "Meta-model") may define the language and processes from which to form a model. Metamodeling may be the construction of a collection of "concepts" (things, terms, etc.) within a certain domain. A model may be an abstraction of phenomena in the real world. A metamodel may yet be another abstraction, highlighting properties of the model itself. Meta-models may be closely related to ontologies. Both are often used to describe and analyze the relations between concepts, and to express additional semantics of existing information. The metamodel may capture the semantic relationships between policies and their constituent parts, including (but not limited to) attributes/mappers/calculations, and mapping templates (policies, rules, rule elements etc.). There are many ways to structure the metamodel to best meet the requirements. For the sake of simplicity, the present patent application inclusively uses the term "metamodel" to avoid listing many overlapping terms that have a similar purpose. The use of this term does not limit the application to the use of one particular kind of metamodeling approach (e.g. the Object Management Group's). Also, similar information modeling concepts such as ontologies, semantic web, semantic wiki, semantic databases etc. can be used, as long as syntax and semantics can be flexibly captured. To make the document more readable, all these approaches are collectively referred to as "metamodel". A metamodel in the MDS System may include some or all of the information required for the MDS System's components to work, for example: entities and their semantic associations for: PFFs (e.g. attributes, calculations, mappers, actions etc.), PSFs (e.g. policy structure, rule structure, rule element structure etc.), "available" associations for PFFs and/or PSFs (e.g. indicating machine-enforceability), "required" associations for PFFs and/or PSFs (e.g. indicating selectability in the editor, input into calculation functions etc.), refinement templates (e.g. transformation templates, associations between PFFs/PSFs), metadata references, metadata itself, semantic descriptors, associations between information elements etc.
updating, by the computing device, the configuration bundle of the service owner with the representation of the second security policy changes to policies are update to the data store of policy configuration policy access point, CMP-PAP, ¶s414,476,477)
[0414] In accordance with certain embodiments of the present patent application, when triggered (S6500) by trigger events (e.g. explicit user commands, deployment/launch of the Protected SoS), the MDS System first reads inputs about "Policy Feature Function(s) and/or Policy Structure Function(s)" (S6510) (abbreviated PFFs and PSFs, and may collectively be referred to as "policy functions") from a memory or storage device, a network location (push or pull), internal memory storage, hardcoded software etc. PFFs may for example include attribute services CMP-ASS, calculation services CMP-CS, mapping services CMP-MS, and other functions used to express and calculate policies (e.g. functional system description from CMP-FDS). Inputs about PFFs may include metamodel elements relating to the policy feature function (e.g. semantic information about what the service is/does, how it relates semantically to other metamodel elements etc.). Inputs about PFFs may also include metadata elements relating to the PFFs (e.g. syntactic information about data, communication protocols, interfaces etc.) Inputs about PFFs may also include bootstrap metamodel(s) and bootstrap metadata information. A PFF may itself provide the metamodel and metadata input pertaining to it (to CMP-MMR and CMP-MDS, respectively). Alternatively, an administrator may provide the metamodel and metadata input pertaining to it. Inputs about PFFs may include "available" PFFs (i.e. sources that provide/implement the feature, e.g. CMP-ASS, CMP-CS, CMP-MS, CMP-FDS). Inputs about PFFs may also include "required" PFFs (i.e. policy features that policy authors wish to author policies with, or that are inputs into calculations). In certain embodiments, the consolidated inputs about PFFs can be read from metamodel and metadata repositories (implemented by CMP-MMR and CMP-MDR, respectively), which implement the functionality of collecting and consolidating information about the MDS System's various policy feature functions. Inputs about PSFs may (similarly to PFFs) include information about policies, rules, and rule elements, including metamodel information, metadata information, bootstrap metamodel/metadata information, information about available PSFs, information about required PSFs etc.
[0476] When the security policy metamodel changes (e.g. because of manual CMP-MMR edits, or changes to the available services and templates, such as PFFs, PSFs, refinement templates etc.), CMP-MDS reads in the new metamodel from CMP-MMR, and if necessary, uses a different set of needed model transformation templates (an example of refinement templates) in the transformation workflow to be able to handle the new metamodel (or: manual customization of the model transformation workflow may be required). CMP-MDS then generates new rules/configurations and transmits to CMP-PAP (which updates CMP-PDPs) & CMP-OSC configurations.
[0477] When the security policy model changes (e.g. via edits in CMP-PE or CMP-MMR), CMP-MDS reads in the new policy model from CMP-MMR, and generates new rules/configurations and transmits to CMP-PAP (which updates CMP-PDPs) & CMP-OSC configurations.
Lang teaches determining approval of a policy but does not teach determination that a policy is not approved and thus does not specifically teach determining, by the computing device, that the second security policy is not approved; reverting the updating of the configuration bundle with the representation of the second security policy. Kandel in the same field of endeavor teaches a system for deployment of security policies. Kandel teaches determining, by the computing device, that the second security policy is not approved(if policy deem non-compliant suspend deployment of policy, ¶s178,179 )reverting the updating of the configuration bundle with the representation of the second security policy(if policy deem non-compliant suspend deployment of policy, ¶s178,179 ).
[0178] Process 600 may be performed without executing or implementing the policy. Normalization of a policy without its execution helps to limit attack exposure to a system implementing process 600, as well as allows for identification of and mitigation for potentially malicious activities that would otherwise be allowed by the policy, by altering/modifying such a policy before it is executed. For example, process 600 may also include applying a security policy to the policy based on the normalizing or otherwise adjusting the policy when security server 102 determines that the policy, after it is normalized, is overly permissive or potentially malicious.
[0179] Identification, normalization, and evaluation of policies could be performed synchronously with processing of policies and execution of related operation(s), and suspending implementation or application of a particular policy and/or operation to which the policy applies until the policy has been evaluated for compliance and a potential malicious or suspicious activity. For example, the policy identification, normalization, and evaluation can be triggered by a new policy creation, policy modification, or policy assignment, or a communication relating to a policy being transmitted. If the policy is determined to be non-compliant or a suspicious or malicious activity related to the policy is identified, an alert can be issued. Implementation or application of the policy and the related operation can be suspended further until the policy is adjusted to mitigate for the identified problem(s) or is determined to be compliant and non-malicious.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Lang’s determination policy compliance with suspending of implementing a non-compliant policy as taught by Kandel. The reason for this modification would be to prevent deployment of policies that may reduce or hinder network security instead of enforce security.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lang as applied to claims 1 and 8 above, and further in view of Kung 2018/0234459.
Regarding claims 7 and 14, Lang teaches wherein the security component comprises a firewall(¶309), a DNS server(¶313), a load balancer(¶348), a router(¶560)
an IAM policy controller(¶403),
[0309] Of course only technologies supported by CMP-OSC can be connected to. Examples of other security components that may be connected to include MS SharePoint, firewalls, IPS, operating systems (e.g. SELinux, MS Windows), SAP etc.
[0313] In various embodiments, this component may be needed for CMP-MDS, for example in cases where policies relate to functional aspects of the Protected SoS (e.g. network information flows, IT assets/systems/applications etc.). For example, a functional system description may be needed to be able to generate (by CMP-MDS) rules that pertain to applications, programmed interactions, workflows etc. It may also be needed to generate "infrastructure rules", which are rules that control information flows of infrastructure technologies in the Protected SoS (e.g. naming services, registries) with other infrastructure technologies and/or applications. For example, many platform software technologies (e.g. web app servers, CORBA, DDS, DNS etc.) need to have certain communications enabled (e.g. to a name service) by "allow" rules in order to function. Assuming those infrastructure technologies are inferable from the functional system description, infrastructure specific refinement templates can generate specific infrastructure rules, effectively enabling (e.g. allowing) the infrastructure communications of those infrastructure (e.g. ObjectSecurity OpenPMF has infrastructure rule generation templates for various middleware platforms).
[0348] It is noted that while the following embodiments are discussed in the context of access control policies, the MDS System is by no means limited to access control policies (or proximity-based access control), or even security policies. Far from it, many other policies can be managed and enforced using the MDS System, e.g. for other security (message protection, non-repudiation, monitoring, auditing etc.), QoS, availability, load balancing, throttling, information distribution, data analytics etc.
[0403] In another embodiment, where no explicit functional system description is available, CMP-FDS automatically determines a functional system description of a deployed Protected SoS using information from a combination of IT landscape monitoring and management tools (well-known to anyone skilled in the art), such as: network topology mapping tools, network management tools, asset monitoring/management tools, information flow monitoring tools, discovery service tools and registries, user identity management tools, single sign-on tools, configuration management tools, application management tools, process orchestration tools (e.g. BPMS/BPEL web service orchestration tools), audit tools, monitoring tools, SIM/SIEM tools etc. In some cases, CMP-FDS's automatic detection feature needs to run for a while, while the deployed "system of systems" is in full operation, in order to "learn" which systems, interactions etc. happen. CMP-FDS "normalizes" all the different information from these various tools into a coherent form (e.g. a model such as UML) that includes all (esp. functional) aspects required by CMP-MDS during rule generation (and also during CMP-PSV during compliance automation). CMP-FDS structures this information in a form that matches with the metamodel of the functional system description in CMP-MMR. This is necessary so it can be used by CMP-MDS.
[0560] In yet another embodiment, the functional system descriptions are automatically detected and generated. This is done by using information from sensors that detect for example network topologies, information flows, router configurations, end-system configurations, application configurations, user-related information (e.g. users logged into a system or application). This automation feature takes all the information and produces a consolidated picture of the functionality of the already-deployed (and usually already running) Protected SoS. Many commercial products are available to detect some of these aspects that form the functional system description--well-known product categories are for example:
Lang does not specifically teach network security enforcement to include, an application firewall, or an egress control. Kung in the same field of endeavor as the invention teaches a system for securities policy enforcement on cloud infrastructure. Kung teaches an application firewall(¶104), or an egress control(¶95).
[0095] Each workload unit can provide one or more services to a set of clients. The set of application security rules that specify the clients and services that can be accessed in a given workload unit define the set of ingress security rules that need to be enforced for that workload unit. And the set of application security rules that specify the providers and services that a workload unit can access define the set of egress security rules that need to be enforced for that workload unit. Thus, a given application level security rule can generate two network policy rules, an ingress network security rule for the service provider and an egress network security rule for the client of the service.
[0104] “Host firewalls” are software firewalls implemented in host operating systems that control inbound and outbound traffic to the host. These firewalls are configured in the same way as security group using “White list communication policies. “Web application firewalls” (WAF) is an application level firewall that filters, monitors, and blocks HTTP traffic to and from a web application. An “Intrusion Prevention System” (IPS) is a computer network service that examine network packets content to detect and prevent vulnerability exploits. Usually offered in cloud providers as an appliance which process network traffic for resources. Next generation Firewalls, an example of which is the Palo Alto Networks Firewall), combine traditional firewall capabilities with advanced filtering capabilities that can operate at application level using deep packet inspection techniques. Data encryption mechanisms can be used to encrypt data at rest or when it is being communicated through the computer network. Finally, “generic security” is any other type of security service offered by an infrastructure service provider. For example, Amazon Web Services offers a security service called “Inspector,” that inspects virtual machines and access applications for vulnerabilities and deviations from best practices.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Lang with additional security enforcement elements such as application level firewalls and egress rules as taught by Kung. The reason for this modification would be to implement additional type of security enforcement elements for a more secure network.
Applicant Remarks
With respect to the double patenting rejection the applicant requests hold the rejection in abeyance until claims are condition for allowance. The examiner has concluded the rejection shall be maintained.
The applicant argues that the 101 rejection for claims reciting an abstract idea is overcome because the processing of a security policy in a domain specific language and that such processing of a domain specific language based security can not be performed practically by a human mentally. The examiner disagrees, a domain specific language is not defined in an detail. Domain specific language based security policy broadly interpreted corresponds to a general description of a security policy. A human can reasonably read a document comprising general description of a security policy , perform error checking of high level description and create with pen and paper specific rules corresponding to the high level description. The claims still do not recite limitation that correspond to a particular application of the idea. The claims still recite steps in broad general terms that do not amount to significantly more than the abstract idea.
Applicant argues with respect to prior art rejection that cited art Lang does not teach registration for auto-approval of the security policy as amended. The examiner contends Lang teaches registration of security policies and auto-approval of security policies as presented in the rejection.
The applicant argues that remainder of the dependent claims are allowable over the alleged deficiencies of the rejection of claims 1,8 and 15 over Lang. The examiner contends that no such deficiencies are present and thus the rejection for the remainder of the dependent claims are proper.
Relevant Art Cited By The Examiner
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2023/0128866 - SOURCE CODE CONVERSION FROM APPLICATION PROGRAM INTERFACE TO POLICY DOCUMENT
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Trost , can be reached on (571)272-7872. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2442
Prosecution Insights