Method, system and computer readable medium for determining trust

Abstract

The invention relates to a method, a system and a computer readable medium for determining trust. This disclosure describes techniques including evaluating trust in a system based on subjective factors. In one embodiment, the disclosure describes a method comprising: determining, by a computing system, a precondition score for a network entity in a computer network; determining, by the computing system, a subjective score for the network entity based on one or more subjective factors of the network entity, where each of the one or more subjective factors of the network entity corresponds to a subjective characteristic of the network entity; determining, by the computing system, a trust score for the network entity based on the precondition score and the subjective score; and modifying, by the computing system, operation of the computer network based on the trust score of the network entity.

Description

[0001] This application claims the benefit of U.S. Application No. 18 / 335,575, filed on July 17, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present disclosure relates to computer networks and to levels of trust attributed to entities in the network. Background Art

[0003] Devices or network entities in a network are often relied upon to perform various operations on behalf of users of the network. Some network entities are more trustworthy than others. Some network entities are more secure than others. Zero trust networking is an approach to network security in which network administrators assume that network entities should not be trusted by default, even if those network entities are in a private network or have been previously verified. Embodiment types of network entities may include network nodes (e.g., endpoint devices, intermediate network devices, etc.), network services, or other types of real or virtual entities that can be identified on a computer network. Because network entities are untrusted by default in zero trust networking, identity and integrity checks are routinely performed on network entities. Summary of the invention

[0004] The present disclosure describes techniques that include using subjective information to evaluate trust in devices (i.e., network entities) in a system. Generally, in at least some cases, subjective information can help provide a more comprehensive assessment of the trustworthiness of a network or network entity and can help ensure that decisions are consistent with organizational priorities.

[0005] As described herein, aspects of a trust assessment may be customized for different stakeholders (e.g., users, operators, organizations). Since different stakeholders may have different priorities and values, it may be appropriate to customize the trust assessment to reflect these differences and provide different stakeholders with corresponding different views of the trust assessment of a network entity. For example, one stakeholder may prioritize the reputation of the network entity's manufacturer, while another stakeholder may prioritize the level of innovation and investment in research and development by the network entity's manufacturer.

[0006] In order to customize trust assessments for different stakeholders, trust factors may be assigned weights that reflect the importance of a given factor to the relevant stakeholder. For example, for stakeholders who value sustainability, higher weights may be applied to factors related to sustainability. In some embodiments, such weights may be derived from information received from stakeholders and used to determine the needs and priorities of stakeholders sharing a common role. Thus, different trust scores may be presented to stakeholders, depending on individual stakeholder preferences, the identity of the stakeholder, and / or the role of the stakeholder.

[0007] In some embodiments, the present disclosure describes operations performed by a computing system according to one or more aspects of the present disclosure. In a specific embodiment, the present disclosure describes a method, the method comprising determining, by a computing system, a prerequisite score of a network entity in a computer network, wherein the prerequisite score is based on one or more prerequisite factors, and wherein each of the one or more prerequisite factors is a condition to be satisfied; determining, by the computing system, a subjective score of the network entity based on one or more subjective factors of the network entity, wherein each of the one or more subjective factors of the network entity corresponds to a subjective characteristic of the network entity; determining, by the computing system, a trust score of the network entity based on the prerequisite score and the subjective score; and modifying, by the computing system, an operation of the computer network based on the trust score of the network entity.

[0008] In another embodiment, the present disclosure describes a system comprising a processing circuit and a storage device, wherein the processing circuit is capable of accessing the storage device and is configured to: determine a prerequisite score for a network entity in a computer network, wherein the prerequisite score is based on one or more prerequisite factors, and wherein each of the one or more prerequisite factors is a condition to be satisfied; determine a subjective score for the network entity based on one or more subjective factors of the network entity, wherein each of the one or more subjective factors of the network entity corresponds to a subjective characteristic of the network entity; determine a trust score for the network entity based on the prerequisite score and the subjective score; and modify an operation of the computer network based on the trust score of the network entity.

[0009] In another embodiment, the present disclosure describes a computer-readable medium including instructions that, when executed, configure processing circuitry of a computing system to: determine a prerequisite score for a network entity in a computer network, wherein the prerequisite score is based on one or more prerequisite factors, and wherein each of the one or more prerequisite factors is a condition to be satisfied; determine a subjective score for the network entity based on one or more subjective factors for the network entity, wherein each of the one or more subjective factors for the network entity corresponds to a subjective characteristic of the network entity; determine a trust score for the network entity based on the prerequisite score and the subjective score; and modify an operation of the computer network based on the trust score for the network entity. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1A is a conceptual diagram illustrating an exemplary computer network for which a trust score is calculated according to one or more aspects of the present disclosure.

[0011] Figure 1B , Figure 1C and Figure 1Dis a conceptual diagram illustrating various types of entity specializations according to one or more aspects of the present disclosure.

[0012] Figure 2 is a block diagram illustrating example components of a trust controller according to one or more aspects of the present disclosure.

[0013] Figure 3 is a conceptual diagram illustrating application of one or more trust scoring schemes to calculate a trust score result for a particular network entity according to one or more aspects of the present disclosure.

[0014] Figure 4 is an example trust scoring scheme according to one or more aspects of the present disclosure.

[0015] Figure 5 are example trust score results according to one or more aspects of the present disclosure.

[0016] Figure 6 is a flow chart illustrating operations performed by an example trust controller in accordance with one or more aspects of the present disclosure. DETAILED DESCRIPTION

[0017] Incorporating subjective factors into trustworthiness assessments, rather than relying solely on objective factors, can improve the value of trustworthiness assessments. As described herein, trust assessments, which are typically expressed or summarized by numerical trust scores, can be a function of both objective and subjective factors. Using both objective and subjective factors in trust assessments tends to produce more complete and multifaceted results. Trustworthiness assessments that consider both objective and subjective factors can more accurately reflect the views of different stakeholders.

[0018] Different stakeholders (e.g., network users, administrators, or organizations) may place different levels of importance on factors that contribute to credibility, so credibility assessments may change based on the stakeholders for whom the credibility assessment is made. A credibility assessment that takes into account the stakeholders for whom the assessment is made is more likely to better reflect the values ​​and priorities of that stakeholder.

[0019] Assessing both objective and subjective factors may also improve the relevance and usefulness of trustworthiness. For example, where a trust calculation is being used to inform decisions or guide actions, the trust calculation will be more valuable or effective if it accurately reflects the values ​​and priorities of the person or organization using the trust assessment. Subjective factors can help improve the relevance and usefulness of the calculation by ensuring that it is consistent with the needs and goals of stakeholders.

[0020] Additionally, if generating the subjective scoring information involves soliciting the opinions and perspectives of stakeholders, then a trust assessment based on the subjective opinions and perspectives of stakeholders may be more likely to be accepted and supported by the people or organizations that are using the trust assessment. This may be particularly important if the trust assessment is being used to inform important decisions or guide actions that will have significant consequences.

[0021] As described herein, the use of subjective information in trust assessments may be considered "subjective" in at least two independent respects. In one aspect, factor values ​​themselves may be subjective. For example, subjective factors as described herein may include attributes such as reliability, flexibility, scalability, maintainability, robustness, availability of technical support, etc. Factor values ​​may be considered "subjective" at least if these and other factors are based on opinions or feedback solicited or otherwise received from humans (e.g., one or more stakeholders, users, administrators, owners, or other reviewers).

[0022] The weights applied to subjective or other factors may also be considered "subjective" individually. For example, as described herein, to calculate a trust score, subjective factors may be weighted differently in the trust score calculation for different stakeholders or consumers of the trust score. How these factors are weighted may be based on the views expressed by each stakeholder regarding which factors are considered important to that stakeholder. In some embodiments, factor weights may be based on responses to surveys or other ways of prompting stakeholders to express their views on how subjective factors should be weighted. In other embodiments, factor weights may be based on the role of the stakeholder and may be determined by an organization or network administrator. Therefore, when calculating a trust score, how each factor is weighted may also be considered "subjective" individually, at least to the extent that the trust score calculation is based on the subjective opinions of stakeholders (or organizations) regarding which subjective factors are considered more important than other factors for a given context.

[0023] Figure 1A 1 is a conceptual diagram illustrating an exemplary computer network 100 according to one or more aspects of the present disclosure. Computer network 100 itself may include multiple computer networks, and such computer networks may include private networks (e.g., internal corporate or government networks), virtual private networks, residential networks, or public networks (e.g., cellular communication networks, Internet backbone networks, etc.).

[0024] exist Figure 1AIn an embodiment of the present invention, the computer network 100 includes a set of network entities 102A to 102G, where "G" can be any number. The present disclosure may collectively refer to the network entities 102A to 102G as "network entities 102". Typically, each network entity 102 can be individually addressed within the computer network 100 and can send and receive data on the computer network 100. One or more network entities 102 can be computing nodes, such as real or virtual endpoint devices (e.g., personal computers, smart phones, tablet computers, server devices, laptop computers, Internet of Things (IoT) devices, wearable devices, etc.) or real or virtual intermediate devices (e.g., routers, switches, firewall devices, virtualized appliances, etc.). In some embodiments, one or more network entities 102 can be network services, such as web servers, certain application programming interfaces (APIs), media streaming services, etc. Other types of network entities may include components, controllers, and routing through the computer network 100.

[0025] In some embodiments, each network entity 102 may have additional metadata, such as a device or port description (e.g., which may be configured on the device by an administrator). Such metadata may also include a profile name, which may include a description of the device marked by the administrator or provided by the customer. Metadata associated with one or more network entities 102 may include a website or site name or description of such entity, which may include a geographic location corresponding to where the entity is housed or located.

[0026] Figure 1A Also shown are input systems 103A to 103N (collectively, “input systems 103”). Each input system 103 may correspond to or include one or more systems or devices typically found on a network. Such systems may include devices that support diagnostic processes implemented within the network (e.g., “trouble ticket registration” systems, customer feedback systems, and alert applications), user devices and systems that support email, messaging, chat, and / or collaboration applications (e.g., Microsoft Teams or Salesforce.com’s Slack platform).

[0027] In some embodiments, one or more such input systems 103 may be considered a "source system" or "source service" that is responsible for reporting factor values ​​used in calculating the trust score of one or more network entities 102. For example, one or more input systems 103 may operate as a source service that reports the severity of known vulnerabilities applicable to network devices or network entities 102. Although each input system 103 is shown as being similar to Figure 1A103, but some input systems 103 may be part of or integrated into a network entity. For example, where input system 103 monitors metrics of a network entity, a source service or input system 103 may be implemented as a module or other logic operating within the network entity. Additionally, in some cases, one or more network entities 102 may monitor and report information about their own operations, and in such embodiments, the network entity may be considered to act as a source service or input system 103.

[0028] Figure 1A Also shown are router 191, firewall 192, access control system 193, asset management system 194, and alarm system 195. Router 191 may represent any network device that operates as a router on network 100. Firewall 192 may perform functions related to monitoring incoming and outgoing network traffic of network 100. Access control system 193 may perform functions related to regulating or limiting access to one or more network entities 102 within network 100 or limiting access to other resources provided by network 100. Asset management system 194 may perform functions related to managing, governing, and / or accounting for resources within network 100 or even outside of network 100. Alarm system 195 may perform functions related to detecting conditions that generate and / or manage alarms that may be triggered by conditions within network 100.

[0029] Similar to the input system 103, each of the router 191, the firewall 192, the access control system 193, the asset management system 194 and the alarm system 195 is Figure 1A 102. However, in other embodiments, one or more of router 191, firewall 192, access control system 193, asset management system 194, and alarm system 195 may be implemented as network entity 102, or implemented using one or more network entities 102. Moreover, for ease of explanation, in Figure 1A 1 , one router 191, firewall 192, access control system 193, asset management system 194, and alarm system 195 are shown. However, the technology described herein can be applied to environments in which any number of routers 191, firewalls 192, access control systems 193, asset management systems 194, and alarm systems 195 are deployed.

[0030] As described above, a computer network (such as computer network 100) can be designed to operate using a zero-trust networking architecture. The concept of trust arises not only in the security context, but also in other contexts, including contexts involving risk management associated with the risks assumed by an organization or enterprise when it relies on a network or devices within a network. However, in the security context, when a computer network operates using a zero-trust networking architecture, many authentication and security checks are performed (e.g., each time a service is requested from a network entity in the computer network). Similar processes and checks can also be performed in other contexts. Performing such checks can be resource intensive and can increase network latency.

[0031] Thus, in order to improve network performance in a computer network that operates using a trust architecture (for security and other purposes), a network administrator may reduce the intensity of checks on specific network entities as needed. While doing so may improve network performance, doing so may undermine the overall security and / or reliability of the network to the extent that there is no systematic method for reducing the intensity of checks on individual network entities. Instead, such reductions in the intensity of checks may be based on the experience and intuition of the network administrator. This may lead to inconsistencies and misconfigurations in the computer network, for example, because knowledge of the reduced intensity of checks may not be communicated between network administrators. Ultimately, this may lead to adverse consequences, such as security breaches and network outages.

[0032] This disclosure describes techniques that can address one or more of these problems. Figure 1A As shown in the embodiment of the present invention, the computer network 100 includes a trust controller 104. The trust controller 104 is a computing system including one or more computing devices (such as one or more server devices, personal computing devices, or other types of computing devices). In some embodiments, the computer network 100 may be a wide area network (WAN), and the trust controller 104 may be part of a WAN controller that manages the WAN. In some embodiments described herein, the trust controller 104 determines the trust level of the network entity 102 in the computer network 100. In some embodiments, the trust level may be expressed as a number or trust "score". In other embodiments, the trust level may be expressed as a class category of trust values ​​indicating a fine-grained continuum of trust values ​​(e.g., "highly trusted", "trusted", "untrusted", "unverified trust"), or a category of trust values ​​for specific operations ("trusted for data transmission", "trusted for testing"). In still other embodiments, the trust level may be expressed as a binary value (e.g., "trusted" or "untrusted").

[0033] Although some embodiments of the present disclosure are described in the context of calculating a "trust score", such embodiments may alternatively be implemented using a "trust level". Similarly, embodiments described in terms of a "trust level" may also be implemented using a trust score. Thus, in this sense, the terms "trust score" and "trust level" may be used interchangeably herein, depending on the context. Typically, a trust score may be expressed as a percentage, where 100% represents complete trust and 0% represents no trust.

[0034] In addition, the trust controller 104 can use the trust score of the network entity 102 to perform various actions with respect to the computer network 100. In some embodiments, one or more computing systems other than the trust controller 104 can determine the trust score and / or use the trust score of the network entity 102 to perform actions with respect to the computer network 100. However, for ease of explanation, at least some embodiments herein describe the trust controller 104 as calculating the trust score and performing actions. In such embodiments, because the trust controller 104 determines the trust score in a predictable, reproducible manner, the trust score can be consistently applied across the network entities of the computer network 100. As a result, inconsistencies associated with ad hoc adjustments to authentication, security, and / or other checks can be reduced, and documentation may not be required to convey knowledge of security procedures among network administrators.

[0035] Trust controller 104 may be implemented as a single trust controller or as (or within) a system (e.g., a hierarchy) of two or more trust controllers. In embodiments where trust controller 104 is implemented as a system of trust controllers, trust controllers of trust controller 104 may correspond to a particular kind of network entity, different network entities in a subnetwork of computer network 100, or other groupings of network entities.

[0036] The trust controller 104 may determine a trust score for the network entity 102. The trust score for the network entity indicates a level of trust in the network entity. Generally, if the network entity has previously performed in a manner that a network administrator expected, there is greater trust in the network entity. Conversely, if the network entity has not yet performed in a manner that a network administrator expected, there is less trust in the network entity. For example, if the network entity is known to be compromised by malware, if the network entity is known to generate corrupted data, if the network entity is known to have frequent service interruptions, if the network entity is known to have unpatched security flaws, etc., the trust score for the network entity may indicate low trust.

[0037] To determine the trust score for each of the network entities 102 , the trust controller 104 may use one or more trust scoring schemes 400 . Figure 1AEach of the network entities 102 in FIG. 4 is shown with an attached trust scoring scheme 400. For example, trust scoring scheme 400A is shown adjacent to network entity 102, which is intended to indicate that trust scoring scheme 400A is a trust scoring scheme that can be used to calculate a trust score for network entity 102A. Similarly, trust scoring scheme 400B is shown adjacent to network entity 102B, while trust scoring scheme 400C is shown adjacent to network entity 102C. Some trust scoring schemes 400 may be applied or used by multiple network entities 102. For example, as shown in FIG. Figure 1A As shown, the trust score scheme 400D is associated with and usable by the network entities 102D, 102E, and 102F. Such sharing of the trust score scheme 400D may be appropriate if each of the network entities 102C, 102D, and 102E have common characteristics (e.g., are the same device, are manufactured by the same manufacturer, perform similar functions, and / or are otherwise similar).

[0038] Additionally, some entities may have multiple trust scoring schemes 400. Figure 1A In the embodiment of FIG. 1 , multiple trust score plans 400G are shown adjacent to the network entity 102G. Multiple plans for a given entity are often appropriate, particularly if there are reasons for calculating trust scores for different purposes or in different contexts (e.g., for a normal operating environment, for an environment where alarms are active in the network, or for a demonstration or training exercise).

[0039] An entity may have a default trust scoring scheme, which may be based on common or typical usage patterns for a given entity. For example, for entity 102 representing a physical network device, the manufacturer of the network device may ship the device with a default trust scoring scheme that is intended to accommodate typical usage of the network device. Such a default trust scoring scheme may be based on a publicly available standard document that specifies rules about how the device should be configured to meet the needs of typical or even specific usage of the network device. In some embodiments, similar network devices manufactured by different vendors may be associated with different default trust scoring schemes.

[0040] In some cases, there may be multiple standardized or default trust scoring schemes for a network device, depending on how the network device will be used. For example, one default scheme may be based on a set of standards that are typically applied in secure networking environments (e.g., based on standards published by the Center for Internet Security or "CIS"). Another default scheme may be based on a different set of standards that may be applied to government deployments of devices (e.g., Defense Information Systems Agency or "DISA" requirements). A third default scheme may be based on a different set of standards applicable to device use in the medical industry (e.g., Health Insurance Portability and Accountability Act or "HIPAA" requirements). In some cases, a trust scoring scheme 400 generated based on one or more such standards may be manually created by the manufacturer of the network device and included in the network device or otherwise available to the user. However, such a trust scoring scheme 400 may be automatically generated based on parsing requirements, rules, and / or specifications published by a standards organization.

[0041] In general, each of the trust score schemes 400 may define a different way of calculating a trust score for a given entity. Since trust may be used in a variety of decision-making processes involving an entity (e.g., network entity 102 of network 100), it may be advantageous to calculate a trust score in a flexible manner because the trust score may differ based on the context. For example, in Figure 1A A particular network entity 102 operating in a network 100 of FIG. 1 may have a high trust score (and be assigned a high degree of trust) based on its hardware and software characteristics. However, if the same network entity 102 is deployed in a different network, where the different network may be used for different purposes in different environments, then those same hardware and software characteristics of the network entity 102 may not be sufficient to grant any significant trust. Thus, the concept of trust scores should be flexible, as not all networks are the same, not all uses and purposes of trust scores are the same, and not all contexts are the same.

[0042] As described herein, a trust scoring plan can define how to calculate a trust score for a given entity. A trust scoring plan can define and / or describe a list of trust factors in each of a plurality of trust factor categories. A trust scoring plan can also define how each of those factors contributes to an overall trust score. Different trust scoring plans can be used to customize how to calculate trust scores for different environments, contexts, purposes, customers, deployments, network segments (e.g., core network, edge network, metropolitan deployment), and / or service types (IPv4, IPv6, streaming, IP voice). In some embodiments, a trust scoring plan can be used to help meet quality of service standards for a particular environment, customer, or deployment. Further, a trust scoring plan can be used for different customer categories, such that customers operating in a government context can use a trust scoring plan that complies with DISA standards, customers in the healthcare industry can use a trust scoring plan that complies with HIPAA standards, and customers in other industries can use a trust scoring plan that complies with applicable standards in such other industries.

[0043] As described herein, the trust score may be calculated by the trust controller 104, and the trust score scheme 400 may be stored in a location that allows for convenient access by the trust controller 104. Figure 1A 4. In the example of FIG. 4, a diagram of various network entities 102 is shown, but such a trust scoring scheme need not be stored at each such network entity 102. Instead, such a trust scoring scheme 400 may be stored in a data store within the trust controller 104. Figure 1A , a trust scoring scheme 400 shown in proximity to a given network entity 102 is shown with a dashed line, which is intended to indicate that such a trust scoring scheme 400 is only associated with a given network entity 102 , but is not necessarily stored at such a network entity 102 .

[0044] According to one or more aspects of the present disclosure, the trust controller 104 may collect information about one or more network entities 102. For example, in Figure 1A In the depicted example, each of input systems 103 collects information, which may include information related to the operation of each network entity 102 and may include metrics, information about the configuration of each network entity 102, information about operations performed by each of network entities 102, and information about various subjective characteristics or ratings associated with network entity 102.

[0045] Information about operations performed may include, for example, the volume of traffic handled, errors logged, restarts required, and other information. Information about subjective characteristics may include information about reliability, uptime ratings, whether problems tend to be resolved quickly and efficiently, scalability, flexibility, interoperability with other systems, ease of maintainability, robustness, availability of technical support and / or customer support, privacy and security ratings, and cost-effectiveness. Such characteristics may be generated by soliciting opinions or rating information from users, network operators, or other stakeholders, so in this sense, the information may be relatively qualitative and / or subjective, rather than qualitative or objective. In any case, such characteristics may be expressed in the form of a score (e.g., from 0 to 100), thereby enabling the use of subjective characteristic descriptions in quantitative algorithms to generate trust assessments or trust scores.

[0046] Such input system 103 sends a signal including the collected information to trust controller 104. Trust controller 104 stores the collected information for later use. Alternatively, or in addition, one or more of network entities 102 individually report information about their operations to trust controller 104. Such information may also include metrics, information about configuration, and / or information about operations performed. Trust controller 104 stores any information received from network entity 102.

[0047] Trust controller 104 may prepare to calculate a trust score. Figure 1A In the embodiments described in the context of FIG. 1 , the trust controller 104 detects a signal (i.e., a “trigger”) that it determines corresponds to a command or request to calculate a trust score for one or more network entities 102. In response to the signal, the trust controller 104 identifies the network entity 102 for which the trust score is to be calculated. In one particular embodiment, the trust controller 104 determines that the signal includes a request to calculate a trust score for the network entity 102B. The trust controller 104 identifies the trust score scheme 400B as an appropriate scheme for calculating the trust score for the network entity 102B. In some embodiments, the trust score scheme 400B may be a default trust score scheme for the network entity 102B. In other embodiments, the trust score scheme 400B may be a trust score scheme that has been customized by an administrator to meet the specific usage context of the network entity 102B within the network 100. The trust controller 104 accesses the trust score scheme 400B in order to calculate the trust score for the network entity 102B.

[0048] In some embodiments, a trigger corresponding to a command or request to calculate a trust score may identify a stakeholder (e.g., a network user or operator or organization) requesting the trust score. In such an embodiment, the trust controller 104 may identify the stakeholder based on the credentials (e.g., a username and password) used by the stakeholder when accessing the network. When calculating the trust score for the stakeholder, the trust controller 104 may use the identity of the stakeholder to select weights to apply to each of the multiple subjective factors. These weights may apply the stakeholder specifically, or more broadly, to the role of the stakeholder.

[0049] The trust controller 104 may perform calculations to generate a trust score result 500B for the network entity 102B. Figure 1A , the trust controller 104 interprets the trust scoring scheme 400B and applies the trust scoring scheme 400B to information stored at the trust controller 104. Such stored information may include information previously obtained by the trust controller 104 from the input system 103 and / or the network entity 102. In most cases, the stored information used when applying the trust scoring scheme 400B to generate the trust scoring result 500B will primarily relate to the network entity 102B, because the trust controller 104 is seeking to calculate the trust score of the network entity 102B. However, information about other network entities 102 may be used. Based on the stored information and the specifications outlined in the trust scoring scheme 400B, the trust controller 104 generates the trust scoring result 500B. In some embodiments, the trust scoring result 500B may include a plurality of supporting documents and / or reports underlying the trust score calculation. Included in the trust scoring result 500B may be a particular composite trust score value or percentage value representing the trust score of the network entity 102B.

[0050] Trust controller 104 may adjust the operation of network 100 based on the trust score value of network entity 102B. Figure 1A, the trust controller 104 may determine that the trust score result 500B (or the composite trust score value included within the trust score result 500B) suggests that the network entity 102B cannot be trusted in the context defined or represented by the trust score scheme 400B. In such an embodiment, the trust controller 104A may take action to restrict the use of the network entity 102B within the network 100 in view of its lack of trustworthiness. In another embodiment, the trust score result 500B may suggest that the network entity 102B may be trusted, and in such an embodiment, the trust controller 104 may enable the network entity 102B to play a larger role or process additional data within the network 100. In still other embodiments, the trust controller 104 may directly or indirectly reconfigure the tested network entity or other network entities based on the trust score result to modify the behavior with respect to the network entity (e.g., route traffic to avoid a given network entity). In further embodiments, the trust controller 104 may output instructions to a network controller or other system to reconfigure aspects of the network.

[0051] The trust scoring scheme may describe how to calculate the trust score based on contribution classes and factors within those contribution classes. Contribution classes are categories of information that contribute to the trust score of the network entity 102. In some embodiments, the contribution classes include one or more of a set of preconditions for the network entity 102, a set of variable factors for the network entity 102, a set of reputation factors for the network entity, and / or a set of subjective factors for the network entity 102.

[0052] In some embodiments, the trust score calculation can be a function of the independent sub-scores of each of the contribution classes. For example, there can be a first sub-score for the preconditions of the network entity, a second sub-score for the variable factors of the network entity, a third sub-score for the reputation factors of the network entity, and a fourth sub-score for the subjective factors of the network entity. In some embodiments, the sub-scores of the contribution classes are expressed as a percentage of the highest possible sub-score of the contribution class. In other embodiments, the sub-scores of the contribution classes are expressed in other ways. The trust controller 104 can use the sub-scores of the contribution classes of the network entity 102 (e.g., the first sub-score, the second sub-score, the third sub-score, and the fourth sub-score) to determine the trust score of the network entity. Therefore, the trust score of the network entity can be the result of a mathematical calculation based on one or more of the preconditions of the network entity, the variable factors of the network entity, and / or the reputation factors of the network entity.

[0053] In general, each of the preconditions of the network entity 102 is a condition that must be satisfied in order for the trust score of the network entity to have a value greater than a minimum value (e.g., 0). In the present disclosure, a trust score of a network entity having a minimum value generally means that a lowest level of trust (e.g., no trust) is assigned to the network entity. In some embodiments, the minimum value may be equal to 0. However, a value other than 0 may be used to represent a trust score indicating no trust.

[0054] The variable factors of the network entity 102 correspond to current characteristics of the network entity. Exemplary characteristics of the network entity may include a current configuration of the network entity, a version of the network entity, activity characteristics of the network entity, a sentiment value or polarity associated with the network entity, etc. The variable factors may be weighted so that some of the variable factors contribute more to the variable factor sub-score than other of the variable factors.

[0055] Each of the reputation factors of the network entity 102 may be a function of specified historical events involving the network entity. For example, the trust controller 104 modifies the value of the reputation factor of the network entity based on the behavior of the network entity over time. For example, the trust controller 104 may modify the value of one reputation factor based on the number of times the network entity has spontaneously rebooted. In another embodiment, the trust controller 104 may modify the value of a reputation factor based on the number of times the network entity has been reconfigured.

[0056] Each of the subjective factors of the network entity 102 may be a function of a specific subjective or qualitative assessment of the network entity. Such subjective assessments may involve any of a plurality of factors, including subjective assessments of reliability, uptime, flexibility, ability to integrate with other systems, ease of maintenance, robustness, availability of technical support, privacy and security, quality of the network or network entity, level of customer support, or total value relative to cost. Information about these subjective factors may be collected from users and / or stakeholders through focus groups, interviews, online forums, customer feedback forms, surveys, rating agencies, ranking organizations, and / or user experience (UX) studies. The trust controller 104 may collect information about such factors that have been collected from the input system 103. The trust controller 104 may use this information to obtain a subjective sub-score, which may involve applying a weight to each of such factors that may be appropriate for a given user. Insofar as such information received (e.g., from the input system 103) originally originates from an administrator, stakeholder, or other human resource, such human resources are preferably encouraged (through policy or otherwise) to provide detailed and specific feedback about their experience with a given network or system.

[0057] The trust scoring scheme enables decoupling of factor values ​​and factor contributions from the way trust scores are calculated. Such decoupling simplifies the process of trying different trust score calculations or applying different rules to calculate trust scores. When the source service or input system 103 provides a factor value, it can be used in different scoring scheme calculations with different contributions and / or weights. Such factor values ​​can even be used in different factor categories. For example, the same factor may be used as a prerequisite factor in one trust scoring scheme, but as a variable factor in another trust scoring scheme. In some embodiments, the trust scoring scheme is initially constructed by a small number of coarse-grained factors and is later expanded to include most of the fine-grained factors. Such factors may be based on standard-based benchmark specifications, such as standards published by CIS or DISA, as described above. Such specifications may include multiple "baseline rules" organized into multiple "baseline rule groups". These rules may outline the appropriate requirements and / or configurations for ensuring that a specific entity follows the goals behind the specification (e.g., cybersecurity, government standards, health industry requirements). In such an embodiment, the coarse-grained factor may be the total score of the benchmark rule group or even the complete benchmark. The fine-grained factor may be a separate benchmark rule.

[0058] As described herein, trust controller 104 may determine a trust score for a network entity based on a number of factors. For example, trust controller 104 may determine a trust score for a network entity based on factors included in one or more contribution classes. In some embodiments, such factors may include operational characteristics, metrics, sentiment information derived from data collected by one or more input systems 103, network topology, information about subjective assessments of network entity 102, and / or other information.

[0059] When sentiment information is used, such sentiment information may be derived from text associated with one or more input systems 103, which may include information derived from diagnostic data associated with one or more network entities 102, such as notes generated by an administrator or comments provided by a user when troubleshooting a problem with a network entity 102 in a trouble ticket registration system implemented within network 100. In other embodiments, sentiment information may be derived from text or other information associated with metadata associated with one or more network entities 102.

[0060] Where subjective information is used, information about each different type of subjective assessment may be collected from one or more input systems 103 and then used to calculate a subjective score or subjective sub-score. One way to use such subjective assessments is to quantify the assessments (e.g., as a quantity from 0 to 100) and then apply weights to each of a selected number of different types of subjective assessments. The weights may be selected based on the user's or stakeholder's own values ​​or priorities as to which types of subjective assessments are important for their purposes. For example, a user may assign values ​​to reliability and flexibility characteristics in a network entity, so those subjective factors may be weighted higher in calculating a trust score than other subjective factors in calculating a trust score. A different user may place more importance on ease of maintenance and / or availability of customer support than other factors, so those subjective factors may be weighted higher for that user.

[0061] When calculating the trust score, as suggested above, the subjective factors may be applied on a per-user basis, such that the subjective sub-score for one user may be different from the subjective sub-score for another user with different values ​​or priorities. In other embodiments, the subjective factors may be applied based on the role of the user, such that the subjective factors of two users with the same role (e.g., a network administrator) may be applied in the same manner, but differently from a user with a different role (e.g., a field technician).

[0062] Using subjective factors in the trustworthiness calculation in this way can improve the relevance and usefulness of the resulting trust score by ensuring that it takes into account the values ​​and priorities of the stakeholders using the calculation. In other words, subjective factors can potentially improve the relevance and usefulness of the trustworthiness calculation for different types of stakeholders, including network operations center (NOC) staff, network planners, field technicians, end users, etc.

[0063] For example, network operations center staff are often responsible for monitoring and managing the performance of the network and ensuring that any issues are resolved quickly. For stakeholders in this role, trustworthiness may be determined primarily by factors such as reliability, uptime, and the ability to resolve issues quickly and efficiently. Trust scores that incorporate subjective factors that reflect the priorities of NOC staff may be more relevant and useful in informing decisions about which entities to deploy and how to prioritize maintenance and upgrades.

[0064] Network planners are responsible for designing and implementing network architecture and policies. Such stakeholders may value factors such as scalability, flexibility, and the ability to integrate with other systems, and therefore, trustworthiness may be appropriately based on such factors. Trust scores that incorporate subjective factors that reflect the priorities of network planners can help inform decisions about which entities to deploy and how to design and implement the network.

[0065] Field technicians are responsible for installing, configuring, and maintaining field network equipment. For these stakeholders, trustworthiness may be determined by factors such as ease of maintenance, robustness, and availability of technical support.

[0066] End users (the stakeholders who use the network and its services) can have different values ​​and priorities. For example, an end user who relies on the network for critical business operations may prioritize uptime and reliability, while an end user who uses the network for personal communications may prioritize privacy and security.

[0067] In calculating the trust score, the trust controller 104 may also consider attributes of the entities that separate one entity from the other. For example, if the network entity 102A trusts the network entity 102C, and the network entity 102C trusts the network entity 102E, the network entity 102A may trust the network entity 102E to some extent because the network entity 102A trusts the entity that also trusts the network entity 102E. In such an embodiment, the trust controller 104 may increase the trust score of the network entity 102E for operations (e.g., data transfer) that the network entity 102A may perform with the network entity 102E. The network entity 102A may not have any direct interactions with the network entity 102E, but the network entity 102A may be able to infer a trust relationship with the network entity 102E based on the trust of the network entity 102A for the intermediate entity (e.g., the network entity 102C).

[0068] On the other hand, if network entity 102A trusts network entity 102C, but network entity 102C does not trust network entity 102E, network entity 102A may not trust network entity 102E because network entity 102C (an entity that network entity 102A trusts) does not trust network entity 102E. In this embodiment, trust controller 104 may lower the trust score of network entity 102E for operations that network entity 102A may perform with network entity 102E. Therefore, network entity 102A may determine a trust inference about network entity 102E based on the trust level of network entity 102A with network entity 102C and the trust level of network entity 102C with network entity 102E.

[0069] Incorporating subjective factors into the calculation of trustworthiness can inform decision making in several ways. Subjective factors can reflect the values, priorities, and goals of an organization and its stakeholders, and by taking these factors into account, the calculation of trustworthiness can be more closely aligned with the needs and priorities of the organization. This can help ensure that trust score calculations are more relevant and useful for guiding decision making because such calculations take stakeholders' perspectives and priorities into account.

[0070] Therefore, incorporating subjective factors has many benefits. For example, the use of subjective factors tends to prioritize the use of network equipment based on its alignment with the operator's values ​​and goals. For example, if an operator values ​​sustainability, it can prioritize (e.g., select) network equipment with low environmental impact.

[0071] Additionally, subjective factors such as customer satisfaction levels or the quality of service provided by a network device can be used to inform the evaluation of its performance. For example, if a network device consistently receives high ratings from customers, this can be considered a positive subjective factor in the evaluation of its performance.

[0072] Additionally, subjective factors such as the reputation of a manufacturer or the level of transparency in its business practices can be used to inform the assessment of the trustworthiness of a network device. For example, if a manufacturer has a history of producing poor or unreliable products, this can be considered a negative subjective factor in the assessment of the trustworthiness of its network devices.

[0073] Additionally, manufacturers or suppliers that respond promptly and provide good support may be considered more trustworthy because it shows that they are committed to maintaining the quality of their products and resolving any issues that may arise. Therefore, the level of support provided by a manufacturer or supplier may affect the trust score calculation.

[0074] Additionally, manufacturers or suppliers who are willing to work closely with operators and provide regular updates on the status of their products may be considered more trustworthy, as such practices demonstrate their commitment to maintaining a strong partnership. Therefore, the level of collaboration and communication with operators may affect the trust score calculation.

[0075] Going a step further, manufacturers or suppliers that actively invest in research and development and bring new, innovative products to market may be considered more trustworthy because such activity demonstrates their commitment to staying ahead of industry trends and evolving with the needs of operators. It may be appropriate for innovation and investment in research and development to influence the trust score calculation.

[0076] Although subjective factors can be used to evaluate the trustworthiness of network devices, objective criteria such as those described herein can be used to evaluate subjective factors.

[0077] More details on trust scoring, particularly in the context of computer networks, can be found in U.S. Patent Application No. 16 / 949,996, filed on November 23, 2020, entitled “Trust Scoring of Network Entities in Networks” (Attorney Docket No. 2014-270US01). Details on inferring trust, particularly in the context of computer networks, can be found in U.S. Patent Application No. 17 / 474,871, filed on September 14, 2021, entitled “Inferring Trust in Computer Networks” (Attorney Docket No. 2014-483US01). Details regarding assessing trust by performing sentiment analysis on entities or devices within a system (e.g., a network) may be found in U.S. Patent Application No. 17 / 644,555, filed on December 15, 2021, entitled “Use of Sentiment Analysis to Assess Trust in a Network” (Attorney Docket No. 2014-516US01). Details regarding the use of a trust score plan may be found in U.S. Patent Application No. 17 / 655,140, ​​filed on March 16, 2022, entitled “Use of a Trust Score Plan” (Attorney Docket No. 2014-542US01). Details regarding trust remediation can be found in U.S. Patent Application No. 18 / 148,762 (Attorney Docket No. 2014-604US01), entitled “Remediation Work Score for Network Trust Applications,” filed on December 30, 2022. All of these applications are incorporated herein by reference in their entirety.

[0078] Figure 1B , Figure 1C and Figure 1D is a conceptual diagram illustrating various types of entity specializations according to one or more aspects of the present disclosure. For example, Figure 1B The illustrated entity may take the form of a functional entity 120, such as one or more routers 121 or one or more switches 122. Figure 1BAs shown, the entity can take the form of a device entity 130 or a network entity 140 and represent an aggregation of devices (e.g., a particular type of device such as a group of reconfigurable optical add / drop multiplexers or “ROADMs”) 131 or networks (e.g., a subnet or subnetworks) 141. Figure 1B The types of entities shown in the Figure 1A The type of entity being described.

[0079] Although Figure 1A The term "entity" is described in terms of an entity (the entity takes the form of a network entity 102 (e.g., a network device, a computing device, a computing service, etc.), but in other embodiments, the term "entity" may cover a broader concept. For example, Figure 1C and Figure 1D Other types of entities or at least different classifications of entities are shown, such as quantitative entities 160 and qualitative entities 170. Quantitative entities 160 may include users 161, services 162, power attributes 163, cooling attributes 164. Qualitative entities 170 may include other types of entities, possibly non-physical entities.

[0080] exist Figure 1D In an embodiment of the present invention, the qualitative entity 170 includes one or more instances of supplier support 171, contractor experience 172, and / or contractor skills 173. The techniques described herein can be applied to both quantitative entities 160 and qualitative entities 170 having trust scores. Such trust scores can be defined based on sentiment analysis and other factors, in part based on a trust scoring scheme selected for the entity. Where sentiment analysis is used, the sentiment may be derived from text or other data associated with the information or other data associated with one or more instances of supplier support 171, data associated with contractor experience 172, and / or data associated with or describing an assessment of contractor skills 173. Given that text describing such entities may be readily available through customer reviews or text-based communications between suppliers, contractors, customers, and others, such qualitative entities 170 may be particularly sensitive to sentiment analysis.

[0081] Furthermore, in some cases, components of a trust score may be spatial in nature. For example, as described herein, a trust score may also be defined in part based on trust levels between adjacent entities in a graph, chart, table, or other data arrangement.

[0082] Figure 2 is a block diagram illustrating example components of the trust controller 104 according to one or more aspects of the present disclosure. Figure 2 One embodiment of a trust controller 104 is shown, and the present disclosure includes any other suitable configuration of the trust controller 104 .

[0083] like Figure 2 As shown in the embodiment of the present invention, the trust controller 104 includes one or more processors 202, one or more communication units 204, one or more input devices 208, one or more output devices 210, zero or more display screens 212, one or more power supplies 214, one or more storage devices 216, and one or more communication channels 218. The trust controller 104 may include other components. For example, the trust controller 104 may include physical buttons, microphones, speakers, communication ports, etc. The communication channel 218 may be interconnected with each of the components 202, 204, 208, 210, 212, and 216 for inter-component communication (physically, communicatively, and / or operationally). In some embodiments, the communication channel 218 may include a system bus, a network connection, an inter-process communication data structure, or any other method for transmitting data. The power supply 214 may provide electrical energy to the components 202, 204, 208, 210, 212, and 216.

[0084] The storage device 216 may store information needed for use during operation of the trust controller 104. In some embodiments, the storage device 216 has the primary purpose of being a short-term computer-readable storage medium rather than a long-term computer-readable storage medium. The storage device 216 may include volatile memory, and therefore may not retain stored contents if power is removed. In some embodiments, the storage device 216 includes non-volatile memory configured for long-term storage of information and for retaining information after power on / off cycles. In some embodiments, the processor 202 of the trust controller 104 may read and execute instructions stored by the storage device 216.

[0085] The trusted controller 104 may include one or more input devices 208 that the trusted controller 104 uses to receive user input. Examples of user input include tactile input, audio input, and video user input. The input device 208 may include a presence sensitive screen, a touch sensitive screen, a mouse, a keyboard, a voice response system, a microphone, a motion sensor capable of detecting gestures, or other types of devices for detecting input from a person or a machine.

[0086] The communication unit 204 may enable the trust controller 104 to send and receive data to and from one or more other computing devices (e.g., via a computer network, such as a local area network or the Internet). For example, the communication unit 204 may be configured to receive data from the network entity 102. In some embodiments, the communication unit 204 may include a wireless transmitter and receiver that enables the trust controller 104 to communicate wirelessly with other computing devices. Embodiments of the communication unit 204 may include a network interface card, an Ethernet card, an optical transceiver, a radio frequency transceiver, or other types of devices capable of sending and receiving information. Other embodiments of such a communication unit may include a Bluetooth® wireless communication device. TM , 3G, 4G, 5G and WI-FI TM radio, universal serial bus (USB) interface, etc. In addition, the trusted controller 104 can communicate with one or more other devices using the communication unit 204 .

[0087] Output device 210 can generate output. Examples of output include tactile output, audio output, and video output. Output device 210 can include a presence-sensitive screen, a sound card, a video graphics adapter card, a speaker, a liquid crystal display (LCD), a light-emitting diode (LED) display, or other types of devices for generating output. Output device 210 can include display screen 212. In some embodiments, output device 210 can include a virtual reality, augmented reality, or mixed reality display device.

[0088] Processor 202 may include processing circuitry configured to perform various actions. Processor 202 may be configured to read instructions from storage device 216 and may execute instructions stored by storage device 216. By executing instructions by processor 202, trust controller 104 may be configured to or cause trust controller to provide at least some of the functions attributed to trust controller 104 or its components (e.g., processor 202) in the present disclosure. Figure 2 As shown in the embodiment of FIG. 2 , the storage device 216 includes computer readable instructions associated with the data collection system 220, the scoring system 222, the action system 224, the trust planning system 227, the tracking system 226, the analysis system 231, and the inference system 221. Figure 2 In the embodiment of FIG. 2 , the storage device 216 may also include source data 228, trust program data storage 237, and rating data 230. Figure 2 In the embodiment shown in FIG. 2 , computer readable instructions associated with the scoring system 222 may include computer readable instructions associated with the prerequisite system 232, the variable factor system 234, the reputation system 236, and the computing system 238. In other embodiments, the storage device 216 may include computer readable instructions associated with other systems or modules.

[0089] The data collection system 220 is configured to collect data about the network entities 102. For example, the data collection system 220 may query the log data of the network entities as part of collecting data about the network entities 102. In some embodiments, the data collection system 220 may be configured to collect configuration and performance data about the network entities. The configuration and performance data may include snapshots of configuration data, snapshots of alarm data, and logs. The data collection system 220 may also collect information about the network topology, enabling determination of which network entities 102 are neighbors (i.e., adjacent to each other in the network topology), and enabling collection and storage of other information about the network (e.g., network paths and routes through the network). The source data 228 may include data collected by the data collection system 220.

[0090] The data collection system 220 may also be configured to collect data that can be used to perform sentiment analysis. For example, the data collection system 220 may be integrated with one or more input systems 103 (e.g., a trouble ticket registration system) to collect data related to diagnostics or troubleshooting performed on one or more network entities 102. In some embodiments, the data collection system 220 may be configured to collect information from emails, messages, chats, and / or collaborative applications or other subjective material sources. The data collection system 220 may also collect information from one or more user devices, wherein such user devices are configured to present a user interface and collect comments about one or more network entities 102 from the user. In one embodiment, such a user interface may present a simplified free-form comment box through the user interface and prompt the user or enable the user to enter any comments they want about the trust of one or more network entities 102. In such an embodiment, the data collection system 220 may collect such input and make the data available for subsequent sentiment analysis as described herein.

[0091] The data collection system 220 may store sentiment information in forms other than simple text and user comments (as source data 228). For example, in some embodiments, sentiment information may include information about a state or change in state. In one such embodiment, a user may provide a comment like "Physical security at this site is poorly maintained." If the comment is subsequently removed (or otherwise invalidated), sentiment information (e.g., "state information") having a sentiment polarity opposite to that of the original comment may be generated and stored within the data collection system 220 as source data 228.

[0092] The remediation system 239 may perform functions related to determining a friction metric and an inertia metric, weighting the friction metric and the inertia metric, and determining a remediation metric from the weighted friction metric and the weighted inertia metric. In some embodiments, the remediation system 239 receives a trust score for the network entity from the trust program system 227. The remediation system 239 may perform one or more of the following: identifying at least one vulnerability of the network entity based on the received trust score; determining a set of remediation measures for addressing the at least one vulnerability; determining, for each remediation action in a set of remediation actions, an expected workload associated with the remediation action; selecting a remediation action from a set of remediation actions based on determining the expected workload associated with the remediation action for each remediation action; and performing operations to perform at least a portion of the selected remediation action.

[0093] Scoring system 222 may use source data 228 to determine a trust score for network entity 102. Scoring data 230 may include a trust score determined by scoring system 222 for network entity 102. Figure 2 In an embodiment of the present invention, the prerequisite system 232 can determine a prerequisite sub-score of the network entity 102. The variable factor system 234 can determine a variable factor sub-score of the network entity 102. The reputation system 236 can determine a reputation sub-score of the network entity 102. The subjective system 233 can determine a subjective sub-score of the network entity 102. The computing system 238 can use one or more of the prerequisite sub-score of the network entity, the variable factor sub-score of the network entity, the reputation sub-score of the network entity, and the subjective sub-score of the network entity to determine a trust score for the network entity.

[0094] The prerequisite system 232 may determine a prerequisite sub-score for the network entity 102. That is, the prerequisite system 232 may determine the trust score of the network entity based on one or more prerequisites. Each of the prerequisites is a condition that must be satisfied in order for the trust score of the network entity to not have a minimum value. The prerequisite system 232 may evaluate the conditions to determine the prerequisite sub-score for the network entity. The prerequisite system 232 may store the prerequisite sub-score for the network entity 102 as score data 230. Exemplary conditions may include whether the network entity is using a certified software version, whether the network entity is using a certified hardware version, etc. Other prerequisites may include a network entity not using a known vulnerable software version, a network entity using only supported software or hardware versions, a network entity having a correct network time setting, a network entity having a correct certificate loaded for transport layer security (TLS), etc. The conditions may be user defined.

[0095] The variable factor system 234 may determine a variable factor sub-score for the network entity 102. In other words, the variable factor system 234 may evaluate a sub-score for each of several characteristics of the network entity. Each of the one or more variable factors of the network entity corresponds to one or more characteristics of the network entity. The variable factor system 234 may store the variable factor sub-scores for the network entity 102 as score data 230. The characteristics may be user defined. Examples of characteristics may include:

[0096] Use only approved applications on network entities,

[0097] Use only signed applications on network entities,

[0098] Whether the network entity's release is a known good version,

[0099] The state or configuration of network entities, for example, whether recommended configurations are applied,

[0100] whether the software release version of the network entity's software application is within a given number of releases of the current version of the software application,

[0101] · Rate limiting of requests to be processed by the router's routing engine.

[0102] · Limits on the rate of possible network management interactions per time period,

[0103] Password strength requirements,

[0104] The number and type of open network ports,

[0105] Whether encryption keys are updated more frequently than a threshold time limit,

[0106] • Sentiment analysis associated with network entities, which may be determined by analysis system 231, as described further below.

[0107] The subjective system 233 may determine a subjective factor sub-score for the network entity 102. In doing so, the subjective system 233 may evaluate a score for each of several subjective characteristics of the network entity. Each of the one or more subjective factors may correspond to a characteristic of the network entity, wherein the evaluation may be somewhat subjective in nature. The subjective system 233 may store the subjective factor sub-scores for the network entity 102 as the score data 230. As with the variable factors, the subjective characteristics may be user defined. Examples of subjective characteristics may include:

[0108] ·reliability

[0109] Uptime rating

[0110] ·Ability to solve problems quickly and effectively

[0111] Scalability

[0112] ·flexibility

[0113] Ability to integrate with other systems

[0114] Easy to maintain

[0115] Robustness

[0116] Availability of technical support

[0117] Privacy and security

[0118] Network quality

[0119] The level of customer support

[0120] Total value relative to the physical cost of the network

[0121] The trust controller 104 may determine the trust score of the network entity based on a number of factors, each of which may be defined in a trust scoring scheme. For example, the trust controller 104 may determine the trust score of the network entity based on factors included in one or more contribution classes. In some embodiments, such factors may include operational characteristics, metrics, sentiment information derived from data collected by one or more input systems 103, or other information.

[0122] The contribution class is a category of information that contributes to the trust score of the network entity. In some embodiments, the contribution class includes one or more of a set of preconditions of the network entity, a set of variable factors of the network entity, a set of reputation factors of the network entity, and a set of subjective factors of the network entity.

[0123] In some embodiments, there may be a separate score or sub-score for each of the contribution classes. For example, there may be a first sub-score for the preconditions of the network entity, a second sub-score for the variable factors of the network entity, a third sub-score for the reputation factors of the network entity, and a fourth sub-score for the subjective factors. In some embodiments, the sub-score of the contribution class is expressed as a percentage of the highest possible sub-score of the contribution class. In other embodiments, the sub-score of the contribution class is expressed in other ways. The trust controller 104 may use the sub-scores of the contribution classes of the network entity (e.g., the first score, the second score, the third score, and the fourth score) to determine the trust score of the network entity. Therefore, the trust score of the network entity can be the result of a mathematical calculation based on one or more of the preconditions of the network entity, the variable factors of the network entity, the reputation factors of the network entity, and / or the subjective factors of the network entity.

[0124] Typically, each of the preconditions of the network entity is a condition that must be satisfied in order for the trust score of the network entity to have a value greater than a minimum value (e.g., 0). In the present disclosure, the trust score of the network entity having the minimum value means that the lowest level of trust (e.g., no trust) is provided to the network entity. In some embodiments, the minimum value may be equal to 0. However, a value other than 0 may be used to represent a trust score indicating no trust.

[0125] The variable factors of the network entity correspond to the current characteristics of the network entity. Exemplary characteristics of the network entity may include the current configuration of the network entity, the version of the network entity, the activity characteristics of the network entity, the sentiment value or polarity associated with the network entity, etc. The variable factors may be weighted so that some of the variable factors contribute more to the variable factor sub-score than other of the variable factors.

[0126] Where sentiment information is used to calculate or modify a trust score, such sentiment information may be derived from text associated with one or more input systems 103, which may include information derived from diagnostic data associated with one or more network entities 102, such as comments generated by an administrator or provided by a user when resolving an issue with a network entity 102 in a trouble ticket registration system implemented within network 100. In other embodiments, the sentiment information may be derived from text or other information associated with metadata associated with one or more network entities 102.

[0127] The analysis system 231 can perform functions related to sentiment analysis for a given entity. Sentiment analysis information can be used to determine variable factor sub-scores for one or more network entities 102, such as in combination with Figure 3 As described. Analysis system 231 can apply the analysis as a component of trust. In the embodiments described herein, analysis system 231 can be integrated into scoring system 222 so that variable factor system 234 and calculation system 238 calculate the trust score by considering sentiment analysis associated with or between network entities (see calculations associated with Table 1 below). However, in other embodiments, analysis system 231 can be used to adjust (and thereby improve) a trust score that has been determined by a scoring system (such as, scoring system 222). In such embodiments, analysis system 231 can apply adjustments to the trust score of an entity based on attitude information or sentiment analysis.

[0128] Each of the reputation factors of the network entity may be a function of specified historical events involving the network entity. For example, the trust controller 104 modifies the value of the reputation factor of the network entity based on the behavior of the network entity over time. For example, the trust controller 104 may modify the value of one reputation factor based on the number of times the network entity has spontaneously restarted. In another embodiment, the trust controller 104 may modify the value of a reputation factor based on the number of times the network entity has been reconfigured.

[0129] Each of the subjective factors of a network entity can be a function of a specified subjective assessment associated with the network entity. For example, the trust controller 104 can collect information about such subjective assessments from one or more input systems 103. The trust controller 104 can also access information about how a given user (or consumer of a trust score) values ​​various types of subjective assessments. In some embodiments, a given user may value some subjective assessments over others, or may value some assessments more than others. The trust controller 104 can apply weights to each subjective assessment corresponding to the values ​​or priorities given to each subjective assessment by the user or other consumer of the trust score. In some embodiments, such weights can be applied on a user-specific basis, but in other embodiments, such weights can be applied to different user groups. For example, the trust controller 104 can apply a set of weights when calculating a subjective score or sub-score for a user with one role (e.g., a network operator), but a different set of weights when calculating a score for other users (e.g., a field technician).

[0130] In calculating the trust score, the trust controller 104 may also consider attributes of the entities that separate one entity from the other. For example, if the network entity 102A trusts the network entity 102C, and the network entity 102C trusts the network entity 102E, the network entity 102A may trust the network entity 102E to some extent because the network entity 102A trusts the entity that also trusts the network entity 102E. In such an embodiment, the trust controller 104 may increase the trust score of the network entity 102E for operations (e.g., data transfer) that the network entity 102A may perform with the network entity 102E. The network entity 102A may not have any direct interactions with the network entity 102E, but the network entity 102A may be able to infer a trust relationship with the network entity 102E based on the trust of the network entity 102A for the intermediate entity (e.g., the network entity 102C).

[0131] On the other hand, if network entity 102A trusts network entity 102C, but network entity 102C does not trust network entity 102E, network entity 102A may not trust network entity 102E because network entity 102C (an entity that network entity 102A trusts) does not trust network entity 102E. In this embodiment, trust controller 104 may lower the trust score of network entity 102E for operations that network entity 102A may perform with network entity 102E. Therefore, network entity 102A may determine a trust inference about network entity 102E based on the trust level of network entity 102A with network entity 102C and the trust level of network entity 102C with network entity 102E.

[0132] As part of calculating the trust score, the variable system 234 may apply different weights to different characteristics to determine the variable sub-score of the network entity. Therefore, a particular characteristic may contribute more to the variable sub-score than other characteristics. Table 1 below shows exemplary contributions of specific selections (possible values) for specific characteristics of a network entity. As shown in the embodiment of Table 1, software applications (apps) may be classified into multiple categories (e.g., Category 1, Category 2, Category 3, etc.). Apps in different categories may correspond to different risk levels. For example, Category 1 apps may be limited to apps approved by a system vendor, signed applications, applications with security audits, etc., Category 2 apps may be limited to applications approved by a vendor, unsigned applications, applications with regular security updates, etc., Category 3 apps may be unapproved apps, etc. In Table 1, the Contribution column indicates the score that will be contributed if the corresponding selection in the "Selection" column is applicable. In other embodiments, one or more selections may be associated with negative values, but the final variable sub-score may be limited to a minimum value of 0 or other predefined minimum values.

[0133] In Table 1, the "Sample Score" column provides an example of how the variable factor sub-scores may be calculated for a particular network entity. Thus, in the example of Table 1, if the network entity uses only Category 1 apps, the variable factor system 234 may determine that the contribution to the characteristic ("software") is 30. If a particular attribute of the network entity (e.g., software) is not a known good version, the variable factor system 234 may determine that the contribution to the second characteristic is 0. If the network entity uses a software version within the last 3 released versions of the software, the variable factor system 234 may determine that the contribution to the third characteristic (e.g., "software version <= latest version - 3") is 10. If the sentiment analysis for the network entity indicates positive polarity, the variable factor system 234 may determine that the contribution to the "sentiment" characteristic is 20. Based on such an assessment, the variable factor system 234 may determine that the variable factor sub-score is 60 (30+0+10+20). See Table 1 below.

[0134] Table 1

[0135]

[0136] The reputation system 236 may determine a reputation sub-score for the network entity 102. The reputation sub-score for the network entity may be based on one or more reputation factors for the network entity. Each of the reputation factors for the network entity may be a function of a specified historical event involving the network entity. The reputation factors for the network entity may be user defined. Historical events may be defined as those events that occurred within a specific time period (e.g., 5 weeks, 10 weeks, 6 months, etc.). The reputation system 236 may store the reputation sub-score for the network entity 102 as score data 230. Exemplary types of reputation factors may include:

[0137] Multiple time intervals (e.g., weeks, days, etc.) without resetting the network entity,

[0138] multiple time intervals (e.g., weeks, days, etc.) without rebooting the network entities,

[0139] Multiple failed logins,

[0140] Login frequency,

[0141] Configure frequency,

[0142] Multiple protocol timeouts or other runtime data.

[0143] Table 2 below illustrates an embodiment of how reputation system 236 may determine a reputation sub-score for a network entity. For example, in Table 2, for each month that the network entity does not undergo a reset, reputation system 236 may increase the reputation sub-score for the network entity by 5. Additionally, in Table 2, for each month that the network entity does not undergo a reboot, reputation system 236 may increase the reputation sub-score for the network entity by 15. Because the time period considered is 5 months, in this embodiment, the maximum reputation sub-score is 100.

[0144] Table 2

[0145]

[0146] Table 3 below illustrates an embodiment of how the subjective system 233 may determine a subjective sub-score for a network entity. For example, in Table 3, the subjective system 233 may determine information about various subjective factors based on information accessed from the input system 103 (e.g., the embodiments listed in Table 3 include reliability, uptime, and flexibility). Such information may correspond to a score representing the rating of the relevant network entity for each factor (e.g., the network entity referenced in Table 3 has a reliability rating of 90 / 100). The subjective system 233 may also determine a weight to be applied to each of the subjective factors, where the contribution of each factor to the subjective sub-score corresponds to the weight multiplied by the rating. For example, in Table 3, since the "reliability" factor is (for a given stakeholder or stakeholder role) 60%, the reliability factor contributes 54 to the overall subjective sub-score. Note that factors with a weight of 0% are effectively excluded from consideration when calculating the subjective sub-score.

[0147] Table 3

[0148]

[0149] Sure Figure 3 The weights applied in may be the result of capturing information that reflects the priorities of stakeholders for the intended use or application of the resulting trust score. One way to capture such information may be through a stakeholder survey. A non-limiting example of such a survey is outlined below:

[0150] 1. What is your role in the organization (e.g., network operations center (NOC) staff, network planner, field technician, end user, customer)?

[0151] 2. In your opinion, which of the following factors are most important in determining the trustworthiness of a network or system? (Select all that apply)

[0152] -reliability

[0153] - Uptime

[0154] - Ability to solve problems quickly and effectively

[0155] - Scalability

[0156] -flexibility

[0157] - Ability to integrate with other systems

[0158] -Easy to maintain

[0159] - Robustness

[0160] - Availability of technical support

[0161] -Privacy and security

[0162] - Quality of the network

[0163] -Level of customer support

[0164] -Comprehensive cost performance

[0165] 3. Please rank the factors you selected in the previous question in order of importance, where 1 is the most important and [number of factors selected] is the least important.

[0166] In making this consideration, it is necessary to give some idea of ​​how to assign scores to the factors.

[0167] 4. Do you think there are any other important factors not listed here when determining the trustworthiness of a network or system? Please describe.

[0168] 5. How do you currently assess the trustworthiness of a network or system?

[0169] 6. In what ways do you think credibility calculations that take subjective factors into account would be useful or beneficial in your role in an organization?

[0170] 7. Is there anything else you would like to add about the importance of credibility or how credibility is assessed in your role in the organization?

[0171] Other techniques or processes may be used to gather information about appropriate weights to apply to the various stakeholders' subjective factors. Such techniques may include focus groups, interviews, online forums, customer feedback forms, and user experience (UX) studies. Preferably, such techniques enable stakeholders to openly discuss their values, priorities, and concerns, and to provide detailed and specific feedback about their experience with the network or system.

[0172] An iterative approach to collecting subjective factors may involve the output of a baseline credibility calculation. By comparing the credibility calculations to the factors scored in previous survey responses, stakeholders can further refine the importance of specific factors while demonstrating their impact, as presented in a credibility report.

[0173] The computing system 238 may determine the trust score of the network entity using one or more of the precondition sub-score of the network entity, the variable factor sub-score of the network entity, the reputation sub-score of the network entity, and / or the subjective factor sub-score. When calculating the trust score of the network entity, the computing system 238 may determine that if one or more of the preconditions are not met (e.g., if the precondition sub-score has a minimum value, such as 0), the trust score of the network entity indicates no trust. In some embodiments, the computing system 238 determines the trust score of the network entity as the sum of the variable factor sub-score and the reputation sub-score. In some embodiments, the computing system 238 determines the trust score of the network entity as a weighted sum of the variable factor sub-score, the reputation factor sub-score, and the subjective factor sub-score. For example, the computing system 238 may apply a 60% weight to the variable factor sub-score, a 30% weight to the reputation factor sub-score, and a 10% weight to the subjective factor sub-score. In some embodiments, the weights applied to the variable, reputation, and subjective factor sub-scores are user-defined. Therefore, in such embodiments, because the weights applied to each sub-score are user-defined, the final trust score may depend on the user's priorities and preferences. In some embodiments, computing system 238 may multiply the resulting sum (or weighted sum) by the precondition sub-score to determine the trust score of the network entity. In some embodiments, if any precondition is not met, computing system 238 may simply set the trust score of the network entity to a minimum value (e.g., 0) instead of trust controller 104 calculating the precondition sub-score. Computing system 238 may store the trust score of network entity 102 as score data 230. In some embodiments, the trust score of network entity 102 may include one or more trust score results 500. Such trust score results 500 may also be stored as score data 230.

[0174] Preferably, and to provide full traceability for the trust score calculation, the trust controller 104 may maintain a record of any subjective (or other) factor values ​​that contributed to the trust calculation. This may include a reference to each factor, value, and collection instance (e.g., stakeholder survey), which in turn may include a date and reference to the stakeholder. To reflect the changing needs of the client, stakeholders may be asked to provide updated responses to the survey (or select from predefined criteria), so that the trust score assessment can remain relevant and useful.

[0175] In some embodiments, the scoring system 222 may aggregate the trust scores of two or more network entities 102 to determine a trust score of a higher-level network entity. Embodiment types of higher-level network entities may include networks, services, routes, and / or other collections of one or more network entities. The scoring system 222 may aggregate the trust scores in one of various ways. For example, the scoring system 222 may aggregate the trust scores of two or more network entities 102 to determine the trust score of the higher-level network entity by taking the lowest trust score of the two or more network entities as the trust score of the higher-level network entity. In another embodiment, the scoring system 222 may aggregate the trust scores of two or more network entities 102 to determine the trust score of the higher-level network entity as the average or sum of the trust scores of the two or more network entities.

[0176] The action system 224 may perform one or more actions based on the trust score determined by the scoring system 222 for the network entity 102. For example, the action system 224 may modify the traffic pattern of the computer network 100 based on the trust score of the network entity. For example, in this embodiment, based on the trust score of the network entity, the action system 224 may change the traffic pattern in the computer network 100 to divert network traffic away from the network entity or to direct network traffic to the network entity. For example, if the trust score of the network entity is below a certain threshold, the action system 224 may change the traffic pattern in the computer network 100 to divert network traffic away from the network entity. In some embodiments, if the trust score of the network entity is above a certain threshold, the action system 224 may change the traffic pattern in the computer network 100 to direct network traffic to the network entity. In such an embodiment, based on the trust score of the network entity being greater than a certain threshold, the action system 224 may change the traffic pattern by sending instructions to one or more routers in the computer network 100 to cause the routers to change the routing in the computer network 100, and thereby control the operation of such routers. For example, such control may cause those routers to route data packets such that the data packets are directed along a route to or through a network entity.

[0177] In another embodiment, the action system 224 may determine that there is an information conflict between two sensors (e.g., an angle of attack sensor and a nose pitch sensor in the context of an aircraft). In this embodiment, the action system 224 may perform one or more actions based on the trust score of the sensor (i.e., the network entity) in response to determining such a conflict. For example, the action system 224 may generate a notification for the operator recommending the use of information from a sensor with a greater trust score. In another embodiment, the action system 224 may disable a sensor with a lower trust score. In some embodiments, the action system 224 may recommend a probe or obtain a combination of other sensor data to determine which of the two sensors is more likely to generate accurate data. In an embodiment where the network entity includes multiple clock sources (e.g., a precision time protocol (PTP) clock source), the action system 224 may change the primary clock source from the current clock source to the backup clock source because the backup clock source has a greater trust score than the current clock source. In some embodiments, the action system 224 may identify a route through the network 100 based on the trust scores of the network entities in the network 100. Thus, action system 224 may configure routers (and thereby control the operation of such routers) to route network traffic along routes that pass through network entities having high trust scores.

[0178] The action system 224 may also perform other types of actions based on the trust score determined by the scoring system 222 for the network entity 102. For example, the action system 224 may determine or adjust a configuration associated with the firewall 192 based on the trust score of the network entity 102A being below a specified trust threshold. Such an adjustment may minimize or limit the ports on the firewall 192 that enable interaction with the network entity 102A. In another embodiment, the action system 224 may interact with one or more access control systems 193 to limit access to devices with trust scores below a threshold. The action system 224 may interact with the asset management system 194 to mark one or more devices as unavailable when the trust score is below a particular threshold or if the trust score is trending downward. The action system 224 may also issue an alert to indicate that the trust score associated with one or more network entities 102 is low, trending lower, and / or has trended below a given threshold.

[0179] When calculating a trust score and / or generating a trust score result 500, the trust plan system 227 can perform functions related to identifying, interpreting, and / or applying one or more trust score plans 400. The trust plan system 227 can use one or more trust score plans 400 to determine how to calculate a trust score. The trust plan system 227 may be able to parse the trust score plan 400 to identify contribution classes, trust factors, contribution values, and contribution factors. The trust plan data store 237 can be primarily maintained by the trust plan system 227.

[0180] Tracking system 226 can track changes in trust scores and / or sub-scores and re-evaluate trust levels associated with one or more entities. Tracking system 226 can collect information from source data 228 and determine changes in trust scores and / or sub-scores associated with one or more network entities 102. Tracking system 226 can determine which network entities 102 need services, such as upgrades, audits, reviews, tests, or other assessments based on historical information about the trust scores of each network entity 102. Tracking system 226 can monitor sentiment associated with one or more network entities 102 and adjust trust scores as the sentiment changes. In some embodiments, tracking system 226 can also identify one or more network entities 102 with consistently high trust scores and implement a trend to use such network entities 102 for high priority, high importance, or critical tasks.

[0181] Inference system 221 may perform functions related to inferring a trust score for a given entity from the perspective of another entity based on the distance, separation, or location of the entity. Inference system 221 may apply the inferred trust as a component of trust or a degree of trust. In some embodiments, inference system 221 may be used to adjust (and thereby improve) a trust score determined by scoring system 222. In such embodiments, inference system 221 may apply an adjustment to an entity's trust score that is based on a degree of separation between the entity and another entity whose trust is being assessed, where the degree of separation corresponds to a distance, a count of intermediate entities, or a location associated with the entity being assessed.

[0182] For example, in Figure 1A, if the trust score of network entity 102E is 70, then network entity 102C, which is adjacent to network entity 102E, may consider network entity 102E to have a trust score of 70. If the trust score of network entity 102C is 80, then network entity 102A, which is adjacent to network entity 102C, may consider network entity 102C to have a trust score of 80. However, the trust score that associates network entity 102A with network entity 102E may be a function of the trust scores of network entity 102C, network entity 102E, and the number of intermediate network entities between network entities 102A and 102E. Such a function may be described as follows:

[0183] Trust score of 102A = function (trust score of 102C, trust score of 102E, count of intermediate entities between 102A and 102E)

[0184] In case the count of the intermediate entity is high, the trust score may be lowered. In case the count is low, the trust score may be higher.

[0185] In other embodiments, inference system 221 may be integrated into scoring system 222 such that computing system 238 computes a trust score by considering inferences about trust between network entities 102 .

[0186] In embodiments where the inference system 221 or aspects of the inference system 221 are integrated into the scoring system 222, the variable factor system 234, the reputation system 236, and / or the subjective system 233 may use trust inferences or information derived from trust inferences to make variable and reputation assessments, respectively. The variable factor system 234 may recalculate trust scores, for example, when new entities are added and new trust inferences are determined. The reputation system 236 may assess whether trust inferences between entities improve or deteriorate over time. The subjective system 233 may change the assessment of subjective factors as the collective subjective scores change over time. For example, if the subjective scores of various network entities 102 tend to increase over time (e.g., because devices become more reliable over time, such normalization may enable subjective reliability scores from different time periods to be effectively compared), then such an assessment may normalize the subjective scores. In such embodiments, Tables 1, 2, and 3 described above may be modified and relabeled as Tables 1A, 2A, and 3A, as follows:

[0187] Table 1A

[0188]

[0189] Table 2A

[0190]

[0191] Table 3A

[0192]

[0193] Scoring system 222 may use trust inferences or information derived from such trust inferences to supplement existing metrics, thereby improving the accuracy of scoring system 222. In general, inference system 221 may receive information from and output information to one or more other systems or modules in storage device 216, and may otherwise interact and / or operate in conjunction with one or more other systems and / or modules of trust controller 104.

[0194] It is important to ensure that the calculation of credibility is objective and unbiased, even when subjective factors are taken into account. Several strategies can be employed to address potential bias in the calculation:

[0195] 1. Use a diverse range of subjective factors: By considering a diverse range of subjective factors, calculations can better reflect the views and values ​​of different stakeholders. This can help reduce the influence of any one individual or group and minimize potential bias.

[0196] 2. Use a transparent and unbiased process to collect and incorporate subjective factors: Clearly defining and communicating the process used to collect and incorporate subjective factors will help ensure that the process is transparent and unbiased and that stakeholders understand how their input will be used.

[0197] 3. Review and revise calculations regularly: As the needs and priorities of the organization change, it is necessary to review and revise the calculation to ensure that it remains relevant and useful. This can also be an opportunity to assess and address any potential bias in the calculation.

[0198] 4. Use multiple data sources: Combining multiple data sources can help provide a more complete and balanced view of credibility and reduce the influence of any one data source. This can include both objective and subjective data sources.

[0199] If the subjective factor is incorrectly or inappropriately defined, prompting and effective remediation may be important. The first step may be to clarify the definition of the subjective factor and ensure that all stakeholders agree on the definition. This may include providing additional training or documentation.

[0200] Once a correct definition of subjective factors has been established, any previous assessments that were incorrectly defined can be reviewed and corrected. Next, a transparent process for evaluating subjective factors can be adopted. This can include creating a checklist or guide to ensure that all relevant factors are being considered. A peer review process can help ensure that multiple perspectives are being considered.

[0201] It may also be appropriate to monitor the assessment process occasionally, periodically, or on an ongoing basis to ensure that subjective factors are assessed consistently and fairly. This may involve conducting regular audits or assessments to identify any biases or inconsistencies in the assessment process and taking steps to address them.

[0202] Creating a culture of openness and transparency around the evaluation process can also promote appropriate and productive subjective evaluations and may involve encouraging feedback from all stakeholders (including customers, employees, and suppliers) and being willing to change the evaluation process based on that feedback.

[0203] To the extent that stakeholders or other actors intentionally seek to skewer subjective factors to influence any decision-making process, it may be appropriate to address such attempts by ensuring transparency and accountability in the decision-making process. This may involve establishing clear guidelines for evaluating network devices and documenting the factors considered in making decisions.

[0204] Another approach is to involve multiple stakeholders in the decision-making process. This could include representatives from different departments within the telecom operator as well as external experts or consultants. Having different perspectives makes it more difficult for any one person to manipulate the decision-making process. It may also be appropriate to establish procedures that enable any suspected instances of bias or unethical behavior to be reported. This could involve setting up a hotline or reporting mechanism that allows stakeholders, users or employees to report concerns anonymously. Finally, ongoing training and education can promote awareness and understanding of the importance of an objective decision-making process.

[0205] Figure 2 The various systems shown in (e.g., data collection system 220, inference system 221, scoring system 222, action system 224, tracking system 226, prerequisite system 232, variable factor system 234, reputation system 236, computing system 238) can be implemented as modules or other logic. In such embodiments, such modules shown or described elsewhere in the present disclosure can perform operations described in a manner of software, hardware, firmware, or a mixture of hardware, software, and firmware that resides in one or more computing devices and / or executes at one or more computing devices. For example, a computing device can use multiple processors or multiple devices to execute one or more of such modules. A computing device can execute one or more of such modules, such as a virtual machine executed on underlying hardware. One or more of such modules can be executed as one or more services of an operating system or computing platform. One or more of such modules can be executed as one or more executable programs at the application layer of a computing platform. In other embodiments, the functions provided by the modules may be implemented by dedicated hardware devices.

[0206] Although the specific modules, data storage, components, programs, executable files, data items, functional units and / or other items included in one or more storage devices can be shown separately, one or more of such items can be combined and operated as a single module, component, program, executable file, data item or functional unit. For example, one or more modules or data storages can be combined or partially combined so that they operate or provide functions as a single module. In addition, one or more modules can interact with each other and / or operate in coordination with each other so that, for example, one module serves as a service or extension of another module. In addition, each module, data storage, component, program, executable file, data item, functional unit or other item shown in the storage device can include multiple components, subcomponents, modules, submodules, data storage and / or other components or modules or data storages not shown.

[0207] In addition, each module, data store, component, program, executable file, data item, functional unit, or other item shown in the storage device can be implemented in different ways. For example, each module, data store, component, program, executable file, data item, functional unit, or other item shown in the storage device can be implemented as a downloadable or pre-installed application or "app". In other embodiments, each module, data store, component, program, executable file, data item, functional unit, or other item shown in the storage device can be implemented as part of an operating system executed on a computing device.

[0208] Figure 3 is a conceptual diagram illustrating the application of one or more trust scoring schemes to calculate a trust score result for a specific network entity according to one or more aspects of the present disclosure. Figure 3 , multiple trust score schemes 400 are shown, each trust score scheme describing information about the scheme, including how to calculate a trust score for an entity according to the scheme. Generally, each trust score scheme 400 includes a description of trust score factors and trust score contributions that are associated with and / or used by the scheme. Each of the trust score schemes 400 can be used by the trust controller 104 to perform a trust score calculation for an entity, thereby generating a trust score result 500. To perform the trust score calculation, the trust controller 104 uses trust score values ​​associated with network entities, where the information is provided by one or more source services 303. In some embodiments, the source service 303 can correspond to or be Figure 1A An embodiment of the input system 103 is shown in FIG.

[0209] In some embodiments, for each entity, such as Figure 1AFor each of the network entities 102 in FIG. 1 , a default trust score scheme 400 may be available for use when performing a trust score calculation for that entity. In the case where the network entity 102 is a network device, for example, such a default trust score scheme 400 may be provided by the manufacturer of the network device. Such a default scheme may be designed by the manufacturer for expected use cases and / or may be based on specifications, rules, and / or "workbench" documents published by a standards organization.

[0210] In other embodiments, a customized trust scoring scheme 400 that more precisely meets the needs of a network or user environment may be used instead of using the default scheme. Figure 1A The network entity 102 shown in FIG. Figure 1A One or more network entities 102 select a particular trust scoring scheme 400. Figure 1A 4. In some embodiments, a trust scoring scheme 400 for each of the network entities 102A in the example embodiment of the present invention may be used to calculate a trust score for each of the network entities 102A in the example embodiment of the present invention, the trust score calculation may be appropriately tailored for a given network, context, or environment. In some embodiments, a customer classification value may control which trust scoring scheme is used. For example, if a customer is classified as a "healthy" type of customer, a first trust scoring scheme may be used, while a different trust scoring scheme may be used for customers classified as "payment systems" or "government". Such a trust scoring scheme may specify the type of subjective assessment associated with a given network entity 102. In some embodiments, various subjective assessments (reliability, flexibility, privacy) may be applied to some network entities 102 and not others.

[0211] According to one or more aspects of the present disclosure, the trust controller 104 may associate one or more trust scoring schemes 400 with one or more network entities 102. For example, in Figure 1A , Figure 2 and Figure 3 In the depicted embodiment, the input device 208 detects the input and outputs information about the input to the trust plan system 227. The trust plan system 227 determines that the input corresponds to information identifying a trust score plan 400 associated with one or more particular network entities 102. For example, the input may indicate that the trust score plan 400A may be applied to the network entity 102A, potentially overriding any default trust score plan that may otherwise be used for the network entity 102A. The same input or other inputs may indicate that a different trust score plan 400 may be applied to the network entity 102B (again, overriding any default trust score plan 400). The trust plan system 227 stores information within the trust plan data store 237 about which trust score plans 400 should be applied to various network entities 102 when generating trust score results 500 for such network entities 102.

[0212] Typically, different trust score schemes 400 may be associated with Figure 1A However, if combined with Figure 1A As suggested, one trust scoring scheme 400 may also be applied to multiple devices, particularly devices that are similar, have similar functionality, and / or come from the same manufacturer (e.g., routers provided by the same manufacturer may use a common trust scoring scheme 400). Additionally, a particular network entity 102 may have multiple trust scoring schemes 400 applied in various or different contexts, as further described below.

[0213] Trust controller 104 can collect data. For example, still referring to Figure 1A , Figure 2 and Figure 3 , each of the input system 103 and the source service 303 collects data for one or more specific network entities 102 in the network 100, wherein each of the input system 103 and the source service 303 collects information corresponding to factor values, which may be used by the trust scoring program 400 when calculating the trust score of the one or more network entities 102. The communication unit 204 of the trust controller 104 detects the input and outputs information about the input to the data collection system 220. The data collection system 220 determines that the input corresponds to information (e.g., factor values, sentiment information, subjective assessment information, and / or compliance, vulnerability, and integrity data). The data collection system 220 evaluates the data to identify which of the network entities 102 the information applies to and which of the input system 103 and the source service 303 is providing the data. The data collection system 220 may also determine a set of contribution values ​​to be reported and an identification of the contribution factors associated with the values ​​based on the data. In some embodiments, the trust controller 104 may expose an application programming interface that each of the source services 303 can use to report factor values. Such an API might include a method for posting factor values ​​of the following form:

[0214] / / PostFactorValues ​​publishes one or more factor values ​​defined by the value of the entity identified by the entity ID (entityID) from the system identified by the source ID (sourceID).

[0215] Release factor value (entity ID string, source ID string, value [] * value release)

[0216] / / ValuePost associates a factor with a value.

[0217] Type value publication structure {

[0218] / / FactorRef identifies the trust score.

[0219] Factor reference string

[0220] / / Value is the factor that holds the value to be published.

[0221] Value interface{}

[0222] }

[0223] In general, the data collection by the input system 103 and the source service 303, and the data collection system 220 that reports such data to the trust controller 104, may occur independently of the association of any trust scoring scheme 400 with each of the network entities 102. In other words, the source service 303 may collect data before, during, or after a trust scoring scheme 400 is selected, changed, or customized for a given network entity 102.

[0224] The trust controller 104 may receive a trigger to generate a trust score result 500. For example, referring again to Figure 1A , Figure 2 and Figure 3 , the input device 208 of the trust controller 104 detects a signal corresponding to a command, trigger, or request to calculate a trust score for a particular network entity 102 (such as network entity 102A) determined by the scoring system 222. In some embodiments, the command, trigger, or request may originate from an interaction with the UI (e.g., by a user or administrator). In other embodiments, the command, trigger, or request may originate from a scheduling request or occur during a Figure 1A Events elsewhere within network 100 or events from a different network.

[0225] In the case where the trigger is due to a UI interaction, the scoring system 222 can receive an indication of a role associated with the user or administrator performing the UI interaction. The scoring system 222 can use the role to determine a set of default weights that can be used to calculate the subjective factor sub-score. In some embodiments, the set of default weights can indicate the weights to be applied to each of the subjective factors when calculating the subjective sub-score (e.g., see Table 3 and Table 3A).

[0226] In other embodiments, rather than receiving information about roles that can be used to identify subjective factor weights, the scoring system 222 can receive information about weights that should be used for a particular user, which can override some or all of the default weights that can be associated with the user's roles. In such embodiments, the weights can be derived from input received from the user during a UI interaction or during an earlier time period. For example, when a new user account is created, the trust controller 104 can present a stakeholder survey at initial login, collect subjective factors from the user or stakeholders, and thereafter use that information to customize the scoring specifically for the user. Alternatively, or in addition, the user might select from a predefined set of criteria associated with their role.

[0227] The trust controller 104 may select an appropriate trust scoring scheme 400 to use when generating a trust scoring result 500 for the network entity 102A. Figure 1A , Figure 2 and Figure 3 , the trust plan system 227 of the trust controller 104 accesses information in the trust plan data store 237. Based on the accessed information, the trust plan system 227 identifies a specific trust score plan 400 for the network entity 102A. In some embodiments, the trust plan system 227 may determine that a default trust score plan 400 is suitable for use in generating the trust score result 500. In other embodiments, the trust plan system 227 may determine that a customized trust score plan 400 (such as a trust score plan generated in response to administrator input) is more suitable for use in generating the trust score result 500. In order to determine which of the trust score plans 400 to use for the network entity 102, the trust plan system 227 may evaluate context information included in the command, trigger, signal, or request received by the trust controller 104. Such context information may identify the context or situation in which the trigger was generated, and the trust plan system 227 may use this information in identifying an appropriate trust score plan 400 to use in generating the trust score result 500 for the network entity 102A.

[0228] Furthermore, in some cases, the trust controller 104 may use historical information to evolve the content of the trust scoring scheme used to calculate the trust scoring result 500. Alternatively, or in addition, the trust controller 104 may use such information to evolve, adjust, or configure the manner in which an appropriate trust scoring scheme is selected. Machine learning techniques may be applied to train models to edit existing trust scoring schemes, generate new trust scoring schemes, or modify which of a set of available trust scoring schemes is selected in changing circumstances.

[0229] The trust controller 104 may calculate sub-scores for use when generating the trust score result 500 for the network entity 102A. For example, continuing with the described embodiment, the trust scheme system 227 outputs information about the selected trust score scheme 400 to the scoring system 222 of the trust controller 104. The scoring system 222 uses the information about the selected trust score scheme 400 to identify trust score factors related to the selected trust score scheme 400. The scoring system 222 accesses information about the relevant trust score factors in the source data 228. The information accessed in the source data 228 may include information about trust score values ​​reported to the trust controller 104 by one or more source services 303, as described above.

[0230] The precondition system 232 of the scoring system 222 evaluates the preconditions specified in the selected trust scoring scheme 400. The precondition system 232 determines whether the source data 228 associated with the network entity 102A satisfies the preconditions identified in the selected trust scoring scheme 400. If the data indicates that the network entity 102A does not satisfy the preconditions, the scoring system 222 may conclude that the trust score of the network entity 102A is 0, and may generate a trust score result 500 reflecting such a score. If the data indicates that the network entity 102A does satisfy the preconditions, the scoring system 222 may perform further calculations to generate the trust score result 500, including determining a variable factor sub-score, a reputation sub-score, and a subjective factor sub-score.

[0231] To calculate the variable sub-scores, the variable system 234 identifies the contributing factors specified in the variable category of the selected trust scoring scheme 400. For example, Figure 2 As described, variable factor system 234 may apply appropriate weights (as specified in the selected trust scoring scheme 400) to different trust factors (e.g., software characteristics, sentiment, also specified in trust scoring scheme 400) to determine variable factor sub-scores for network entity 102A. Variable factor system 234 may store information about the variable factor sub-scores for network entity 102A in scoring data 230.

[0232] To calculate the reputation factor sub-scores, reputation system 236 identifies contributing factors specified in the reputation factor category of the selected trust scoring scheme 400. Reputation system 236 may apply the specified weights (specified in the selected trust scoring scheme 400) to the reputation factors identified in the selected trust scoring scheme 400 to determine the reputation factor sub-scores for network entity 102A. Reputation system 236 may store information about the reputation factor sub-scores for network entity 102A in scoring data 230.

[0233] To calculate the subjective factor sub-score, the subjective system 233 identifies the subjective factors specified in the subjective factor category of the selected trust scoring scheme 400. For example, Figure 2 As described, subjective system 233 may apply appropriate weights (such as specified by the user's role or by the preferences of a particular user) to different subjective scores (e.g., reliability, flexibility, ease of maintenance, level of customer support) to determine a subjective factor sub-score for network entity 102A. Subjective system 233 may store information about the subjective factor sub-scores for network entity 102A as score data 230. In some embodiments, information about the weights that may be applied to various roles may be included in trust scoring scheme 400.

[0234] Trust controller 104 may generate a trust score result 500 for network entity 102A. Figure 1A , Figure 2 and Figure 3 In the embodiment described in the context of FIG. 1 , the computing system 238 of the scoring system 222 accesses information about the variable factor sub-scores, the reputation factor sub-scores, and the subjective factor sub-scores in the scoring data 230. The computing system 238 uses these sub-scores to generate the trust score result 500. The computing system 238 stores information about the trust score result 500 in the scoring data 230 of the trust controller 104.

[0235] In generating the trust score result 500, the computing system 238 can calculate a specific numeric trust score value based on the sub-scores and information included in the selected trust score scheme 400. For example, as described herein, the contribution values ​​included in the selected trust score scheme 400 are associated with the trust score identified in the selected trust score scheme 400. The contribution values ​​are used to define the contribution of each factor to the calculated trust score. How the contribution values ​​are used can depend on the type of trust factor with which they are associated. For example, a trust factor can have an implicit maximum contribution and an actual contribution. The percentage score of the factor category is determined as follows.

[0236] Factor category sub-score = (the sum of the actual contribution of each of the factors in the category / the sum of the maximum contribution of each of the factors in the category) * 100

[0237] A simplified version of the trust score calculation using factor category sub-scores can have the following form:

[0238] Trust score = (precondition sub-score) * (variable factor sub-score / 100 * plan.variable weight) + (reputation factor sub-score / 100 * plan.reputation weight) + (subjective factor sub-score / 100 * plan_subjective weight))

[0239] In the above calculations, the overall percentage score for each of the variable and reputational categories may be adjusted according to the category contribution (e.g., as defined in the selected trust scoring scheme 400). Additionally, in the above calculations, the precondition subscore will be either 0 (precondition not met) or 1 (precondition met). In the event that the precondition subscore for the network entity 102A is 0, the trust score for the physical network entity 102A will generally be 0. However, if the precondition is met, the trust score for the network entity 102A will be the above-described function of the variable factor subscore, the reputation subscore, and the subjective factor subscore, as defined by the selected trust scoring scheme 400.

[0240] The trust score result 500 may include a trust score report 501, a trust score support document 502, and one or more factor value reports 503. The trust score report 501 may include a calculated trust score (e.g., a trust score calculated as described above), as well as information about variable, reputational, and subjective sub-scores. The trust score support document 502 may identify the trust score scheme used to calculate the trust score result and / or may include information about how the trust score is calculated, thereby enabling an administrator to determine and / or identify the underlying data used to calculate the trust score. In some embodiments, the trust score support document 502 includes a reference to one or more factor value reports 503. The factor value reports 503 may come from different sets of source services 303, which may correspond to compliance, integrity, and / or vulnerability source services 303. In some embodiments, each of the factor value reports 503 may provide factor values ​​for calculating the trust score and generating the trust score result 500. An applicable trust scoring scheme 400 along with one or more of these factor value reports 503 may enable an administrator to track or determine how a trust score is calculated, which may be useful for adjusting the trust scoring scheme 400 for one or more network entities 102, for debugging purposes, troubleshooting, and / or verifying system integrity.

[0241] The trust controller 104 can act on the trust score result 500. For example, referring again to Figure 1A , Figure 2 and Figure 3In the embodiments described in the context of FIG. 1 , the action system 224 accesses the trust score result 500 from within the score data 230. The action system 224 determines that certain aspects of the network 100 should be adjusted based on the trust score result 500. For example, the action system 224 can cause the communication unit 204 of the trust controller 104 to output a signal through the network 100. One or more devices or systems on the network 100 detect the signal. In one embodiment, the firewall 192 detects the signal and determines that the signal corresponds to a command to adjust the settings associated with the firewall 192. The firewall 192 appropriately adjusts its settings as specified by the information included in the signal or based on other information available to the firewall 192. In another embodiment, the alarm system 195 can detect the signal and adjust the sensitivity of one or more alarms configured for the network 100.

[0242] Figure 4 An exemplary trust scoring scheme according to one or more aspects of the present disclosure is shown. Figure 4 The trust scoring scheme 400 shown in FIG. 4 represents one possible format of information that may be included in a trust scoring scheme and may be Figure 1A The trust scoring schemes 400A to 400G shown in Figure 2 and / or Figure 3 Although any of the embodiments of the trust scoring scheme 400 described herein may be used. Figure 4 The trust scoring plan 400 is shown using a YAML representation of a trust scoring plan, but other formats (including JavaScript Object Notation (JSON), Extensible Markup Language (XML), any other domain specific language, or any other suitable format) are possible. In general, any suitable method of formatting, representing, or otherwise storing information according to a trust scoring plan may be used. The trust scoring plan may be in a format that is primarily machine-readable (e.g., a binary format) or in a format that facilitates human review (e.g., as in Figure 4 Formats that are text-based or easily edited by a human user or administrator may be preferred because those formats can facilitate changes to the trust scoring scheme (e.g., by an administrator) in response to changing conditions, needs, or circumstances.

[0243] In some embodiments, the trust controller 104 may provide administrators or other users with the ability to edit the trust scoring plan and customize the trust scoring plan for a specific environment. In some embodiments, the trust controller 104 may enable the underlying text (e.g., YAML or JSON text) to be accessible to administrators in order to edit the domain specific language in which the trust scoring plan is written. In other embodiments, the trust controller 104 may present a graphical or other user interface to such an administrator. In some cases, such a user interface (or an API to such a user interface) may not need to know the details of the domain specific language in which the trust scoring plan is written, thereby enabling the creation of a trust scoring plan or customization of an existing trust scoring plan in a more accessible manner.

[0244] Figure 4 The exemplary trust score scheme 400 of defines how to calculate a trust score for a particular entity (e.g., a "Junos" device), which may be a network device such as a router, switch, computing node, or other device or system. Figure 4 The trust scoring scheme 400 shown in FIG. 4 is a list of names of various trust factors (e.g., "vul:junos:advisory_severity" or "periods_since_restart"), each of which is categorized into the appropriate trust factor category ("precondition", "variable", "reputation", and "subjective"). For each factor, a factor "contribution" value is provided.

[0245] Trust factors can vary depending on the type of data required to express the value of the factor. For example, trust factors can be Boolean, enumerated, integer, decimal, or other forms.

[0246] The value of a Boolean factor can be expressed as true or false. For example, the value of a factor can indicate whether an entity is using a certified or approved version of software, or whether an entity is using a version that falls within the last three versions of the software. Factors in the Prerequisite category will typically consist of Boolean factors, and any false value for a trust factor classified in the Prerequisite factor category will result in a trust score of 0. When used in the Variable Factor category, a Boolean Trust Factor will typically add its contribution value to the Trust Score when the Trust Factor value is true. The maximum contribution value of a Boolean Factor is its contribution value.

[0247] The value of an enumerated factor may be represented as one of a set of fixed predefined values. An embodiment of an enumerated trust factor value may involve an advisory label for the software or device. Such labels may include "None", "Low", "Medium", "High", and "Critical" labels, which may correspond to severity levels. A trust scoring scheme that includes trust factors represented as an enumeration may specify a contribution value for each predefined value (e.g., in the above embodiment, such values ​​may be 100, 75, 50, 25, and 0, corresponding to "None" to "Critical", respectively). The maximum contribution value of an enumerated factor is the maximum contribution value associated with a predefined value (e.g., the maximum contribution value would be 100 in the described embodiment).

[0248] The value of a sub-scoring factor can be expressed as a percentage and can represent a score calculated by a contributing source service (e.g., one of source services 303). The percentage is used to adjust the size of the value that contributes to the trust score. For example, a sub-scoring factor may be generated by a compliance source service 303 to reflect the results of evaluating a set of rules related to a particular area (such as, rules specified in a standards-based benchmark document). If the compliance source service 303 reports a factor value of 66, and the contribution value of the factor is 10, then the factor will contribute a value of 6.6 to the trust score. The contribution of the sub-scoring factor value is the sub-score value divided by 100 multiplied by the maximum contribution (e.g., sub-score / 100*maximum contribution). The maximum contribution value of a sub-scoring factor is its contribution value.

[0249] Reputation factors are used in the reputation factor category, and typically, the value of a reputation factor is a count of time periods during which an entity meets the conditions defined by the factor. For example, a reputation factor may relate to the number of time periods during which a device has not been reset or restarted, or the number of time periods during which there is no excessive shell access. Typically, a reputation factor defines the amount of time for each time period (e.g., hourly, daily, weekly, monthly, etc.), the maximum number of time periods to be considered, and the contribution value of each time period that meets the conditions. For example, for a specific reputation factor with a contribution value of 5 per time period, a source service 303 reports a value of 3, and the contribution to the trust score will be 15. The maximum contribution value of a reputation factor is the product of the number of cycles to be considered and the contribution value per time period. In some reputation factor schemes, including at least some of the schemes described herein, a source service 303 may need to know the time period interval and the number of cycles for which the count should be reported. In other schemes, one or more source services 303 may only report events that will meet (or violate) the conditions defined by the trust factor. Using this information, the scoring system 222 of the trust controller 104 can determine the number of qualified cycles and use the information provided by each of the source services 303 to determine the appropriate contribution to the trust score.

[0250] Subjective factors are used in the subjective factors category and may correspond to evaluations of subjective information, ratings, and other information used to inform trust evaluations. Such information may be specified in the trust scoring scheme 400 in a manner that parallels variable factors and reputation factors.

[0251] Figure 5 Exemplary trust score results according to one or more aspects of the present disclosure are shown. Figure 5 The trust score result 500 shown in may be Figure 1A , Figure 2 and Figure 3 The trust score result 500 may be composed of a plurality of different documents, including a trust score report 501, a trust score support document 502 ( Figure 5 ) and factor value report 503 ( Figure 5 Of course, the trust score result 500 may be represented in other ways and in other formats.

[0252] Trust score report 501 presents a summary of the prerequisite, variable, reputation, and subjective factor category sub-scores for a particular entity. Figure 5 In the embodiment of , the trust score report 501 shows factor category sub-scores with values ​​of 1.00, 39.19, 0.00, and 11.00 for the device identified as "ex11." Those sub-scores result in a trust score of 25.21.

[0253] The trust score support document may be a JSON document that includes references to three factor value reports (each of which is from the compliance, integrity, and vulnerability source services 303). In such a trust score support document, a unique code may identify a specific value report generated by the source service 303. The factor value report may also be a JSON document based on the information reported by the compliance source service 303, and may identify the source service category and an identifier of the event that generated the factor value report (i.e., an identifier of a compliance scan). The information provided in the trust score report 501, the trust score support document, and the factor value report may be used to determine the low-level details of the scan that take into account the trust score calculated from the factor values.

[0254] Figure 6 is a flow chart illustrating operations performed by an exemplary trust controller 104 according to one or more aspects of the present disclosure. Figure 1A The network 100 and the trust controller 104 are described in the context of Figure 6 In other embodiments, Figure 6 The operations described in the above may be performed by one or more other components, modules, systems, or devices. Figure 6The operations described may be combined, performed in a different order, omitted, or may include additional operations not specifically shown or described.

[0255] exist Figure 6 In the process shown, and in accordance with one or more aspects of the present disclosure, the trust controller 104 may determine a prerequisite score for a network entity in a computer network (601). Figure 1A In the embodiment of the present invention, the trust controller 104 collects information about a particular network entity 102A from one or more input systems 103. The collected information is related to the conditions that must be met in order for the network entity 102A to be non-minimum. The trust controller 104 uses this information to determine whether each condition is met. Based on this determination, the trust controller 104 calculates a precondition sub-score for the network entity 102A, which in some embodiments is 0 or 1.

[0256] The trust controller 104 may determine a subjective score for the network entity based on one or more subjective factors of the network entity (602). For example, the trust controller 104 collects information from one or more input systems 103, wherein the information relates to subjective characteristics of the network entity 102A. The trust controller 104 applies a weight to each characteristic, wherein the weight is customized to the client (e.g., stakeholder) for whom the trust score is to be calculated. In some embodiments, the weight is determined based on the role of the stakeholder. The trust controller 104 calculates a subjective sub-score based on the applied weight.

[0257] Trust controller 104 may determine a trust score for the network entity based on the precondition score and the subjective score (603). For example, trust controller 104 may multiply the precondition subscore with the subjective subscore to determine the trust score. In some embodiments, such as where trust controller 104 also calculates a variable subscore and a reputation subscore, trust controller 104 may multiply the precondition subscore with the sum of the variable, reputation, and subjective subscores. Trust controller 104 generates a trust score result 500B.

[0258] Trust controller 104 may modify the operation of the computer network based on the trust scores of the network entities (604). Figure 1A In the example of FIG. 5 , the trust controller 104 evaluates the trust score result 500 and adjusts the configuration of the router or other network device based on the evaluation. Alternatively, or in addition, the trust controller 104 can reroute traffic, restrict access to the network entity 102A, or adjust the configuration associated with the access control system 193 and / or the asset management system 194.

[0259] For the processes, devices, and other embodiments or illustrations described herein included in any flowchart or flow chart, the specific operations, actions, steps, or events included in any technology described herein may be performed in a different order, may be added, merged, or omitted entirely (e.g., not all described actions or events are necessary for practicing these technologies). In addition, in certain embodiments, operations, actions, steps, or events may be performed non-sequentially, for example, by multithreading, interrupt processing, or multiple processors. Further specific operations, actions, steps, or events may be automatically performed, even if not specifically identified as being automatically performed. In addition, specific operations, actions, steps, or events described as being automatically performed may alternatively not be automatically performed, but rather, in some embodiments, such operations, actions, steps, or events may be performed in response to an input or another event.

[0260] The disclosures of all publications, patents, and patent applications mentioned herein are each incorporated herein by reference in their entirety. If any such disclosure material incorporated by reference conflicts with the present disclosure, the present disclosure shall control.

[0261] For ease of explanation, only a limited number of devices (e.g., network entity 102, trust controller 104, entity 110, quantitative entity 160, qualitative entity 170, etc.) are shown in the figure and / or in other illustrations referenced herein. However, the technology according to one or more aspects of the present disclosure can be performed with more such systems, components, devices, modules, and / or other items, and collective references to such systems, components, devices, modules, and / or other items can represent any number of such systems, components, devices, modules, and / or other items.

[0262] The accompanying drawings included herein each illustrate at least one exemplary implementation of an aspect of the present disclosure. However, the scope of the present disclosure is not limited to such implementations. Therefore, in addition to the systems, methods, or techniques shown in the figures, other embodiments or alternative implementations of the systems, methods, or techniques described herein may be suitable in other cases. Such implementations may include a subset of the devices and / or components included in the figures, and / or may include additional devices and / or components not shown in the figures.

[0263] The detailed description set forth above is intended as a description of various configurations, and is not intended to represent the only configuration in which the concepts described herein may be practiced. In order to provide a full understanding of the various concepts, the specific embodiments include specific details. However, these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in the form of block diagrams in the accompanying drawings of reference in order to avoid confusing such concepts.

[0264] Thus, although one or more implementations of various systems, devices, and / or components may be described with reference to a particular figure, such systems, devices, and / or components may be implemented in a number of different ways. Figure 1A and / or Figure 2 ) as separate devices may be alternatively implemented as a single device; one or more components shown as separate components may be alternatively implemented as a single component. In addition, in some embodiments, one or more devices shown as a single device in the figures of this document may be alternatively implemented as multiple devices; one or more components shown as a single component may be alternatively implemented as multiple components. Each of such multiple devices and / or components may be directly coupled via wired or wireless communication and / or remotely coupled via one or more networks. In addition, one or more devices or components that may be shown in the various figures of this document may be alternatively implemented as part of another device or component not shown in these figures. In this manner and in other ways, some functions described herein may be performed by distributed processing of two or more devices or components.

[0265] In addition, specific operations, techniques, features and / or functions may be described herein as being performed by specific components, devices and / or modules. In other embodiments, such operations, techniques, features and / or functions may be performed by different components, devices or modules. Therefore, in other embodiments, some operations, techniques, features and / or functions described herein as being attributed to one or more components, devices or modules may be attributed to other components, devices and / or modules, even if not specifically described in this manner herein.

[0266] Although specific advantages have been identified in conjunction with the description of some embodiments, various other embodiments may include some, none, or all of the enumerated advantages. Other advantages, technical or otherwise, may become apparent to those of ordinary skill in the art through this disclosure. Additionally, although specific embodiments have been disclosed herein, any number of techniques may be used to implement various aspects of the disclosure, whether currently known or not, and therefore, the disclosure is not limited to the embodiments specifically described and / or illustrated in this disclosure.

[0267] In one or more embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a computer-readable medium and / or transmitted via a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium corresponding to a tangible medium such as a data storage medium, or a communication medium including any medium (e.g., according to a communication protocol) that facilitates the transfer of a computer program from one place to another. In this manner, a computer-readable medium may generally correspond to (1) a non-temporary tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0268] As an example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM or optical disk storage, disk storage or other magnetic storage devices, flash memory or any other medium that can be used to store the required program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection can be appropriately referred to as a computer-readable medium. For example, if a wired (e.g., coaxial cable, fiber optic cable, twisted pair) or wireless (e.g., infrared, radio and microwave) connection is used to transmit instructions from a website, server or other remote source, the wired or wireless connection is included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals or other transient media, but refer to non-transient tangible storage media.

[0269] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the terms "processor" or "processing circuitry" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the described techniques, respectively. In addition, in some embodiments, the described functionality may be provided within dedicated hardware and / or software modules. Furthermore, these techniques may be fully implemented in one or more circuits or logic elements.

[0270] The techniques of the present disclosure may be implemented in a variety of devices or apparatuses, including wireless handsets, mobile or non-mobile computing devices, wearable or non-wearable computing devices, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require implementation by different hardware units. Instead, as described above, the various units may be combined in hardware units or provided by a collection of interoperating hardware units including one or more processors as described above in combination with appropriate software and / or firmware.

Claims

1. A method for determining trust, comprising: determining, by a computing system, a prerequisite score for a network entity in a computer network, wherein the prerequisite score is based on one or more prerequisite factors, and wherein each of the one or more prerequisite factors is a condition to be satisfied; determining, by the computing system, a subjective score for the network entity based on one or more subjective factors of the network entity, wherein each of the one or more subjective factors of the network entity corresponds to a subjective characteristic of the network entity; determining, by the computing system, a trust score for the network entity based on the prerequisite score and the subjective score; and Operation of the computer network is modified, by the computing system, based on the trust score of the network entity.

2. The method according to claim 1, wherein: Determining the subjective score includes: identifying information about a consumer of the trust score of the network entity; and The subjective score is determined further based on the consumer's information regarding the trust score of the network entity.

3. The method according to claim 1, wherein: Determining the subjective score includes: identifying a set of weights to be applied to the one or more subjective factors; and The subjective rating is further determined based on the set of weights.

4. The method according to any one of claims 1 to 3, further comprising: A variable score for the network entity is determined by the computing system based on one or more variable factors of the network entity, wherein each of the one or more variable factors of the network entity corresponds to a current characteristic of the network entity.

5. The method according to claim 4, wherein: Determining the trust score includes: The trust score is further determined based on the variable score.

6. The method according to any one of claims 1 to 3, further comprising: A reputation score for the network entity is determined by the computing system based on one or more reputation factors of the network entity, wherein each of the one or more reputation factors of the network entity corresponds to a current characteristic of the network entity.

7. The method according to claim 6, wherein: Determining the trust score includes: The trust score is further determined based on the reputation score.

8. The method according to any one of claims 1 to 3, wherein: Determining the trust score includes: identifying a trust scoring scheme from a plurality of trust scoring schemes associated with the network entity; and The trust score is determined further based on the trust scoring scheme.

9. The method according to any one of claims 1 to 3, wherein: Determining the trust score includes: The trust score is determined based on the one or more precondition factors, wherein each of the one or more precondition factors must be satisfied in order for the trust score to be other than a minimum value.

10. The method according to any one of claims 1 to 3, wherein: Determining the trust score includes: determining a level of trust that another network entity has in the network entity; and The trust score is determined further based on the level of trust that the other network entity has in the network entity.

11. The method according to any one of claims 1 to 2, wherein: The subjective score is a first subjective score, wherein the first subjective score is calculated based on a first set of weights applied to the one or more subjective factors, the first set of weights being associated with a first consumer of the trust score, and wherein the trust score is a first trust score, the method further comprising: determining, by the computing system, a second subjective score for the network entity based on a second set of weights applied to one or more objective factors, the second set of weights being associated with a second consumer of the trust score; A second trust score for the network entity is determined by the computing system based on the second subjective score.

12. The method according to claim 11, in, Modifying the operation of the computer network includes enabling the network entity to process network traffic.

13. The method according to claim 12, further comprising: Operation of the computer network is modified, by the computing system, based on the second trust score to route traffic away from the network entity.

14. A system for determining trust, the system comprising a processing circuit and a storage device, wherein: The processing circuit has access to the storage device and is configured to: determining a prerequisite score for a network entity in a computer network, wherein the prerequisite score is based on one or more prerequisite factors, and wherein each of the one or more prerequisite factors is a condition to be satisfied; determining a subjective score for the network entity based on one or more subjective factors for the network entity, wherein each of the one or more subjective factors for the network entity corresponds to a subjective characteristic of the network entity; determining a trust score for the network entity based on the prerequisite score and the subjective score; and Operation of the computer network is modified based on the trust score of the network entity.

15. The system of claim 14, wherein: To determine the subjective rating, the processing circuit is further configured to: identifying information about a consumer of the trust score of the network entity; and The subjective score is determined further based on the consumer's information regarding the trust score of the network entity.

16. The system of claim 14, wherein: To determine the subjective rating, the processing circuit is further configured to: identifying a set of weights to be applied to the one or more subjective factors; and The subjective rating is further determined based on the set of weights.

17. A system according to any one of claims 14 to 16, wherein: The processing circuit is further configured to: A variable score for the network entity is determined based on one or more variable factors for the network entity, wherein each of the one or more variable factors for the network entity corresponds to a current characteristic of the network entity.

18. The system of claim 17, wherein: To determine the trust score, the processing circuit is further configured to: The trust score is further determined based on the variable score.

19. The system of claim 18, wherein: The processing circuit is further configured to: A reputation score for the network entity is determined based on one or more reputation factors for the network entity, wherein each of the one or more reputation factors for the network entity corresponds to a current characteristic of the network entity.

20. A computer readable medium encoded with instructions for causing one or more programmable processors to perform the method of any one of claims 1 to 13.

Images