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/16/2025. Claims 1-6 are pending of which claims 1-4 are amended and claims 5-6 new.
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
Claim3 is objected to because of the following informalities: Claims were not properly marked. Claims 3 adds the term configurations but does not clearly mark such terms to indicate the addition of such limitations. Appropriate correction is required.
Wherein the data-centric model is defined by communications constructs and communication security configurations
…
Wherein the communication security configurations define protections for the data sent from the data producers to the data consumers
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 3 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 3 recites “a method for visually augmenting a system model and validating ….”, there is no support for visually augmenting a system model. There is no language in the specification regarding visually augmenting a system model.
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-4 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 and 3 both comprise a method that recites a step of
Claim 1 … (a) on a computer system having a software implemented and operable data-centric model of a Data Distribution Service (DDS) data exchange system exchanging data between data producers and data consumers, wherein …
(b) on the computer system having a software implemented and operable validation code for validating the domain security policies and the topic security policies for the data centric model, wherein…
Claim 3: comprising:(a) on a computer system having a software implemented and operable data-centric model of a data exchange system exchanging data between data producers and data consumers, wherein…
;(b) on the computer system having a software implemented and operable validation code for validating the defined protections for the data centric model, wherein…
The limitations of having code does not recite a step of a process or method… but rather describes and attribute of an element. Thus since no step nor method is performed it is unclear as to whether such limitations and the related wherein clauses are required to be performed as part of a method. Claims 2 and 4 recited similar language. Claims 1-4 are this rejection under 112 2nd ¶ as being indefinite for not clearly establishing the metes and bounds of the claim. Applicant amendments reciting exchanging data between data producers and data consumers does not alleviate the claims as recited directed towards the aspect of “having software implemented and operable” and renders the remainder of the claim limitation optional. The claim is directed to having software…., rather than a method.
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.
Claim 3 is rejected under 35 U.S.C. 102a1,a2 as being anticipated by Lang US 2015/0269383.
Regarding claim 3, Lang teaches for visually augmenting a system model and validating cybersecurity configurations to generate security configurations for data-centric communications system, comprising:(a) exchanging data between data producers and consumers on a computer system having a software implemented and operable data-centric model of a data exchange system used for the exchanging data between data producers and data consumers(Lang teaches a DDS system for implementing a topic publish-subscribe system, a publish subscribe system for exchange data between publishers and subscribers ¶645)
[0645] In the MDS System, CMP-PEPs can trigger policy decision-making by CMP-PDP for Protected SoS nodes for either inbound communications (i.e. messages sent to the resource) or outbound communications (i.e. messages sent from the resource), or both. While this distinction may seem insignificant, each choice has major implications, dependent on the communications paradigm of the Protected SoS, on the information transmitted, etc. For example, inbound communications in request-reply style communications usually transmit a "read" request to a service, followed by a response that for example includes the requested information. The information flows from the resource to the requestor. For "write" requests, e.g. to a storage system, the inbound communications (request) would include the information. For an "execute" request, there may be no response. In a data distribution centric publish-subscribe architecture, requests (i.e. registering as a subscriber or publisher to a topic) are separate from the information flows, which are handled automatically by the publish-subscribe middleware software. There are numerous other communications paradigms well-known to anyone skilled in the art.
wherein the data exchange system has security settings( system implements security configuration derived from high-level descriptions, ¶306)
[0306] COMPONENT "CMP-OSC" (Other Technology Component Security Configuration): This component may allow the configuration of other security configurations via a model-driven refinement process based on the methods employed by the CMP-MDS component (for security rule generation). The difference is that instead of rules for CMP-PDPs, CMP-OSC can generate specific configurations for "other security components" (OSC), which often require custom configuration files, configuration commands, source code, binary code etc. This CMP-OSC component may closely interact with CMP-MDS, and in many embodiments CMP-MDS feeds directly into CMP-OSC, which further processes the outputs of CMP-MDS and distributes/configures them within the "other technology component". In other words, in some embodiments, CMP-OSC carries out methods similar to CMP-MDS to generate and distribute configurations, while in other embodiments, CMP-OSC informs CMP-MDS to generate configurations and CMP-OSC distributes those. In yet another embodiment, CMP-MDS autonomously generates the configurations and CMP-OSC distributes them. It is obvious that the described features can be distributed between CMP-MDS and CMP-OSC in various additional ways.
[0563] Network management tools [0564] Asset monitoring/management tools [0565] Information flow monitoring tools (e.g. a passive DDS application node that listens to all topics and records which DDS nodes publishes and reads messages ;
wherein the data-centric model is defined by communications constructs and communications security configurations(meta model define syntax for constructing messages and security policy implements security configuration on message delivery , ¶s, 213 303),
[213] "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.
[0303] COMPONENT "CMP-MDS" (Model-Driven Security Policy Automation): This model-driven security policy automation component may automatically generate the required technical security rules (esp. access control rules). In certain embodiments, CMP-MDS uses the MDS methods and systems described in the background section (and the MDS Patent) and in the present application, and may form a part of more elaborate MDS (e.g. PBAC) architectures. This process is enabled by the metamodels stored in CMP-MMR, the metadata stored in CMP-MDR, and the policy model (created from the user's selection) stored in CMP-MMR and/or CMP-PE, and other information sources.
wherein the communications constructs include data types to which the data producers can send on and the data consumers can receive, (security polices applied based on data types of the messages ¶s 276,371 ) wherein the communications security configurations define protections for the data sent from the data producers to the data consumers(policies define and implement message protections , ¶348),
[0276] It is noted that many different standards and approaches could be used to capture metadata, and this application is not limited to one particular metadata standard. In some embodiments, metadata mainly concerns the syntactic and technical integration information about services, such as the service's network location, application interface, supported data types etc. An example of service metadata is the WSDL standard and another example is OMG IOR. The metadata could for example be captured, stored, transferred, and processed in e.g. Eclipse using e.g. EMF and e.g. XMI.
[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.
[0371] Configuration CFG-5 is depicted in FIG. 13. Its features can be summarized as "Metadata+Metamodel & Calculation Services Separate from Attribute Services". Compared to CFG-4, this configuration includes additional metadata (1355, 1365, 1375) for each service (1350, 1360, 1370) that captures the syntax and integration information (integration interfaces, data types, network information, protocols etc.) of the inputs and outputs of the available services. In an embodiment, an attribute service CMP-ASS (1350) provides the geolocation of requestors in the Geography Markup Language (GML) standard notation. It provides metadata about its features to the metadata repository CMP-MDR (1385), including for example: network address (e.g. IP), server information (e.g. app server), supported communications protocols (e.g. SOAP), supported interfaces (e.g. "get_requestor_geolocation", supported formats (e.g. GML) etc
[0646] CMP-PEPs can enforce policies on inbound (to the resource) communications easily based on attributes of the caller, and based on information about the resource that can be obtained from the request message itself (e.g. invoked resource operation, the requested kind of data). Inbound CMP-PEPs have the great advantage over outgoing CMP-PEPs that they will block denied requests before they even reach the protected resource, thus ensuring availability and robustness. However, if the policy decision depends on the specifics of the response (e.g. the particular kind of information returned), then inbound CMP-PEPs cannot easily obtain the information CMP-PDPs require to make access decisions. A feasible approach like the MDS System's support for fine-grained resource (content) labels where the required information from the resource itself at the time the inbound request gets intercepted by CMP-PEP. In some cases (e.g. where the returned data is small), the CMP-PEP can cache the requested information and pass it on as a response itself. In other cases, this means that each granted request incurs two accesses to the resource: one to determine the policy decision, followed by the actual request. Inbound (to the resource) PEPs are often not ideal for such use cases. In other cases (such as publish-subscribe based systems), there is no request that triggered a response, but the responses (publications) are simply published and distributed to all subscribers--inbound (to the resource) PEPs are often not ideal for such use cases either
and wherein the communications constructs and the communications security configurations are linked to each other within the data-centric model by assignment of the security configuration to the data types(security configuration applied based on data type i.e. topic type, ¶s 274, 851)
[0274] In some embodiments, the metadata and repository also form a vital input into the automatic MDS System (e.g. PBAC) system component configuration, including MDS System's runtime, MDS system's model transformation engine etc. It may also form a vital input into the automated configuration of security features (and other features) of underlying technology components, such as operating systems, virtual machines, network interfaces, middleware, applications, databases etc.
[0851] The semantics of the operational proximity attribute(s) depend heavily on the information sources used to calculate the attribute(s), and also on how several operational proximity aspects are combined. For example, if operational task labels and a task hierarchy are available, these could be used to establish close operational proximity (i.e. working on the same operation), or a distance relation between different operational labels (e.g. by a hierarchy of tasks and topic types, e.g. intelligence analysts and information about criminals). Potentially, an operational proximity chart can be modeled that captures the position of roles/tasks and topics and their relations, which could be used to calculate an organizational proximity value. Different calculation methods will therefore need to be applied depending on exact attribute source.
(b) validating the defined security protections for the data centric model on the computer system having a software implemented and operable validation code used for the validating of the defined protections for the data centric model, wherein the validating is performed with a validation model; and;(MDS models used to transform i.e. validate policies into specific security configurations, ¶43 and verify the security policies are enforceable, ¶419 )
[0043] MDS model transformations turn the inputs into the outputs. A trivial policy example would be "Interactions in the component deployment model are interpreted as explicit granted access". Roles are only used to split up interfaces into subsets of operations, in order to minimize privileges. From these transformation inputs, MDS then generates a number of explicit access rules that allows the identity of the modelled invoker to access the modelled invocation target. The advantage of this approach is that basic security policies for distributed component applications can be automatically generated without any human interaction or any security-related tags in the models. OpenPMF MDS model transformations use rule templates (implemented in Eclipse, which includes a modelling framework that can be used for transformations, including for example EMF, OAW, MWE, Xtext, Xpand etc.) It is important to see that the customer who uses the MDS tool (in this case OpenPMF) will not see any of the model transformation complexity once the MDS tool is installed and configured. All they will see is a development/modelling GUI with some extra features and menu items for the model transformation.
[0419] It is evident to anyone skilled in the art of computer science that there are many ways of implementing checking whether there is a refinement template match, and checking whether the policy is machine-enforceable, with the same result, and that the presented flow diagram only illustrates one particular implementation. For example, the matching step (S6540) may iterate through all available combinations of refinement templates to determine a match, and set a variable if a match is found, which can be checked by the "no match and policy not machine-enforceable" determining step (S6570). Furthermore, a policy rule is machine-enforceable if an available, i.e. machine-enforceable, PFF (e.g. CMP-ASS, CMP-CS, CMP-MS) can be associated with every policy function feature in the policy, and an available, i.e. machine-enforceable, PSF (e.g. policy, rule, rule element) can be associated with every policy structure feature in the policy. Similarly, a configuration is machine-enforceable if every configuration feature can be associated with a supported configuration feature of other security components (cf. CMP-OSC) and/or the MDS System (cf. CMP-RSC).
(c) generating on the computer system a set of security configuration files from the validating step and from the validation model, wherein the set of security configuration files are used by the data exchange system to configure the security settings of the data exchange system(transform human understandable policies into custom security configuration files that implement security rules and security components into configuration files ¶s43, 305-307, 437).
[0043] MDS model transformations turn the inputs into the outputs. A trivial policy example would be "Interactions in the component deployment model are interpreted as explicit granted access". Roles are only used to split up interfaces into subsets of operations, in order to minimize privileges. From these transformation inputs, MDS then generates a number of explicit access rules that allows the identity of the modelled invoker to access the modelled invocation target. The advantage of this approach is that basic security policies for distributed component applications can be automatically generated without any human interaction or any security-related tags in the models. OpenPMF MDS model transformations use rule templates (implemented in Eclipse, which includes a modelling framework that can be used for transformations, including for example EMF, OAW, MWE, Xtext, Xpand etc.) It is important to see that the customer who uses the MDS tool (in this case OpenPMF) will not see any of the model transformation complexity once the MDS tool is installed and configured. All they will see is a development/modelling GUI with some extra features and menu items for the model transformation.
[0305] COMPONENT "CMP-PSV" (Model-Driven Security Accreditation/Compliance (MDSA)): This component may analyze all available models and metamodels, and--in many embodiments based on verification requirements model--may produce a verification result. This component can be executed when the Protected SoS is deployed (e.g. for certification & accreditation such as Common Criteria), or can be executed continually at runtime (e.g. to detect compliance/non-compliance on an ongoing basis for rapid re-accreditation). In many embodiments, model-driven algorithms can check traceability from requirements to enforcement, correct traceability of information flows within the MDS System, traceability of runtime incidents to requirements models etc. In many embodiments, CMP-PSV also detects changes to the Protected SoS or the requirements models, and produces supporting evidence for manual accreditation/re-accreditation. The functionality of this component has been described in the background section and the MDSA Patent.
[0306] COMPONENT "CMP-OSC" (Other Technology Component Security Configuration): This component may allow the configuration of other security configurations via a model-driven refinement process based on the methods employed by the CMP-MDS component (for security rule generation). The difference is that instead of rules for CMP-PDPs, CMP-OSC can generate specific configurations for "other security components" (OSC), which often require custom configuration files, configuration commands, source code, binary code etc. This CMP-OSC component may closely interact with CMP-MDS, and in many embodiments CMP-MDS feeds directly into CMP-OSC, which further processes the outputs of CMP-MDS and distributes/configures them within the "other technology component". In other words, in some embodiments, CMP-OSC carries out methods similar to CMP-MDS to generate and distribute configurations, while in other embodiments, CMP-OSC informs CMP-MDS to generate configurations and CMP-OSC distributes those. In yet another embodiment, CMP-MDS autonomously generates the configurations and CMP-OSC distributes them. It is obvious that the described features can be distributed between CMP-MDS and CMP-OSC in various additional ways.
[0307] It is noted therefore that the present application is not limited to the generation of security rules (or, even more specifically, access rules)--instead, the present application can also generate specific configurations in the format required by an "other security component" (custom configuration files, configuration commands, source code, binary code etc.)
[0437] In some embodiments, there is a configuration phase. In such embodiments, a system configurer (e.g. administrator(s), system integrator(s), system deployer(s)) configures the installed components and interconnections (by setting configuration files/options/settings etc.) using for example a keyboard and display/screen.
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.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Lang US 2015/0269383, and further in view of Yegorin US 2020/0067903.
Regarding claim 1, Lang teaches a method for visually modeling and validating cybersecurity configurations to generate security configurations for Data Distributed Service (DDS) systems, comprising: (a) exchanging data between data producers and data consumers on a computer system having a software implemented and operable data-centric model of a Data Distribution Service (DDS) data exchange system used for the exchanging data between data producers and data consumers(Lang teaches a DDS system for implementing a topic publish-subscribe system, a publish subscribe system for exchange data between publishers and subscribers ¶645)
[0645] In the MDS System, CMP-PEPs can trigger policy decision-making by CMP-PDP for Protected SoS nodes for either inbound communications (i.e. messages sent to the resource) or outbound communications (i.e. messages sent from the resource), or both. While this distinction may seem insignificant, each choice has major implications, dependent on the communications paradigm of the Protected SoS, on the information transmitted, etc. For example, inbound communications in request-reply style communications usually transmit a "read" request to a service, followed by a response that for example includes the requested information. The information flows from the resource to the requestor. For "write" requests, e.g. to a storage system, the inbound communications (request) would include the information. For an "execute" request, there may be no response. In a data distribution centric publish-subscribe architecture, requests (i.e. registering as a subscriber or publisher to a topic) are separate from the information flows, which are handled automatically by the publish-subscribe middleware software. There are numerous other communications paradigms well-known to anyone skilled in the art.
wherein the Data Distribution Service (DDS) data exchange system has security settings(DDS system implements security configuration derived from high-level descriptions, ¶306)
[0306] COMPONENT "CMP-OSC" (Other Technology Component Security Configuration): This component may allow the configuration of other security configurations via a model-driven refinement process based on the methods employed by the CMP-MDS component (for security rule generation). The difference is that instead of rules for CMP-PDPs, CMP-OSC can generate specific configurations for "other security components" (OSC), which often require custom configuration files, configuration commands, source code, binary code etc. This CMP-OSC component may closely interact with CMP-MDS, and in many embodiments CMP-MDS feeds directly into CMP-OSC, which further processes the outputs of CMP-MDS and distributes/configures them within the "other technology component". In other words, in some embodiments, CMP-OSC carries out methods similar to CMP-MDS to generate and distribute configurations, while in other embodiments, CMP-OSC informs CMP-MDS to generate configurations and CMP-OSC distributes those. In yet another embodiment, CMP-MDS autonomously generates the configurations and CMP-OSC distributes them. It is obvious that the described features can be distributed between CMP-MDS and CMP-OSC in various additional ways.
[0563] Network management tools [0564] Asset monitoring/management tools [0565] Information flow monitoring tools (e.g. a passive DDS application node that listens to all topics and records which DDS nodes publishes and reads messages ;
wherein the data-centric model is defined by DDS constructs and a DDS security configuration model(security polices applied based on data types of the messages ¶s 276,371, policies define and implement message protections , ¶348),
[0276] It is noted that many different standards and approaches could be used to capture metadata, and this application is not limited to one particular metadata standard. In some embodiments, metadata mainly concerns the syntactic and technical integration information about services, such as the service's network location, application interface, supported data types etc. An example of service metadata is the WSDL standard and another example is OMG IOR. The metadata could for example be captured, stored, transferred, and processed in e.g. Eclipse using e.g. EMF and e.g. XMI.
[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.
[0371] Configuration CFG-5 is depicted in FIG. 13. Its features can be summarized as "Metadata+Metamodel & Calculation Services Separate from Attribute Services". Compared to CFG-4, this configuration includes additional metadata (1355, 1365, 1375) for each service (1350, 1360, 1370) that captures the syntax and integration information (integration interfaces, data types, network information, protocols etc.) of the inputs and outputs of the available services. In an embodiment, an attribute service CMP-ASS (1350) provides the geolocation of requestors in the Geography Markup Language (GML) standard notation. It provides metadata about its features to the metadata repository CMP-MDR (1385), including for example: network address (e.g. IP), server information (e.g. app server), supported communications protocols (e.g. SOAP), supported interfaces (e.g. "get_requestor_geolocation", supported formats (e.g. GML) etc
wherein the DDS constructs includes DDS topics to which the data producers can publish on and the data consumers can subscribe to(data is published to consumer(i.e. subscribers) based subscribed topics, ¶565)
[0565] Information flow monitoring tools (e.g. a passive DDS application node that listens to all topics and records which DDS nodes publishes and reads messages
[0576] populate network map with IP addresses of all nodes [0577] associate discovered DDS application (with their published/subscribed topics) with each node [0578] associate interactions with DDS applications based on detected network traffic
wherein the DDS security configuration model comprising domain security configurations defining security protections for RTPS packets sent within one or more DDS domains (security polices can be applied/defined for different domains… different organizations, ¶s701,703)
[0701] In an embodiment of the MDS System that implements ZBAC, CMP-MDS (directly or via CMP-PAP) distributes the machine-enforceable rules to the ZBAC authorization servers based on the participants served by each ZBAC server (e.g. on ZBAC server per trust domain, per organization etc.).
[0703] On the receiving resource side (potentially in a different trust domain with a different ZBAC server), the receiving Protected SoS node's CMP-PEP passes the token and attributes about the message on to its own ZBAC server to determine whether access should be granted. Based on an agreed trust relationship between federated authorization servers (that is technically implemented using e.g. cryptographic certificates), the ZBAC server can act as the CMP-PDP and confirm that the token was issued by a trusted ZBAC server, and that the token grants access for the specific request.
wherein the DDS constructs and the DDS security configurations are linked to each other within the data-centric model by assigning the DDS security configurations to the DDS topics and one or more DDS domains(high-level policy descriptions are transformed into specific rules and security configuration/components, ¶s213,303 , policies are implement at the domain level i.e. tenant domain, ¶701)
[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.
[0303] COMPONENT "CMP-MDS" (Model-Driven Security Policy Automation): This model-driven security policy automation component may automatically generate the required technical security rules (esp. access control rules). In certain embodiments, CMP-MDS uses the MDS methods and systems described in the background section (and the MDS Patent) and in the present application, and may form a part of more elaborate MDS (e.g. PBAC) architectures. This process is enabled by the metamodels stored in CMP-MMR, the metadata stored in CMP-MDR, and the policy model (created from the user's selection) stored in CMP-MMR and/or CMP-PE, and other information sources.
[0701] In an embodiment of the MDS System that implements ZBAC, CMP-MDS (directly or via CMP-PAP) distributes the machine-enforceable rules to the ZBAC authorization servers based on the participants served by each ZBAC server (e.g. on ZBAC server per trust domain, per organization etc.).
(b) validating the domain security configurations for the data centric model wherein the validating occurs on the computer system having a software implemented and operable validation code use for validating the domain security, wherein the validating is performed with a validation model;(MDS models used to transform i.e. validate policies into specific security configurations, ¶43)
[0043] MDS model transformations turn the inputs into the outputs. A trivial policy example would be "Interactions in the component deployment model are interpreted as explicit granted access". Roles are only used to split up interfaces into subsets of operations, in order to minimize privileges. From these transformation inputs, MDS then generates a number of explicit access rules that allows the identity of the modelled invoker to access the modelled invocation target. The advantage of this approach is that basic security policies for distributed component applications can be automatically generated without any human interaction or any security-related tags in the models. OpenPMF MDS model transformations use rule templates (implemented in Eclipse, which includes a modelling framework that can be used for transformations, including for example EMF, OAW, MWE, Xtext, Xpand etc.) It is important to see that the customer who uses the MDS tool (in this case OpenPMF) will not see any of the model transformation complexity once the MDS tool is installed and configured. All they will see is a development/modelling GUI with some extra features and menu items for the model transformation.
(c) the computer system generating a set of security configuration files from the validating step and from the validation model, wherein the set of security configuration files are used by the Data Distribution Service (DDS) data exchange system to configure the security settings of the Data Distribution Service (DDS) data exchange system(transform human understandable policies into custom security configuration files that implement security rules and security components, ¶s43, 305-307).
[0043] MDS model transformations turn the inputs into the outputs. A trivial policy example would be "Interactions in the component deployment model are interpreted as explicit granted access". Roles are only used to split up interfaces into subsets of operations, in order to minimize privileges. From these transformation inputs, MDS then generates a number of explicit access rules that allows the identity of the modelled invoker to access the modelled invocation target. The advantage of this approach is that basic security policies for distributed component applications can be automatically generated without any human interaction or any security-related tags in the models. OpenPMF MDS model transformations use rule templates (implemented in Eclipse, which includes a modelling framework that can be used for transformations, including for example EMF, OAW, MWE, Xtext, Xpand etc.) It is important to see that the customer who uses the MDS tool (in this case OpenPMF) will not see any of the model transformation complexity once the MDS tool is installed and configured. All they will see is a development/modelling GUI with some extra features and menu items for the model transformation.
[0305] COMPONENT "CMP-PSV" (Model-Driven Security Accreditation/Compliance (MDSA)): This component may analyze all available models and metamodels, and--in many embodiments based on verification requirements model--may produce a verification result. This component can be executed when the Protected SoS is deployed (e.g. for certification & accreditation such as Common Criteria), or can be executed continually at runtime (e.g. to detect compliance/non-compliance on an ongoing basis for rapid re-accreditation). In many embodiments, model-driven algorithms can check traceability from requirements to enforcement, correct traceability of information flows within the MDS System, traceability of runtime incidents to requirements models etc. In many embodiments, CMP-PSV also detects changes to the Protected SoS or the requirements models, and produces supporting evidence for manual accreditation/re-accreditation. The functionality of this component has been described in the background section and the MDSA Patent.
[0306] COMPONENT "CMP-OSC" (Other Technology Component Security Configuration): This component may allow the configuration of other security configurations via a model-driven refinement process based on the methods employed by the CMP-MDS component (for security rule generation). The difference is that instead of rules for CMP-PDPs, CMP-OSC can generate specific configurations for "other security components" (OSC), which often require custom configuration files, configuration commands, source code, binary code etc. This CMP-OSC component may closely interact with CMP-MDS, and in many embodiments CMP-MDS feeds directly into CMP-OSC, which further processes the outputs of CMP-MDS and distributes/configures them within the "other technology component". In other words, in some embodiments, CMP-OSC carries out methods similar to CMP-MDS to generate and distribute configurations, while in other embodiments, CMP-OSC informs CMP-MDS to generate configurations and CMP-OSC distributes those. In yet another embodiment, CMP-MDS autonomously generates the configurations and CMP-OSC distributes them. It is obvious that the described features can be distributed between CMP-MDS and CMP-OSC in various additional ways.
[0307] It is noted therefore that the present application is not limited to the generation of security rules (or, even more specifically, access rules)--instead, the present application can also generate specific configurations in the format required by an "other security component" (custom configuration files, configuration commands, source code, binary code etc.)
Lang teaches polices applied to a domain but do not teach the DDS policies include a
the topic security configurations and the topic security protection configurations for the data centric model, topic security configurations defining protections for RTPS packets with the DDS topics. Yegorin in the same field of endeavor as the invention teaches an event data publish subscribe system. Yegorin teaches the DDS policies include a
the topic security configurations and the topic security protection configurations for the data centric model, topic security configurations defining protections for RTPS packets with the DDS topics (security context of users subcribers are implemented to validate what topics are accessible, what topics can be published, ¶s72, 91 , 98 )
[0072] The server uses a topic, such as the default topic, to publish information about the successfully connected client along with that client's security context if required. The client subscribes to allowed topics and hence receives messages on that topic from the server that are published by other clients. The client publishes its messages on the authorized topic to the server. The server validates incoming messages published by other clients based on allowed topics and security context information stored in memory or in a third party store. An important check performed by server is to check the JWT has not expired, by checking its expiration time, and that the JWT has not been revoked, by checking the OAuth2 server that issued the JWT. If the token is expired or revoked the server closes the underlying network connection and frees up the associated memory resources. For recently expired or revoked tokens, the server may provide a small leeway time before acting on the token removal. In addition, the server can run other types of validation checks, e.g. based on message payload size or data format.
[0091] In the MQTT standard, there is a system topic labeled SSYS, which is a pre-defined, default topic that is created for and reserved from message brokers to publish information about the message broker to clients. In MQTT implementations of the invention, the server does not need to include the JWT in the messages transmitted to SSYS subscribing clients (i.e. internal clients), but rather can rely on the fact that subscribing clients listen to privileged SSYS topics (configured to allow access to a limited number of clients) and the server thus maintains security context per client identifier independently. We note that the SSYS prefix is used for special kinds of topics which transfer the broker-internal state and provide control API functions, so SSYS topics provide a suitable vehicle for the special measures we propose. That is, MQTT implementations of the invention may leverage the SSYS topic facility to provide a notification and propagation mechanism for security context (in the form of JWTs) to third party software which can cache it, additionally validate it and have it propagate further to other components if needed. Moreover, in MQTT implementations of the invention, the reserved SYS topic supports the lifecycle events: CONNECTED and DISCONNECTED which are issued when a particular client connects or disconnects, and also following a connection time-out. The server notifies connected internal systems through system (i.e. SSYS) topic about new client connections with its associated security token which can then be used by the internal systems themselves, and if needed can be propagated between internal systems. The internal clients are therefore kept up to date on connection status of external clients by the server issuing connect/disconnect events to SYS topic each time an external client connects/disconnects.
[0098] The MQTT server validates the JWT and builds a list of the above allowed topics for the MQTT client, persists in memory a security context associated with the underlying network connection (token, topics etc.) and publishes MQTT client details and security information into the SSYS topic:
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 validation of topics and security context protect access to messages based on topic Yegorin. The reason for this modification would be all granular control of events/message publication at the payload level.
Claim 2 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Lang/Yegorin as applied to claim 1 above, and further in view of Larsen US 2007/0124817.
Regarding claim 2, Lang/Yegorin do not teach the computer system further comprising having a software implemented and an operable translation code for interpreting STRIDE threat security policies and translating them into the DDS security policies Larsen in the same field of endeavor as the invention teaches system for assessment and remediation of security threats in a network. Larsen teaches the computer system further comprising having a software implemented and an operable translation code for interpreting STRIDE threat security policies and translating them into the DDS security policies stride based analysis to implement security on application messaging, ¶s22,25-28) .
[0022] Some disclosed embodiments include an operating system (OS) message security framework and method which can be used to address threats of attackers sending certain types of messages to an application in order to achieve information disclosure, tampering and/or elevation of privilege. The goals of many hacking attempts, namely the previously mentioned Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and/or Elevation of privilege are a classification (called STRIDE) that describes the effects of realizing a threat and what the threat allows the attacker to accomplish. STRIDE is described, for example, in Writing Secure Code, Second Edition (Microsoft Press, 2003) by Michael Howard and David Blanc.
[0025] However, some messages can, in certain conditions, lead to attacks that could result in the information disclosure, tampering and/or elevation of privilege if care is not exercised while responding to the message. If controls contain sensitive data that the application tries to restrict access to (e.g., by making the control read-only, hiding the control, etc.), messages that remove the restriction can be sent from another process running on the same machine as the application. The following list describes some real-world scenarios that could result in the application being compromised:
[0026] Hiding the controls--The controls that contain data to which the user does not have access rights to view are hidden, i.e., access control is performed on the UI level and not the data level. If the correct combinations of messages are sent to the control from a malicious process created by a hacker, the controls could be made visible and sensitive data might be displayed, unless the application proactively does something to prevent the messages from taking effect.
[0027] A disabled or read only control--If a control is disabled or made read-only, preventing the user from changing the data within the control, various messages sent from a malicious process could make the edit control writable and the attacker might gain access to whatever data is in the control, unless the application proactively does something to prevent the enabling of the control.
[0028] A password edit control--If the edit control contains a password (shown as dots) sending a message that changes the control properties to a standard edit control could result in the password being shown as clear text. Numerous other scenarios exist, but common for many of them is the fact that if the application does not actively perform any actions to prevent the messages from affecting the state of the controls, situations leading to information disclosure, tampering and/or elevation of privilege are possible.
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/Yegorin with modeling and of threats using a STRIDE based threat model and translating the STRIDE threat model into security configurations as taught by Larsen. The reason for this modification would be implement security configurations using STRIDE threat model descriptions. Such a modification comprising a simple substitution of the high-level policy description with a known alternative STRIDE threat model description.
Regarding claim 5, Larsen teaches wherein the mapping to DDSSecurity configurations is performed using a STRIDE-based security model that classifies security threats into spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
[0022] Some disclosed embodiments include an operating system (OS) message security framework and method which can be used to address threats of attackers sending certain types of messages to an application in order to achieve information disclosure, tampering and/or elevation of privilege. The goals of many hacking attempts, namely the previously mentioned Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and/or Elevation of privilege are a classification (called STRIDE) that describes the effects of realizing a threat and what the threat allows the attacker to accomplish. STRIDE is described, for example, in Writing Secure Code, Second Edition (Microsoft Press, 2003) by Michael Howard and David Blanc.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Lang as applied to claim 3 above, and further in view of Larsen US 2007/0124817
Regarding claim 4, Lang does no teach further comprising preventing security threats and enforcing security policies on the computer system by further having a software implemented and an operable translation code for interpreting STRIDE threat security properties and translating into the security policies configurations. Larsen in the same field of endeavor as the invention teaches a system for security protection of application messaging. Larsen teaches preventing security threats and enforcing security policies on the computer system by further having a software implemented and an operable translation code for interpreting STRIDE threat security properties and translating into the security policies configurations (stride based analysis to implement security on application messaging, ¶s22,25-28) .
[0022] Some disclosed embodiments include an operating system (OS) message security framework and method which can be used to address threats of attackers sending certain types of messages to an application in order to achieve information disclosure, tampering and/or elevation of privilege. The goals of many hacking attempts, namely the previously mentioned Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and/or Elevation of privilege are a classification (called STRIDE) that describes the effects of realizing a threat and what the threat allows the attacker to accomplish. STRIDE is described, for example, in Writing Secure Code, Second Edition (Microsoft Press, 2003) by Michael Howard and David Blanc.
[0025] However, some messages can, in certain conditions, lead to attacks that could result in the information disclosure, tampering and/or elevation of privilege if care is not exercised while responding to the message. If controls contain sensitive data that the application tries to restrict access to (e.g., by making the control read-only, hiding the control, etc.), messages that remove the restriction can be sent from another process running on the same machine as the application. The following list describes some real-world scenarios that could result in the application being compromised:
[0026] Hiding the controls--The controls that contain data to which the user does not have access rights to view are hidden, i.e., access control is performed on the UI level and not the data level. If the correct combinations of messages are sent to the control from a malicious process created by a hacker, the controls could be made visible and sensitive data might be displayed, unless the application proactively does something to prevent the messages from taking effect.
[0027] A disabled or read only control--If a control is disabled or made read-only, preventing the user from changing the data within the control, various messages sent from a malicious process could make the edit control writable and the attacker might gain access to whatever data is in the control, unless the application proactively does something to prevent the enabling of the control.
[0028] A password edit control--If the edit control contains a password (shown as dots) sending a message that changes the control properties to a standard edit control could result in the password being shown as clear text. Numerous other scenarios exist, but common for many of them is the fact that if the application does not actively perform any actions to prevent the messages from affecting the state of the controls, situations leading to information disclosure, tampering and/or elevation of privilege are possible.
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 modeling and of threats using a STRIDE based threat model and translating the STRIDE threat model into security configurations as taught by Larsen. The reason for this modification would be implement security configurations using STRIDE threat model descriptions. Such a modification comprising a simple substitution of the high-level policy description with a known alternative STRIDE threat model description.
Regarding claim 6, Lang/Yegarin/Larsen does not teach wherein the threats security properties are authentication, integrity, non-repudiation, confidentiality, availability, authorization, or a combination thereof. Lee in the same field of endeavor as the invention teaches system for stride based cybersecurity analysis. Lee teaches wherein the threats security properties are authentication, integrity, non-repudiation, confidentiality, availability, authorization, or a combination thereof( threat properties include authentication, integrity, non-repudiation, confidentiality, availability, authorization, ¶56-63) .
[0056] When the user's selection is complete, in S520, the extractor 110 may extract the asset type and threat type (STRIDE) corresponding to the first threat scenario (e.g., the threat scenario of TS001) of the first damage scenario (e.g., the damage scenario of DS001 in FIG. 2) among the damage scenarios selected by the user, and provide the asset type and threat type to the searcher 120.
[0057] According to the threat type (STRIDE) classification, it is possible to classify threats corresponding to each of the six goals by adding three elements of authentication, non-repudiation and authorization to three security elements of confidentiality, integrity and availability.
[0058] In this case, spoofing, which is related to authentication among security attributes, may identify threats to obtain system privileges using a false account or the like.
[0059] Tampering, which is related to integrity among security attributes, may identify threats that illegally change data.
[0060] Repudiation, which is related to non-repudiation among security attributes, may identify threats that deny that a specific service has not been performed or that it is not responsible.
[0061] Information disclosure, which is related to confidentiality among security attributes, may identify threats that provide information to someone who does not have access rights.
[0062] Denial of Service, which is related to availability among security attributes, may identify threats that prevent a service or application from being performed normally.
[0063] Elevation of privileges, which is related to authorization among security attributes, may identify a threat that allows someone to perform an unauthorized service by receiving authorization.
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/Yegorin/Larsen with STRIDE properties as taught by Lee. The reason for this modification would be implement security configurations using STRIDE know properties for STRIDE threat evaluation. Such a modification comprising a simple substitution with a known properties used for STRIDE threat modeling.
Applicant Remarks
Applicant’s arguments with respect to claim(s) 1-4 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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, Emmanuel Moise, can be reached on (571)272-3865. 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