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 .
Response to Arguments
In the remarks filed on 06/09/2026. The applicant amended claims 1,2, 11, and 16 are amended. No claims were added.
With respect to claim objections:
Applicant’ claim amendments and remarks filed on 06/09/2026 have been fully considered and does not fully overcome the claim objections as presented in the non-final office action filed 02/09/2026. Therefore, objections have been maintained.
With respect to 35 U.S.C.§112(b)::
Applicant’ claim amendments and remarks filed on 06/09/2026 have been fully considered and overcome the 112(b) rejections as presented in the non-final office action filed 02/09/2026. Therefore, 112(b) rejections have been withdrawn.
With respect to 35 U.S.C. § 103 rejections:
Applicants’ arguments filed on 06/09/2026 have been received and entered.
Applicants’ arguments with respect to the newly amended independent claims, see Applicant Arguments 2-5, with respect to the rejection (s) of independent claims 1,11 and 16 have been fully considered.
Applicant argues that Shubhabrata generates only a single contextual score for an asset and does not assign different contextual scores to the same contextual information depending on the security issue. Examiner understand the applicant’s perspective; however, examiner respectfully disagrees. Shubhabrata expressly discloses that “for each vulnerability considered by the vulnerability module 306, the contextual module 310 generates a contextual score 216. To generate the contextual score 216”. Shubhabrata further explains that contextual module generates the contextual score by corelating “aspects of the specified vulnerability, e.g., from vulnerability data 210, and aspects of the asset 224, e.g., from metadata in tags 202”. Shubhabrata therefore does not generate a contextual score based solely on the identity or characteristics of the asset. Rather, contextual score 216 is specific to the relationship between a particular vulnerability and the contextual information of the asset.
Shubhabrata further expressly teaches that dynamic contextual information such as “virus found or intrusion detected” may produce “a high contextual score 216 in and of themselves” and may produce “an even higher contextual score 216 when corelated with certain types of vulnerabilities, such as vulnerabilities that rely on insertion of virus or repeated intrusions”. Accordingly, when the same asset includes a first vulnerability relaying on virus insertion and a second vulnerability that does not rely on virus insertion, the same VIRUS FOUND contextual information produces an even higher contextual score when mapped to the first vulnerability and high contextual score when mapped to the second vulnerability. Thus, Shubhabrata teaches or at least suggests assigning different contextual scores to the same contextual information instance based on the security issue to which the contextual information is mapped.
Applicant contends that Shubhabrata generates “one contextual score per(asset, vulnerability) evaluation does not distinguish the claim. Because Shubhabrata evaluates each vulnerability associated with an asset separately while using the workload context of that same asset, separate evaluations of the first and second vulnerabilities provide the claimed first and second contextual scores for the same contextual information instance. Applicant additionally argues that the claimed CSM itself must store two contextual scores. Claim 1, however, does not require a particular physical matrix layout or permanently store score fields. The claim broadly recites a structured data representation that maps security issues to contextual information. Shubhabrata discloses data structures corelating each vulnerability asset, CVSS score, tag information, contextual score, and prioritization score, and states that associated entries may be linked in a database, arranged in rows or columns of table, or listed sequentially in a file. These corelated data structures reasonably teach the recited structure data representation under BRI. Green is relied upon for the security risk management framework, and security posture visualization, while Shubhabrata is relied upon for vulnerability specific contextual correlation and scoring. Thus, the combined teaching of Green and Shubhabrata teaches the amended claim 1. Therefore, the 103 rejection is maintained.
Claim Objections
Regarding claim 1,11, and 16, Claim 1, 11, and 16 are objected to because of the following informalities: In line 16, “base sores to security issues” should read “base sores to the plurality of security issues”. In line 21 “wherein the CMS” should read “wherein the CSM”, and “is assign” should read “is assigned”. Appropriate correction is required.
Regarding claim 2, Claim 2 is objected to because of the following informalities: In claim 2 , “a contextual security matrix model generator associated with a security risk management engine, supports generating the CSM model associated with security issue data, the contextual information, and recommended remediation action data of the CSM” is grammatically broken (i.e., missing proper punctuation and verb structure) and makes the scope of claim 2 unclear. Appropriate correction is required.
Regarding dependent claims 4-7, 9-10, 13, 15, 17, 19, and 20, these claims use “the security issue” even though their respective independent claims identify both “a first security issue” and “a second security issue”. This creates ambiguity and inconsistency. The overall claim sets focus their scoring, visualization, remediation operations primarily on the first security issue, examiner suggest applicant to modify “the security issue” with “the first security issue”.
Regarding claim 11, Claim 11 is objected to because of the following informalities: The limitation “includes the CSM based risk for the first security issue” should read “the CSM based risk score for the first security issue”. “security exposure associated with a security issue” should read “ security exposure associated with the first security issue” as claim 1. Appropriate correction is required.
Regarding claim 16, Claim 16 is objected to because of the following informalities: The limitation “security posture visualization comprises the security issue” should read “security posture visualization comprises the first security issue”. “security exposure associated with a security issue” should read “ security exposure associated with the first security issue” as claim 1. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Green (US 20190312905 A1) in view of Shubhabrata (US 9692778 B1).
Regarding claim 1, Green teaches a computerized system comprising: one or more computer processors; computer memory storing computer-useable instructions that, when used by the one or more computer processors, cause the one or more computer processors to perform operations, the operations (Green, a non-transitory computer readable medium is disclosed comprising instructions for determining a secured system security risk score. The instructions may cause the system to execute a method, [0006] one or more processors, for executing program instructions, [0071]) comprising:
accessing a first security issue associated with a computing device in a computing environment (Green, receiving, on an electronic network, security data corresponding to a security vulnerability of each of a plurality of servers, each of the plurality of servers being associated with a secured system, [0004] Fig 22, At step 2905, on an electronic network, security data are received corresponding to at least one security vulnerability associated with each of a plurality of servers, each of the plurality of servers being associated with a secured system, [0063]);
identifying contextual information associated with the first security issue, wherein the contextual information comprises a computing environment configuration or state that affects a security exposure of the first security issue on the computing environment (Green, Systems detects and categorizes security vulnerabilities, and modify the assessed risk level of data sources, servers, Internet of Things (IoT) devices, systems, etc., based on the categorization. The assessed risk level are modified over time based upon predetermined rules, such as the time since discovery, and mitigation steps taken, [0034] FIG. 3, mitigation steps are taken based on risks and impacts that have been identified such as applying mitigation at the server level since it is a result of the environment where the server resides and the protection system installed on the server. The mitigation environment reflects varying levels of network, server, and data protection. For example, a high-risk environment 905 is protected by a few risk mitigating components such as whitelists or a demilitarized zone/perimeter network. A server obtains a medium mitigated risk by being associated with a medium-risk environment 910, which add additional mitigating components such as putting the server behind a first firewall, exposing it to antivirus protection, etc. [0045] Risk levels of servers can be upgraded and downgraded. For example, a medium-risk server 1025 can be moved to a high-risk environment 905, and the server can be upgraded to a high-risk server 1030, [0046])[Examiner interprets that system detecting and categorizing vulnerabilities by evaluating factors such as whether the server is in DMZ versus firewall (i.e., contextual information such as environment configuration or state), then modifying the overall assessed risk level accordingly as limitation above];
wherein the CSM is generated using a CSM model that is a computational framework that algorithmically assigns base-scores to security issues (Green, FIG. 21 is a listing of formulas that may be used to determine risk levels and/or scores discussed herein. As discussed above, a base score may be determined at step 2405 that may be an aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score may also be determined at step 2410. For example, system security metrics may be averaged to determine an overall mitigated risk level and/or mitigated risk level score, [0062] a server security vulnerability score may be determined, for each of the plurality of servers, based on the security data corresponding to the at least one security vulnerability for each of the plurality of servers, [0063]) [Examiner interprets that system assigning a base score/risk score based on vulnerability/ security data and normalized rating (i.e., algorithmic scoring framework)];
based on the CSM-based risk score, generating a security posture visualization associated with the computing environment, wherein the security posture visualization comprises the first security issue associated with the CSM-based risk score (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. The system displays risk or other information associated with PEO 1510, [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060]) [Examiner interprets that displaying relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores as based on the CSM-based risk score, generating a security posture visualization associated with the computing environment, wherein the security posture visualization comprises the security issue associated with the CSM-based risk score]; and
communicating the security posture visualization to cause display of the security posture visualization (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. A user can select a particular PEO level 1510, which causes the system to display risk or other information associated with PEO 1510, [0058]) [Examiner interprets that the user selecting to display risk posture or other information as communicating the security posture visualization to cause display of the security posture visualization].
Although, Green teaches structured scoring such as normalized inputs, multipliers/mitigators, formulas/steps to compute risk scores based on factors like mitigation environment, elapsed time, escalation thresholds and impacts is functionally similar to mapping (issue and context) to modified score, Plurality of security issues (i.e., many vulnerabilities across many servers and multiple factors are used to compute scores), base score, and multiple modifiers/factors contributing to a final risk score, and the logical representation of relationships between security issues, contextual information, and associated risk scores, Green does not explicitly teach an explicit matrix data structure:
accessing a contextual security matrix (CSM) that is a structured data representation that maps a plurality of security issues to one or more instances of the contextual information, wherein the CSM includes at least the first security issue and a second security issue, wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score, wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different; based on the first base score of the first security issue and the one or more contextual scores of the first security issue, generating a CSM-based risk score that quantifies the security exposure associated with the first security issue;
However, Shubhabrata teaches:
accessing a contextual security matrix (CSM) that is a structured data representation that maps a plurality of security issues to one or more instances of the contextual information (Shubhabrata, system and method employ an algorithm that correlates vulnerabilities with contextual information such as threat data and virtualization tags (e.g., as provided in the virtualization environment by a vendor such as VMware, etc.). The algorithm works on a three-dimensional (or three axis) model in some embodiments. The three dimensions are summarized below: Dimension#1—Vulnerability (e.g., as reported by vulnerability assessment products). Related data could include base/temporal CVSS score, common vulnerabilities and exposures identifier (CVE ID), severity, etc. Dimension#2—Threat (e.g., threats received from Threat Intelligence systems such as DeepSight). Related data could include threat impact, impacted CVE ID, type of threat, operating system impacted, applications impacted, etc. Dimension#3—Workload Context: Tags (e.g., Operational Tags as well as Security Tags, i.e., static tags and dynamic tags, as defined in a virtualization environment using VMware, etc.) (See Col 3, lines 43-67) A vulnerability score 212, a threat score 214, and a contextual score 216 are combined to form a prioritization score 218., (see, col 6, lines 1-3) The contextual module 310 tracks the workload context 102 of each of the assets 224, for example by establishing a data structure in memory and populating the data structure with information derived from the tags 202…. For each asset 224, and for each vulnerability considered by the vulnerability module 306, the contextual module 310 generates a contextual score 216. To generate the contextual score 216, the contextual module 310 correlates aspects of the specified vulnerability, e.g., from vulnerability data 210, and aspects of the asset 224, e.g., from metadata in tags 202. In some embodiments, for a specified asset 224 and a vulnerability specified by a CVE ID 220, the contextual module 310 determines whether the vulnerability matches the asset 224, (see, Col 8, lines 19-40)) [In light of specification CSM defines how security issue is affected by each contextual information and operates as data structure, see instant application at par [0026,0061, 0032], Examiner interprets that Vulnerability as security issue, Tags/workload context as contextual information, generated contextual score as contextual score, a specific tag instance such as INTERNET FACING, CRITICAL DATA as first instance of contextual information, contextual score 216 for that vulnerability asset context correlation as first contextual score, and data structure established and populated in memory by contextual module (e .g., tables, linked records or multidimensional data representations corelating vulnerabilities assets and contextual attributes) as contextual security matrix (CSM) + 3 axis model as CSM model].
wherein the CSM includes at least the first security issue and a second security issue, wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score (Shubhabrata, a mission critical Internet Banking web server may have multiple known vulnerabilities, but which of those present genuine risk to the organization may be unknown, (Col 3, lines 30-33) VA products known as scanners scan virtual machines and report vulnerabilities with additional information such as Severity, Base CVSS Score 222, Temporal CVSS Score 222, and CVE ID 220. The vulnerability data 210 provided by such a scanner applies to a particular asset 224 being scanned.1 The CVSS score 222, which can include a base score and a temporal score, may be resolved or analyzed into metrics and vectors, and the vulnerability score 212 can be based on the CVSS score 222, (Col 4, lines 59-67) Vulnerability Score 212 represents CVSS Score 222 (Base or Temporal as reported by VA products), e.g., as associated or correlated with a particular vulnerability or exposure which may be accompanied by a CVE ID 220. This score is expressed on a scale of 1-10, or 0-10, (Col 6, lines 12-16) The vulnerability module 306 of FIG. 3 tracks specific vulnerabilities for each asset 224, for example by establishing a data structure in memory and populating the data structure with information about each vulnerability relative to each asset 224. When vulnerability data 210 is received by the computing device 302, the vulnerability module 306 tracks the association of CVE ID 220, CVSS score 222, severity and exploitability information (when available) for each such vulnerability or exposure, for each asset 224, so that these are correlated, For example, various associated entries could have links in a database, be on the same row or column in a table, or be listed sequentially in a file, etc. The vulnerability module 306 produces a vulnerability score 212, for each vulnerability for each asset 224, which could be the base CVSS score 222 or the temporal CVSS score 222 or a combination thereof, (Col 7, lines 14-29)) [Examiner interprets that system associating an individualized Base CVSS score with each vulnerability as limitation above].
wherein the CMS includes a first instance of contextual information that is assigns a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue wherein the first contextual score and the second contextual score are different; (Shubhabrata, For each asset 224, and for each vulnerability considered by the vulnerability module 306, the contextual module 310 generates a contextual score 216. To generate the contextual score 216, the contextual module 310 correlates aspects of the specified vulnerability, e.g., from vulnerability data 210, and aspects of the asset 224, e.g., from metadata in tags 202, for a specified asset 224 and a vulnerability specified by a CVE ID 220, the contextual module 310 determines whether the vulnerability matches the asset 224. Consider a vulnerability to data access, as an aspect of a vulnerability specified by a CVE ID 220, and an asset 224 that handles sensitive data. This would be a strong match or correlation and would generate a higher contextual score 216. A vulnerability to data access, and an asset 224 that does not have sensitive data, would generate a lower contextual score 216. A vulnerability to crashing a system, and an asset that has a critical server, would generate a higher contextual score 216 than would be the case for an asset that does not have a critical server. A vulnerability that relies on access via the Web, and an asset that has Web-connectivity, would generate a higher contextual score 216 than would be the case for an asset that does not have Web-connectivity. Certain types of dynamic tag information 206, such as virus found or intrusion detected, could produce a high contextual score 216 in and of themselves, and would produce an even higher contextual score 216 when correlated with certain types of vulnerabilities, such as vulnerabilities that rely on insertion of a virus or repeated intrusions. In some embodiments, threat information 208 is correlated with information from tags 202, in production of the contextual score 216. Further correlations of this nature are readily understood, (Col 8, lines 28-59)] Examiner interprets that system generating a contextual score separately for each vulnerability based on correlation between the particular vulnerability and the contextual information such that the same contextual information may result in different contextual cores depending upon the vulnerability to which the contextual information is corelated as limitation above] and
based on the first base score of the first security issue and the one or more contextual scores of the first security issue, generating a CSM-based risk score that quantifies the security exposure associated with the first security issue (Shubhabrata, A vulnerability score 212, a threat score 214, and a contextual score 216 are combined to form a prioritization score 218. The prioritization score 218 can be applied to indicate the impact or severity of vulnerability, so that vulnerabilities can be prioritized as to which ones need attention or remediation, (Col 6, lines 1-6) Vulnerability Score 212 represents CVSS Score 222 (Base or Temporal as reported by VA products), e.g., associated or correlated with a particular vulnerability or exposure which may be accompanied by a CVE ID 220. This score is expressed on a scale of 1-10, or 0-10, Contextual Score 216 represents Tags 202 (both Static and Dynamic Tags) correlated with Threats and Vulnerabilities. A score is derived in a scale of 1-10, Prioritization Score 218 equals (Vulnerability Score 212×Threat Score 214×Contextual Score 216)/100. This is for a particular vulnerability or exposure, which is now prioritized, (Col 6, lines 12-26) The embodiments of the system and method described herein correlate vulnerabilities with emerging threats to derive threat exposure, the risk the vulnerability poses, and the importance of remediating such risk, (Col 4, lines 35-39) The vulnerability score, the threat score and the contextual score, and the prioritization score, are specific to the asset, and are specific to a particular vulnerability, e.g. the vulnerability identified by or associated with the CVSS score and/or the CVE ID, in various embodiments. The prioritization score provides a measure of a context-dependent vulnerability of an asset. In a decision action 416, it is determined whether the prioritization score meets a threshold. If the answer is no, the prioritization score does not yet meet a threshold, flow branches back to the action 402, in order to update the prioritization score, (Col 10 ,lines 12-22)) [Examiner interprets that system generating the contextual score for each vulnerability based on relationship between the vulnerability and contextual information, and calculating prioritization score using the vulnerability/base score and contextual score and quantifying context dependent vulnerability/risk as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Green to include a concept of accessing a contextual security matrix (CSM) that is a structured data representation that maps a plurality of security issues to one or more instances of the contextual information, wherein the CSM includes at least the first security issue and a second security issue, wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score, wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different; based on the first base score of the first security issue and the one or more contextual scores of the first security issue, generating a CSM-based risk score that quantifies the security exposure associated with the first security issue as taught by Shubhabrata for the purpose of combining vulnerability score 212, and a contextual score 216 to form a prioritization score 218 which can be applied to indicate the impact or severity of vulnerability, so that vulnerabilities can be prioritized as to which ones need attention or remediation, [Shubhabrata: (col 6, lines 1-6)].
Regarding claim 2, Green and Shubhabrata teaches the system of claim 1, wherein a contextual security matrix model generator, associated with a security risk management engine, supports generating the CSM model associated with security issue data, the contextual information, and recommended remediation action data of the CSM (Green, FIG. 2, data sources 205 comprises one or more servers connected to an electronic network, of an organization. The data sources 205 provides data derived by the analysis of security information 205 at the server level for each server, for example, by IP address. Each data source 205 is processed by the Active Engine 207 (i.e., a security risk management engine or a CSM model) to normalize the data then gets analyzed to establish security risk status. The risk level of each server in the cluster/hierarchy of servers 210 is evaluated independently. Once a base level of risk is determined for servers 215, this base level are modified based on a variety of factors, [0044] Fig 21 a base score is determined at step 2405 that using aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score is determined at step 2410 by averaging system security metrics to determine an overall mitigated risk level and/or mitigated risk level score. Confidentiality, integrity, and/or availability scores/multipliers is used to determine the mitigated risk level. At step 2415, the risk level can be escalated by one or more authorized users by setting one or more threshold frequencies, At step 2420, an impact assessment is determined, which determines remediation priority. At step 2425, an overall system risk (i.e., the security exposure) is determined based on the determined base level risk (i.e., security issue base-scores of security issues) , mitigated risk level (i.e., CSM-based risk scores) , escalation, and/or impact assessment (i.e., contextual scores of instances of contextual information). For example, one or more of these values are averaged to determine the system level risk, [0062]) [Examiner interprets that active engine analyzing data sources that provides contextual data (i.e., server specific details) to establish risk status and system further adjusting and refining the risk level by aggregating scores and incorporating contextual and mitigation data as limitation above].
Green does not explicitly teach:
a contextual security matrix model generator generating the CSM model
However, Shubhabrata teaches:
a contextual security matrix model generator generating the CSM model (Shubhabrata, system and method employ an algorithm that correlates vulnerabilities with contextual information such as threat data and virtualization tags (e.g., as provided in the virtualization environment by a vendor such as VMware, etc.). The algorithm works on a three-dimensional (or three axis) model in some embodiments. The three dimensions are summarized below: Dimension#1—Vulnerability (e.g., as reported by vulnerability assessment products). Related data could include base/temporal CVSS score, common vulnerabilities and exposures identifier (CVE ID), severity, etc. Dimension#2—Threat (e.g., threats received from Threat Intelligence systems such as DeepSight). Related data could include threat impact, impacted CVE ID, type of threat, operating system impacted, applications impacted, etc. Dimension#3—Workload Context: Tags (e.g., Operational Tags as well as Security Tags, i.e., static tags and dynamic tags, as defined in a virtualization environment using VMware, etc.) (See Col 3, lines 43-67) The contextual module 310 tracks the workload context 102 of each of the assets 224, for example by establishing a data structure in memory and populating the data structure with information derived from the tags 202…. For each asset 224, and for each vulnerability considered by the vulnerability module 306, the contextual module 310 generates a contextual score 216. To generate the contextual score 216, the contextual module 310 correlates aspects of the specified vulnerability, e.g., from vulnerability data 210, and aspects of the asset 224, e.g., from metadata in tags 202. In some embodiments, for a specified asset 224 and a vulnerability specified by a CVE ID 220, the contextual module 310 determines whether the vulnerability matches the asset 224, (see, Col 8, lines 19-40)) [In light of specification, CSM model requires a model that defines scoring relationships, examiner interprets that 3 axis correlation algorithm defining the relationship between base scores, vulnerabilities and their workload context or contextual information as a contextual security matrix model generator generating the CSM model] Same motivation applies as claim 1.
Regarding claim 3, Green and Shubhabrata teaches the system of claim 1, wherein the CSM is a scored representation of how each of the plurality of security issues is affected by corresponding contextual information (Green, FIG. 2, Each data source 205 is processed by the Active Engine 207 (i.e., a CSM model) to normalize the data then gets analyzed to establish security risk status (i.e., a plurality of security issues). The risk level of each server in the cluster/hierarchy of servers 210 is evaluated independently. Once a base level of risk is determined for servers 215, this base level are modified based on a variety of factors, [0044] Fig 6, table 1205 (i.e., the CSM matrix) containing data feed vulnerabilities (i.e., the plurality of security issues) vs frequency in days and risk thresholds (i.e., the contextual information and scores) [0048] in Fig 20, in table 2005, (i.e., the CSM matrix) tabulate normalized score from multiple data sources into composite risk, [0061] Fig 21 a base score is determined at step 2405 that using aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score is determined at step 2410 by averaging system security metrics to determine an overall mitigated risk level and/or mitigated risk level score. Confidentiality, integrity, and/or availability scores/multipliers is used to determine the mitigated risk level. At step 2415, the risk level can be escalated by one or more authorized users by setting one or more threshold frequencies, At step 2420, an impact assessment is determined, which determines remediation priority. At step 2425, an overall system risk (i.e., the security exposure) is determined based on the determined base level risk (i.e., security issue base-scores of security issues) , mitigated risk level, escalation, and/or impact assessment (i.e., contextual scores of instances of contextual information). For example, one or more of these values are averaged to determine the system level risk, [0062]) [Examiner interprets that active engine (i.e., a CSM model) analyzing data sources that provides security issues and contextual data (i.e., server specific details) to establish risk status and system further adjusting and refining the risk level by aggregating scores based on contextual data from data sources (i.e. multiple servers) and configuring those scores in the tabular format (i.e., CSM matrix) form as wherein the CSM is a scored representation of how each of the plurality of security issues is affected by corresponding contextual information].
Regarding claim 4, Green and Shubhabrata teaches the system of claim 1, wherein the CSM further comprises one or more recommended remediation actions that are mapped to the security issue, wherein a recommended remediation action is an actionable item that is performed to mitigate the security issue in the computing environment (Green, Fig 3, mitigation steps (i.e., a remediation action) is taken based on risks and impacts that have been identified. Mitigation is applied at the server level since it is a result of the environment where the server resides and the protection system installed on the server. The mitigation environment reflect varying levels of network, server, and data protection. For example, a high-risk environment 905 is protected by a few risk mitigating components such as white lists or a demilitarized zone/perimeter network. A server obtain a medium mitigated risk by being associated with a medium-risk environment 910, which can add additional mitigating components such as putting the server behind a first firewall, exposing it to antivirus protection, etc. These support and protection structures are layered to protect the server and/or system and mitigate the base risk. For example, all protections of the high-risk environment 905 automatically be present in the medium and low-risk environments 910 and 915. Mitigation data is inputted by an authorized user(s),[0045] the remediation priority algorithm is configurable by a user or organization. For example, a system with a medium-risk level but high security impact can be automatically assigned a higher remediation priority than a system with a high security risk level but a low security impact. Thus, remediation priorities 705 are set to automatically, and categorically, prioritize higher security impact systems, or set to prioritize higher risk level systems, depending upon user and/or organizational requirements, [0054]) [Examiner interprets that system or user assigning different remediation priorities to mitigate different vulnerabilities based on their risk levels (i.e. security issues) as the CSM further comprises one or more recommended remediation actions that are mapped to the security issue, wherein a recommended remediation action is an actionable item that is performed to mitigate the security issue in the computing environment].
Regarding claim 5, Green and Shubhabrata teaches the system of claim 1, wherein the base-score of the security issue is a predefined score of the security issue and a contextual score of an instance of the contextual information is a quantified additional security exposure of the security issue based on the instance of the contextual information, wherein the quantified additional security exposure is associated with a potential impact or a potential exploitability (Green, FIG. 2, data sources 205 comprises one or more servers connected to an electronic network, of an organization which provides data derived by the analysis of security information 205 at the server level for each server, for example, by IP address. Each data source 205 is processed by the Active Engine 207 (i.e., a security risk management engine) to normalize the data. Each data source 205, for example, Assured Compliance Assessment Solution (ACAS) scan results and gets analyzed to establish security risk status (i.e., a plurality of security issues). The risk level of each server in the cluster/hierarchy of servers 210 is evaluated independently. Once a base level of risk is determined for servers 215, this base level can be modified based on a variety of factors, [0044] mitigation steps (i.e., a remediation action) is taken based on risks and impacts that have been identified. Mitigation is applied at the server level since it is a result of the environment where the server resides and the protection system installed on the server. The mitigation environment reflect varying levels of network, server, and data protection. For example, a high-risk environment 905 is protected by a few risk mitigating components such as white lists or a demilitarized zone/perimeter network. A server obtain a medium mitigated risk by being associated with a medium-risk environment 910, which can add additional mitigating components such as putting the server behind a first firewall, exposing it to antivirus protection, etc. These support and protection structures are layered to protect the server and/or system and mitigate the base risk. For example, all protections of the high-risk environment 905 automatically be present in the medium and low-risk environments 910 and 915. Mitigation data is inputted by an authorized users. By adding additional predetermined mitigating measures, a server's security risk is improved substantially by environmental protections,[0045] Fig 21 a base score is determined at step 2405 that using aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score is determined at step 2410 by averaging system security metrics to determine an overall mitigated risk level and/or mitigated risk level score. Confidentiality, integrity, and/or availability scores/multipliers is used to determine the mitigated risk level. At step 2415, the risk level can be escalated by one or more authorized users by setting one or more threshold frequencies, At step 2420, an impact assessment is determined, which determines remediation priority. At step 2425, an overall system risk (i.e., the security exposure) is determined based on the determined base level risk (i.e., security issue base-scores of security issues) , mitigated risk level (i.e., CSM-based risk scores) , escalation, and/or impact assessment (i.e., contextual scores of instances of contextual information). For example, one or more of these values are averaged to determine the system level risk, [0062]) [Examiner interprets that receiving security data corresponding to security vulnerability from scanning tools (e.g., ACAS) and analyzing the normalized data to base score of each servers (i.e., predefined vulnerability severity) and multiplying mitigation risk level, escalation, and/or impact assessment (i.e. a contextual score of an instance of contextual information) and adjusting and modifying the risk levels by applying better mitigation steps in order to decrease the initial vulnerability rating for better protections as limitation above].
Regarding claim 6, Green and Shubhabrata teaches the system of claim 1, wherein the security issue is associated with the first instance of the contextual information and a second instance of the contextual information, the first instance of the contextual information is associated with the first contextual score and the second instance of the contextual information is associated with a second contextual score (Green, FIG. 4, an individual server 1005 that is high risk receives active mitigation in a low-risk environment 915 and can be downgraded to medium risk 1010. Risk levels of servers can also upgrade. For example, a medium-risk server 1025 may be moved to a high-risk environment 905, can be upgraded to a high-risk server 1030 (i.e., a first instance of contextual information), [0046] Fig 22, At step 2905, on an electronic network, security data is received corresponding to at least one security vulnerability (i.e., the security issues) associated with each of a plurality of servers, each of the plurality of servers being associated with a secured system. At step 2910 a server security vulnerability score may be determined, for each of the plurality of servers, based on the security data corresponding to the at least one security vulnerability for each of the plurality of servers. At step 2915 the server security vulnerability score can be modified, for each of the plurality of servers, based on a time elapsed since a discovery of at least one security vulnerability ( i.e., a second instance of contextual information), [0063]) [Examiner interprets that each vulnerability of different servers are dependent on multiple contextual factors such as (i.e., time, environment, mitigation steps) simultaneously each contributing an independent contextual scores that modifies the base security issue score as limitation above].
Regarding claim 7, Green and Shubhabrata teaches the system of claim 1, wherein the CSM-based risk score is generated based on a sum of the base-score of the security issue and a contextual score of one or more instances of the contextual information of the security issue (Green, Fig 21 a base score is determined at step 2405 that using aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score is determined at step 2410 by averaging system security metrics to determine an overall mitigated risk level and/or mitigated risk level score. Confidentiality, integrity, and/or availability scores/multipliers is used to determine the mitigated risk level. At step 2415, the risk level can be escalated by one or more authorized users by setting one or more threshold frequencies, At step 2420, an impact assessment is determined, which determines remediation priority. At step 2425, an overall system risk (i.e., the CSM-based risk score) is determined based on the determined base level risk (i.e., security issue base-scores of security issues) , mitigated risk level, escalation, and/or impact assessment (i.e., a contextual score of one or more instances of contextual information of the security issue). For example, one or more of these values are averaged to determine the system level risk, [0062] Techniques presented applies multipliers and mitigators to increment and decrement a meta risk score for servers, systems, IoT devices, environments, other devices, etc., associated with an organization. Multipliers may be increased based upon the discovery dates of vulnerabilities, the lifespan of vulnerabilities, and/or remediation types and dates, [0066]) [Examiner interprets that calculating overall risk of system based on base level risk (i.e., security issue base-scores of security issues) and mitigated risk level, escalation, and/or impact assessment collectively (i.e., a contextual score of one or more instances of contextual information of the security issue) using multipliers and mitigators to increase or decrease the risk levels as limitation above].
Regarding claim 8, Green and Shubhabrata teaches the system of claim 1, wherein a security posture management engine supports generating the security posture visualization comprising the plurality of security issues, wherein the plurality of security issues are associated with corresponding CSM-based risk scores and the contextual information, wherein the security posture visualization comprises each of the plurality of security issues as alerts, wherein an alert comprises a prioritization identifier and a recommended remediation action, wherein the recommended remediation action is executable to address a security threat associated with the alert (Green, the remediation priority algorithm is configurable by a user or organization. For example, a system with a medium-risk level but high security impact can be automatically assigned a higher remediation priority than a system with a high security risk level but a low security impact. Thus, remediation priorities 705 are set to automatically, and categorically, prioritize higher security impact systems, or set to prioritize higher risk level systems, depending upon user and/or organizational requirements, [0054] FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. For example, a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510. [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060]) [Examiner interprets that displaying risk posture or other information such as relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores and color-coding based on associated risk levels (i.e., alerts) and setting up remediation priority based on risk levels to automatically, and categorically, prioritize higher security impact systems as limitation above].
Regarding claim 9, Green and Shubhabrata teaches the system of claim 1, the operations further comprising: communicating, from a security management client, a request for a security posture of the computing environment; based on the request, receiving the security posture visualization associated with the computing environment, wherein the security posture visualization comprises an alert associated with the computing device, the security issue, and an instance of the contextual information associated with the security issue; and causing display of the security posture visualization (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. For example, a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510. [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060]) [Examiner interprets that user selecting to display risk posture or other information such as relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores as communicating, from a security management client, a request for a security posture of the computing environment; based on the request, receiving the security posture visualization associated with the computing environment, wherein the security posture visualization comprises an alert associated with the computing device, the security issue, and an instance of contextual information associated with security issue; and causing display of the security posture visualization].
Regarding claim 10, Green and Shubhabrata teaches the system of claim 1, the operations further comprising: receiving an indication to execute a recommended remediation action associated with the security issue, wherein the recommended remediation action is associated with the security posture visualization; and communicating the indication to execute the recommended remediation action to cause execution of the recommended remediation action (Green, Fig 3, mitigation steps (i.e., a remediation action) is taken based on risks and impacts that have been identified. Mitigation is applied at the server level since it is a result of the environment where the server resides and the protection system installed on the server. The mitigation environment reflect varying levels of network, server, and data protection. For example, a high-risk environment 905 is protected by a few risk mitigating components such as whitelists or a demilitarized zone/perimeter network. A server obtain a medium mitigated risk by being associated with a medium-risk environment 910, which can add additional mitigating components such as putting the server behind a first firewall, exposing it to antivirus protection, etc. These support and protection structures are layered to protect the server and/or system and mitigate the base risk. For example, all protections of the high-risk environment 905 automatically be present in the medium and low-risk environments 910 and 915. Mitigation data is inputted by an authorized user(s),[0045] the remediation priority algorithm is configurable by a user or organization. For example, a system with a medium-risk level but high security impact can be automatically assigned a higher remediation priority than a system with a high security risk level but a low security impact. Thus, remediation priorities 705 are set to automatically, and categorically, prioritize higher security impact systems, or set to prioritize higher risk level systems, depending upon user and/or organizational requirements, [0054] a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510, [0058]) [Examiner interprets that user clicking the button to execute different remediation priorities via security posture visualization and mitigate different vulnerabilities by applying different changes on the displayed visualization posture as limitation above].
Regarding claim 11, Green and Shubhabrata teaches one or more computer-storage media having computer-executable instructions embodied thereon that, when executed by a computing system having a processor and memory, cause the processor to perform operations, the operations (Green, a non-transitory computer readable medium is disclosed comprising instructions for determining a secured system security risk score. The instructions may cause the system to execute a method, [0006] one or more processors, for executing program instructions, [0071]) comprising:
communicating a request for a security posture of a computing environment (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. A user can select a particular PEO level 1510, which causes the system to display risk or other information associated with PEO 1510, [0058]) [Examiner interprets that the user selecting to display risk posture or other information as communicating a request for a security posture of a computing environment];
based on the request, receiving a security posture visualization associated with the computing environment, wherein the security posture visualization comprises a plurality of security issues having corresponding contextual security matrix (CSM)-based risk scores, wherein a CSM-based risk score quantifies a security exposure associated with a security issue (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. For example, a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510. [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060] Fig 21 a base score is determined at step 2405 that using aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score is determined at step 2410 by averaging system security metrics to determine an overall mitigated risk level and/or mitigated risk level score. Confidentiality, integrity, and/or availability scores/multipliers is used to determine the mitigated risk level. At step 2415, the risk level can be escalated by one or more authorized users by setting one or more threshold frequencies, as discussed elsewhere herein. At step 2420, an impact assessment is determined, which determines remediation priority. At step 2425, an overall system risk (i.e., the security exposure) is determined based on the determined base level risk (i.e., security issue base-scores of security issues) , mitigated risk level (i.e., CSM-based risk scores) , escalation, and/or impact assessment (i.e., contextual scores of instances of contextual information). For example, one or more of these values are averaged to determine the system level risk, [0062]) [Examiner interprets that user selecting to display risk posture or other information such as relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores (i.e., CSM based scores) as limitation above].
wherein the CSM is generated using a CSM model that is a computational framework that algorithmically assigns base-scores to security issues (Green, FIG. 21 is a listing of formulas that may be used to determine risk levels and/or scores discussed herein. As discussed above, a base score may be determined at step 2405 that may be an aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score may also be determined at step 2410. For example, system security metrics may be averaged to determine an overall mitigated risk level and/or mitigated risk level score, [0062] a server security vulnerability score may be determined, for each of the plurality of servers, based on the security data corresponding to the at least one security vulnerability for each of the plurality of servers, [0063]) [Examiner interprets that system assigning a base score/risk score based on vulnerability/ security data and normalized rating (i.e., algorithmic scoring framework)],
causing display of the security posture visualization, wherein the security posture visualization includes the CSM-based risk for the first security issue (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. For example, a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510. [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060]) [Examiner interprets that user selecting to display risk posture or other information such as relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores as causing display of the security posture visualization].
Although, Green teaches structured scoring such as normalized inputs, multipliers/mitigators, formulas/steps to compute risk scores based on factors like mitigation environment, elapsed time, escalation thresholds and impacts is functionally similar to mapping (issue and context) to modified score, Plurality of security issues (i.e., many vulnerabilities across many servers and multiple factors are used to compute scores), base score, and multiple modifiers/factors contributing to a final risk score, and the logical representation of relationships between security issues, contextual information, and associated risk scores, Green does not explicitly teach an explicit matrix data structure:
wherein the CSM-based risk score is generated using a CSM, wherein the CSM includes at least the first security issue and a second security issue, wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score; wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different;
However, Shubhabrata teaches:
wherein the CSM-based risk score is generated using a CSM (Shubhabrata, A vulnerability score 212, a threat score 214, and a contextual score 216 are combined to form a prioritization score 218. The prioritization score 218 can be applied to indicate the impact or severity of vulnerability, so that vulnerabilities can be prioritized as to which ones need attention or remediation, (see col 6, lines 1-6), A relatively high prioritization score 218 suggests the vulnerability in the asset 224 should be addressed by remediation. Vulnerability data 210 and/or threat information 208 can be consulted to guide the remediation effort, (see, col 9, lines 10-14)) [In light of specification, CSM based score quantifies security exposure (exploitability and impact), see instant application [0006], [0032], the prioritization score indicating the impact or severity as CSM based score].
wherein the CSM includes at least the first security issue and a second security issue, wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score (Shubhabrata, a mission critical Internet Banking web server may have multiple known vulnerabilities, but which of those present genuine risk to the organization may be unknown, (Col 3, lines 30-33) VA products known as scanners scan virtual machines and report vulnerabilities with additional information such as Severity, Base CVSS Score 222, Temporal CVSS Score 222, and CVE ID 220. The vulnerability data 210 provided by such a scanner applies to a particular asset 224 being scanned.1 The CVSS score 222, which can include a base score and a temporal score, may be resolved or analyzed into metrics and vectors, and the vulnerability score 212 can be based on the CVSS score 222, (Col 4, lines 59-67) Vulnerability Score 212 represents CVSS Score 222 (Base or Temporal as reported by VA products), e.g., as associated or correlated with a particular vulnerability or exposure which may be accompanied by a CVE ID 220. This score is expressed on a scale of 1-10, or 0-10, (Col 6, lines 12-16) The vulnerability module 306 of FIG. 3 tracks specific vulnerabilities for each asset 224, for example by establishing a data structure in memory and populating the data structure with information about each vulnerability relative to each asset 224. When vulnerability data 210 is received by the computing device 302, the vulnerability module 306 tracks the association of CVE ID 220, CVSS score 222, severity and exploitability information (when available) for each such vulnerability or exposure, for each asset 224, so that these are correlated, For example, various associated entries could have links in a database, be on the same row or column in a table, or be listed sequentially in a file, etc. The vulnerability module 306 produces a vulnerability score 212, for each vulnerability for each asset 224, which could be the base CVSS score 222 or the temporal CVSS score 222 or a combination thereof, (Col 7, lines 14-29)) [Examiner interprets that system associating an individualized Base CVSS score with each vulnerability as limitation above].
wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different (Shubhabrata, For each asset 224, and for each vulnerability considered by the vulnerability module 306, the contextual module 310 generates a contextual score 216. To generate the contextual score 216, the contextual module 310 correlates aspects of the specified vulnerability, e.g., from vulnerability data 210, and aspects of the asset 224, e.g., from metadata in tags 202, for a specified asset 224 and a vulnerability specified by a CVE ID 220, the contextual module 310 determines whether the vulnerability matches the asset 224. Consider a vulnerability to data access, as an aspect of a vulnerability specified by a CVE ID 220, and an asset 224 that handles sensitive data. This would be a strong match or correlation and would generate a higher contextual score 216. A vulnerability to data access, and an asset 224 that does not have sensitive data, would generate a lower contextual score 216. A vulnerability to crashing a system, and an asset that has a critical server, would generate a higher contextual score 216 than would be the case for an asset that does not have a critical server. A vulnerability that relies on access via the Web, and an asset that has Web-connectivity, would generate a higher contextual score 216 than would be the case for an asset that does not have Web-connectivity. Certain types of dynamic tag information 206, such as virus found or intrusion detected, could produce a high contextual score 216 in and of themselves, and would produce an even higher contextual score 216 when correlated with certain types of vulnerabilities, such as vulnerabilities that rely on insertion of a virus or repeated intrusions. In some embodiments, threat information 208 is correlated with information from tags 202, in production of the contextual score 216. Further correlations of this nature are readily understood, (Col 8, lines 28-59)] Examiner interprets that system generating a contextual score separately for each vulnerability based on correlation between the particular vulnerability and the contextual information such that the same contextual information may result in different contextual cores depending upon the vulnerability to which the contextual information is corelated as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Green to include a concept of wherein the CSM-based risk score is generated using a CSM, wherein the CSM includes at least the first security issue and a second security issue, wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score; wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different as taught by Shubhabrata for the purpose of combining vulnerability score 212, and a contextual score 216 to form a prioritization score 218 which can be applied to indicate the impact or severity of vulnerability, so that vulnerabilities can be prioritized as to which ones need attention or remediation, [Shubhabrata: (col 6, lines 1-6)].
Regarding claim 12, Green and Shubhabrata teaches the media of claim 11, wherein the CSM is a scored representation of how each of the plurality of security issues are affected by corresponding contextual information (Green, FIG. 2, Each data source 205 is processed by the Active Engine 207 (i.e., a CSM model) to normalize the data then gets analyzed to establish security risk status (i.e., a plurality of security issues). The risk level of each server in the cluster/hierarchy of servers 210 is evaluated independently. Once a base level of risk is determined for servers 215, this base level are modified based on a variety of factors, [0044] Fig 6, table 1205 (i.e., the CSM matrix) containing data feed vulnerabilities (i.e., the plurality of security issues) vs frequency in days and risk thresholds (i.e., the contextual information and scores) [0048] in Fig 20, in table 2005, (i.e., the CSM matrix) tabulate normalized score from multiple data sources into composite risk, [0061] Fig 21 a base score is determined at step 2405 that using aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score is determined at step 2410 by averaging system security metrics to determine an overall mitigated risk level and/or mitigated risk level score. Confidentiality, integrity, and/or availability scores/multipliers is used to determine the mitigated risk level. At step 2415, the risk level can be escalated by one or more authorized users by setting one or more threshold frequencies, At step 2420, an impact assessment is determined, which determines remediation priority. At step 2425, an overall system risk (i.e., the security exposure) is determined based on the determined base level risk (i.e., security issue base-scores of security issues) , mitigated risk level, escalation, and/or impact assessment (i.e., contextual scores of instances of contextual information). For example, one or more of these values are averaged to determine the system level risk, [0062]) [Examiner interprets that active engine (i.e., a CSM model) analyzing data sources that provides security issues and contextual data (i.e., server specific details) to establish risk status and system further adjusting and refining the risk level by aggregating scores based on contextual data from data sources (i.e. multiple servers) and configuring those scores in the tabular format (i.e., CSM matrix) form as wherein the CSM is a scored representation of how each of the plurality of security issues is affected by corresponding contextual information].
Regarding claim 13, Green and Shubhabrata teaches the media of claim 11, wherein the CSM further comprises one or more recommended remediation actions that are mapped to the security issue, wherein a recommended remediation action is an actionable item that is performed to mitigate the security issue in the computing environment (Green, Fig 3, mitigation steps (i.e., a remediation action) is taken based on risks and impacts that have been identified. Mitigation is applied at the server level since it is a result of the environment where the server resides and the protection system installed on the server. The mitigation environment reflect varying levels of network, server, and data protection. For example, a high-risk environment 905 is protected by a few risk mitigating components such as white lists or a demilitarized zone/perimeter network. A server obtain a medium mitigated risk by being associated with a medium-risk environment 910, which can add additional mitigating components such as putting the server behind a first firewall, exposing it to antivirus protection, etc. These support and protection structures are layered to protect the server and/or system and mitigate the base risk. For example, all protections of the high-risk environment 905 automatically be present in the medium and low-risk environments 910 and 915. Mitigation data is inputted by an authorized user(s),[0045] the remediation priority algorithm is configurable by a user or organization. For example, a system with a medium-risk level but high security impact can be automatically assigned a higher remediation priority than a system with a high security risk level but a low security impact. Thus, remediation priorities 705 are set to automatically, and categorically, prioritize higher security impact systems, or set to prioritize higher risk level systems, depending upon user and/or organizational requirements, [0054] a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510, [0058]) [Examiner interprets that system or user assigning different remediation priorities to mitigate different vulnerabilities based on their risk levels (i.e. security issues) as the CSM further comprises one or more recommended remediation actions that are mapped to the security issue, wherein a recommended remediation action is an actionable item that is performed to mitigate the security issue in the computing environment].
Regarding claim 14, Green and Shubhabrata teaches the media of claim 11, wherein the security posture visualization comprises the plurality of security issues, wherein the plurality security issues are associated with corresponding CSM-based risk scores and the contextual information (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. For example, a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510. [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060]) [Examiner interprets that displaying risk posture or other information such as relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores and color-coding based on associated risk levels (i.e., alerts) as the security posture visualization comprise s a plurality of security issues, wherein the plurality security issues are associated with corresponding CSM-based risk scores and contextual information].
Green does not explicitly teach:
CSM based risk score
However, Shubhabrata teaches:
CSM based risk score (Shubhabrata, A vulnerability score 212, a threat score 214, and a contextual score 216 are combined to form a prioritization score 218. The prioritization score 218 can be applied to indicate the impact or severity of vulnerability, so that vulnerabilities can be prioritized as to which ones need attention or remediation, (see col 6, lines 1-6), A relatively high prioritization score 218 suggests the vulnerability in the asset 224 should be addressed by remediation. Vulnerability data 210 and/or threat information 208 can be consulted to guide the remediation effort, (see, col 9, lines 10-14)) [In light of specification, CSM based score quantifies security exposure (exploitability and impact), see instant application [0006], [0032], the prioritization score indicating the impact or severity as CSM based score] Same motivation applies as claim 11
Regarding claim 15, Green and Shubhabrata teaches the media of claim 11, the operations further comprising: receiving an indication to execute a recommended remediation action associated with the security issue, wherein the recommended remediation action is associated with the security posture visualization; and communicating the indication to execute the remediation action to cause execution of the recommended remediation action (Green, Fig 3, mitigation steps (i.e., a remediation action) is taken based on risks and impacts that have been identified. Mitigation is applied at the server level since it is a result of the environment where the server resides and the protection system installed on the server. The mitigation environment reflect varying levels of network, server, and data protection. For example, a high-risk environment 905 is protected by a few risk mitigating components such as white lists or a demilitarized zone/perimeter network. A server obtain a medium mitigated risk by being associated with a medium-risk environment 910, which can add additional mitigating components such as putting the server behind a first firewall, exposing it to antivirus protection, etc. These support and protection structures are layered to protect the server and/or system and mitigate the base risk. For example, all protections of the high-risk environment 905 automatically be present in the medium and low-risk environments 910 and 915. Mitigation data is inputted by an authorized user(s),[0045] the remediation priority algorithm is configurable by a user or organization. For example, a system with a medium-risk level but high security impact can be automatically assigned a higher remediation priority than a system with a high security risk level but a low security impact. Thus, remediation priorities 705 are set to automatically, and categorically, prioritize higher security impact systems, or set to prioritize higher risk level systems, depending upon user and/or organizational requirements, [0054] a user selects a particular PEO level 1510, which cause the system to display risk or other information associated with PEO 1510, [0058]) [Examiner interprets that user clicking the button to execute different remediation priorities and mitigate different vulnerabilities by applying different changes on the displayed visualization posture as receiving an indication to execute a remediation action associated with the security issue, wherein the recommended remediation action is associated with the security posture visualization; and communicating the indication to execute the remediation action to cause execution of the recommended remediation action].
Regarding claim 16, Green and Shubhabrata teaches a computer-implemented method, the method comprising:
accessing a first security issue associated with a computing device in a computing environment (Green, receiving, on an electronic network, security data corresponding to a security vulnerability of each of a plurality of servers, each of the plurality of servers being associated with a secured system, [0004] Fig 22, At step 2905, on an electronic network, security data are received corresponding to at least one security vulnerability associated with each of a plurality of servers, each of the plurality of servers being associated with a secured system, [0063]);
generating a security posture visualization associated with the computing environment, wherein the security posture visualization comprises the security issue associated with a contextual security matrix (CSM)-based risk score that is generated using a CSM (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. The system displays risk or other information associated with PEO 1510, [0058], the low-risk designation for PEO 1 at 1510 is based upon the average score of the servers under PEO 1. Higher level risk designations are averages of lower servers, or alternatively the median risk level of lower servers, the highest server risk level of any of the lower servers, the mode of the server risk level (most frequently occurring), etc., [0059] The display 1500 with a series of concentric rings, where each concentric ring level represents a hierarchical level of the organization, with the highest selected level being displayed in the center or innermost ring. It automatically gets updated based upon determined risk levels. For example, the color, pattern, size, and/or visual indicator assigned to the displayed servers, systems, higher level organizational elements, etc., are based on the associated risk level. Such as color-coding low risk - color green, high risk - color red, apportioned different sizes such as higher risk elements – larger hierarchical ring, lower risk elements – smaller hierarchical ring, [0060]) [Examiner interprets that displaying relevant risk levels related to different security vulnerability of different servers calculated based on vulnerability scores as generating a security posture visualization associated with the computing environment, wherein the security posture visualization comprises the security issue associated with a contextual security matrix (CSM)-based risk score that is generated using a CSM];
wherein the CSM is generated using a CSM model that is a computational framework that algorithmically assigns base-scores to security issues wherein the CSM includes at least the first security issue and a second security issue, (Green, FIG. 21 is a listing of formulas that may be used to determine risk levels and/or scores discussed herein. As discussed above, a base score may be determined at step 2405 that may be an aggregated normalized score, such as a summation of a plurality of normalized scores. A mitigated risk level score may also be determined at step 2410. For example, system security metrics may be averaged to determine an overall mitigated risk level and/or mitigated risk level score, [0062] a server security vulnerability score may be determined, for each of the plurality of servers, based on the security data corresponding to the at least one security vulnerability for each of the plurality of servers, [0063]) [Examiner interprets that system assigning a base score/risk score based on vulnerability/ security data and normalized rating (i.e., algorithmic scoring framework)];
communicating the security posture visualization to cause display of the security posture visualization, wherein the security posture visualization includes the CSM-based risk for the first security issue (Green, FIGS. 15-19 are example diagrams of aggregated server and/or system data at various organizational levels that are displayed to one or more users, for example on a heads-up dashboard (HUD) display 1500. A user can select a particular PEO level 1510, which causes the system to display risk or other information associated with PEO 1510, [0058]) [Examiner interprets that the user selecting to display risk posture or other information as communicating the security posture visualization to cause display of the security posture visualization].
Although, Green teaches structured scoring such as normalized inputs, multipliers/mitigators, formulas/steps to compute risk scores based on factors like mitigation environment, elapsed time, escalation thresholds and impacts is functionally similar to mapping (issue and context) to modified score, Plurality of security issues (i.e., many vulnerabilities across many servers and multiple factors are used to compute scores), base score, and multiple modifiers/factors contributing to a final risk score, and the logical representation of relationships between security issues, contextual information, and associated risk scores, Green does not explicitly teach an explicit matrix data structure:
wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score, wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different; and
However, Shubhabrata teaches:
wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score (Shubhabrata, a mission critical Internet Banking web server may have multiple known vulnerabilities, but which of those present genuine risk to the organization may be unknown, (Col 3, lines 30-33) VA products known as scanners scan virtual machines and report vulnerabilities with additional information such as Severity, Base CVSS Score 222, Temporal CVSS Score 222, and CVE ID 220. The vulnerability data 210 provided by such a scanner applies to a particular asset 224 being scanned.1 The CVSS score 222, which can include a base score and a temporal score, may be resolved or analyzed into metrics and vectors, and the vulnerability score 212 can be based on the CVSS score 222, (Col 4, lines 59-67) Vulnerability Score 212 represents CVSS Score 222 (Base or Temporal as reported by VA products), e.g., as associated or correlated with a particular vulnerability or exposure which may be accompanied by a CVE ID 220. This score is expressed on a scale of 1-10, or 0-10, (Col 6, lines 12-16) The vulnerability module 306 of FIG. 3 tracks specific vulnerabilities for each asset 224, for example by establishing a data structure in memory and populating the data structure with information about each vulnerability relative to each asset 224. When vulnerability data 210 is received by the computing device 302, the vulnerability module 306 tracks the association of CVE ID 220, CVSS score 222, severity and exploitability information (when available) for each such vulnerability or exposure, for each asset 224, so that these are correlated, For example, various associated entries could have links in a database, be on the same row or column in a table, or be listed sequentially in a file, etc. The vulnerability module 306 produces a vulnerability score 212, for each vulnerability for each asset 224, which could be the base CVSS score 222 or the temporal CVSS score 222 or a combination thereof, (Col 7, lines 14-29)) [Examiner interprets that system associating an individualized Base CVSS score with each vulnerability as limitation above];
wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different (Shubhabrata, For each asset 224, and for each vulnerability considered by the vulnerability module 306, the contextual module 310 generates a contextual score 216. To generate the contextual score 216, the contextual module 310 correlates aspects of the specified vulnerability, e.g., from vulnerability data 210, and aspects of the asset 224, e.g., from metadata in tags 202, for a specified asset 224 and a vulnerability specified by a CVE ID 220, the contextual module 310 determines whether the vulnerability matches the asset 224. Consider a vulnerability to data access, as an aspect of a vulnerability specified by a CVE ID 220, and an asset 224 that handles sensitive data. This would be a strong match or correlation and would generate a higher contextual score 216. A vulnerability to data access, and an asset 224 that does not have sensitive data, would generate a lower contextual score 216. A vulnerability to crashing a system, and an asset that has a critical server, would generate a higher contextual score 216 than would be the case for an asset that does not have a critical server. A vulnerability that relies on access via the Web, and an asset that has Web-connectivity, would generate a higher contextual score 216 than would be the case for an asset that does not have Web-connectivity. Certain types of dynamic tag information 206, such as virus found or intrusion detected, could produce a high contextual score 216 in and of themselves, and would produce an even higher contextual score 216 when correlated with certain types of vulnerabilities, such as vulnerabilities that rely on insertion of a virus or repeated intrusions. In some embodiments, threat information 208 is correlated with information from tags 202, in production of the contextual score 216. Further correlations of this nature are readily understood, (Col 8, lines 28-59)] Examiner interprets that system generating a contextual score separately for each vulnerability based on correlation between the particular vulnerability and the contextual information such that the same contextual information may result in different contextual cores depending upon the vulnerability to which the contextual information is corelated as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Green to include a concept of wherein the first security issue is associated with a first base score and the second security issue is associated with a second base score that is different from the first base score, wherein the CMS includes a first instance of contextual information that is assign a first contextual score when mapped to the first security issue and a second contextual score when mapped to the second security issue, and wherein the first contextual score and the second contextual score are different as taught by Shubhabrata for the purpose of combining vulnerability score 212, and a contextual score 216 to form a prioritization score 218 which can be applied to indicate the impact or severity of vulnerability, so that vulnerabilities can be prioritized as to which ones need attention or remediation, [Shubhabrata: (col 6, lines 1-6)].
Regarding claims 17-20, Claim 17-20 recite commensurate subject matter as claim 4, 8, 6, and 10 respectively. Therefore, they are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12141291 B1: “relates to the field of software development methods and tools and, more particularly, to methods and systems for providing a secured systems development lifecycle (SDLC) for cloud applications”
US 20240323216 A1: “relates to system for providing security posture management using a credential-based security posture engine in a security management system”
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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.N.P./
Examiner, Art Unit 2436
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436
Prosecution Insights