Enriching exposed credential search results to make them executable

Abstract

Techniques are disclosed for (i) identifying a resource accessible using an exposed credential using contextual information associated with the exposed credential, (ii) identifying a responsible entity of the resource, and (iii) alerting the responsible entity to the exposed credential. The credential is determined to be in an exposed state. If the exposed credentials are used, access to the resource may potentially be provided to the actor despite the fact that the actor should not have access to the resource. The exposed credentials are analyzed to determine a context. Based on the context, a resource is identified. A responsible entity associated with the resource is identified. A warning is then sent to the entity.

Description

Background Art

[0001] Plaintext secrets (e.g., unencrypted secrets) present a serious source of security risk to the data storage industry as well as other industries. In some cases, plaintext secrets may be ignored by scanning tools (e.g., static analysis scanning tools). In the case of detected exposed secrets, there is significant complexity in remediating these exposures. This complexity includes scenarios where the assumed secrets eventually become false positives. Another complexity involves detecting secrets that are expired or belong to deleted resources. If the secret is expired or belongs to a deleted resource, no remediation is required, and if remediation is performed, it is a futile effort. Another complexity is that it may be difficult to determine which entity assigned the secret so that the entity can be contacted to provide a security response. If the secret is invalidated or rotated without coordination with the actor, it may also be difficult to determine the complete set of actors that use a specific secret and will therefore be destroyed.

[0002] "Bearer token" systems are a particular source of risk. A "bearer token" is a plaintext secret that is a quasi-password. The quasi-password itself can be used to complete the authentication flow (e.g., "please provide access to the bearer of this secret"). Bearer tokens are highly performant in providing authorization for resources and are widely used throughout the industry. Because there is no identity-specific verification (e.g., no expensive cryptographic signing), this security model can be very convenient. However, the storage, retrieval, and transmission of these types of secrets should still be handled in a secure manner.

[0003] There is a trend in the industry to move away from bearer tokens in favor of dedicated identity-driven solutions such as role-based access control (RBAC) and managed service identity (MSI). These approaches address many of the risks associated with bearer tokens, but can come with greater costs both in creating and managing identities and in converting existing systems to a move away from bearer token approaches.

[0004] That said, some data store customers have expressed reluctance to move away from bearer tokens, even in the presence of RBAC / MSI driven alternatives to provide authentication. This reluctance is often due to the lack of convenience of such systems and due to assumed development inefficiencies.

[0005] Unfortunately, developers sometimes inadvertently expose secrets / credentials. In fact, it is inevitable that some secrets / credentials (e.g., bearer tokens, passwords, usernames, etc.) will be submitted to source code, documents, or some other data structure (collectively referred to as "artifacts"). This artifact may then be exported to a public repository or other Internet location, thereby providing a risk for security breaches, where unauthorized entities gain access to the secrets and then use the secrets to gain access to resources.

[0006] Exposed secrets / credentials have long been a challenge for data stores and other service providers. For example, thousands of valid application secrets are discovered in commonly used repositories every month. Sometimes, customers are unaware of the exposure. When a secret is discovered, it is often difficult to determine who should be notified about the exposed secret. Therefore, what is needed is an improved technique for determining who should be notified when a scenario involving exposed credentials occurs.

[0007] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is merely provided to illustrate one exemplary technology area in which some embodiments described herein may be practiced. Summary of the invention

[0008] Embodiments disclosed herein relate to systems, devices, and methods for (i) using contextual information associated with exposed credentials to identify resources that can be accessed using the exposed credentials, (ii) identifying the responsible entity for the resources, and (iii) alerting the responsible entity to the exposed credentials.

[0009] Some embodiments identify credentials within an artifact. An embodiment determines that the credential is in an exposed state. As a result, the credential is an "exposed" credential. The exposed credential can potentially provide access to a resource if used. An embodiment analyzes the exposed credential and / or artifact to determine a "context" for the exposed credential. Based on the context, a specific resource is identified. An embodiment then determines the responsible entity for the resource. An embodiment also triggers the transmission of an alert. The alert includes information detailing the circumstances surrounding the exposed credential.

[0010] To identify the responsible entity, some embodiments identify a subscription mapping associated with the resource. In such embodiments, the subscription mapping includes a subscription identification for the entity associated with the resource. Based on the subscription identification, the embodiment identifies the responsible entity.

[0011] Some embodiments identify a first credential located within a first artifact. It is determined that the first credential is in an exposed state. If used, the first exposed credential can potentially provide access to a resource. An embodiment analyzes the first exposed credential and / or the first artifact to determine a context. Based on the context, a resource is identified. An embodiment also determines a responsible entity for the resource. An embodiment then triggers transmission of a warning to the responsible entity. The warning includes information detailing how the first exposed credential is in an exposed state. Additionally, an embodiment determines a first characteristic of the first exposed credential. A relationship between the first characteristic of the first exposed credential and the resource is established. An embodiment stores an indication of the relationship in a data source. Advantageously, the indication is searchable. An embodiment identifies a second exposed credential having a second characteristic similar to the first characteristic. Based on the similarity, an inference is generated, wherein the inference indicates that the second exposed credential may also be associated with the resource.

[0012] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0013] Additional features and advantages will be set forth in the following description, and in part will be clear from the description, or may be learned by practicing the teachings herein. The features and advantages of the present invention may be realized and obtained by the instruments and combinations particularly pointed out in the appended claims. The features of the present invention will become more fully clear from the following description and the appended claims, or may be learned by practicing the present invention as set forth below. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments that are illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are therefore not to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0015] Figure 1 Illustrate an example scenario where credentials are exposed.

[0016] Figure 2 Various implementations of example articles of manufacture are illustrated.

[0017] Figure 3 Various different implementations of example credentials are illustrated.

[0018] Figure 4A , Figure 4B , Figure 4C and Figure 4D An example architecture is illustrated that may be used to determine a responsible entity associated with exposed credentials.

[0019] Figure 5A , Figure 5B and Figure 5C Various flow diagrams of example methods for determining a responsible entity for exposed credentials are illustrated.

[0020] Figure 6 An example computer system configured to perform any of the disclosed operations is illustrated. DETAILED DESCRIPTION

[0021] Embodiments disclosed herein relate to systems, devices, and methods for (i) using contextual information associated with exposed credentials to identify resources that can be accessed using the exposed credentials, (ii) identifying the responsible entity for the resource (e.g., one or more entities with permissions to manage the resource), and (iii) alerting the responsible entity to the exposed credentials.

[0022] Some embodiments determine that a credential is in an exposed state. The exposed credential, if used, can potentially provide an actor with access to a resource, despite the fact that the actor should not have access to the resource. An embodiment analyzes the exposed credential and / or an artifact including the exposed credential to determine a context. Based on the context, the resource is identified. The embodiment then determines a responsible entity associated with the resource. The embodiment also triggers the transmission of an alert. The alert includes information detailing how the exposed credential is in an exposed state.

[0023] Examples of technology benefits, improvements and real-world applications

[0024] The following sections summarize some example improvements and practical applications provided by the disclosed embodiments. However, it should be understood that these are only examples, and the embodiments are not limited to only these improvements.

[0025] The disclosed embodiments bring substantial benefits, advantages, and practical applications to the technical field of data security management. Advantageously, the disclosed embodiments improve data security by providing techniques and mechanisms for quickly and efficiently identifying responsible entities that may be interested in being notified about exposed credentials. Performing the disclosed operations reduces the likelihood of security breaches.

[0026] The disclosed embodiments also help prevent possible security breaches by automating some of the remediation steps performed when secrets are exposed (e.g., identification of responsible entities), whether those secrets are client secrets, application secrets, or perhaps even developer secrets. The embodiments effectively create an automated routine for identifying responsible entities for workload identities. That is, the disclosed service attempts to remove or eliminate the need for human intervention with respect to the general process flow of identifying responsible entities. In doing so, the service significantly reduces the amount of time required to initiate the steps performed to remediate an error or leak.

[0027] The embodiments advantageously describe solutions that address all of the above problems and complexities. At a high level, the disclosed principles include techniques for improving the "identifiability" of credentials (e.g., bearer tokens, passwords, usernames, etc.) to drive false positive and false negative rates in detection to approximately 0%. The embodiments also provide automated mechanisms for identifying the responsible party for a credential, resource, or artifact. The embodiments also provide an anonymous endpoint for accepting reports of exposure. The disclosed embodiments include services that can correlate secrets with the resource providers that assigned them.

[0028] There is much substantial value in such a system. For example, the system promises to greatly reduce the literal costs associated with responding to scenarios involving leaked or exposed credentials, and will reduce the window for literal exposure of exposed secrets. Embodiments allow for a seamless merger of a bearer token model or credential model with an RBAC or MSI driven approach. In other words, bearer tokens can be allocated and used by development teams (e.g., to gain the convenience and efficiency of the approach), with the development team knowing in advance that any detection / reporting of these secrets (if they are mishandled) will result in automatic notification to the entities responsible for those secrets.

[0029] Embodiments also allow for maximum participation of the security researcher community. Reports can be completely anonymous, as the simple fact of having / carrying a secret is sufficient to claim identification of the responsible entity. "Identifiable" secrets (e.g., secrets with known patterns) also eliminate or reduce false negatives and false positives, which ensures that all activity in the system is driven by actual discoveries.

[0030] The disclosed identifiable secret model additionally allows for routing and risk assessment (using the bearer token itself). Such a model allows a single reporting endpoint to handle credentials reported for a range of resource providers (e.g., a secret distribution security model). As a result, the disclosed solution eliminates false positives and ensures that no or minimal false negatives (missed detections) occur. This solution provides a vast improvement over many of today's existing scanning capabilities.

[0031] The disclosed solution does not require the management of huge amounts of metadata to determine the resource provider that assigned the secret, the person that assigned the secret, or even all the users / dependencies that depend on the secret. The solution allows for complete anonymity in reporting, allowing the system to leverage (as an example) public security research and report to the endpoint (e.g., for secrets that may be detected in public open source repositories).

[0032] The disclosed embodiments advantageously gather sufficient contextual information from scan results (e.g., perhaps a static analysis scan) to identify resources associated with exposed or leaked credentials. Doing so enables the embodiments to make runtime calls to verify whether the identified credentials are false positives. As a specific example, if the string is indeed a token / credential, there is typically enough contextual information in the adjacent code to identify the type of token. The embodiments can then advantageously construct URLs to see if they can use the token to access the resource.

[0033] Embodiments also enable rich fingerprinting of discoveries. Embodiments advantageously construct a unique fingerprint for each credential discovery. Additional information may then be added to the fingerprint to optimize the running of subsequent leaked credential searches. For example, if the fingerprint stores an indication of the resources accessed using the credential / token, embodiments may skip the incidental step of collecting additional contextual information for dynamic verification. Instead, embodiments may attempt to directly verify the credential / token based on the resources identified in the fingerprint.

[0034] Another advantage is that embodiments are able to tag ownership information as credential discovery. Modern software development uses some form of version control for source code. Embodiments utilize version control data structures to tag credential discovery with ownership information. As an example, after the steps of searching to identify a potential token and dynamically verifying that it is indeed an exposed credential, embodiments can check who made the last commit to the file and use that as approximate ownership information for discovery. If there are additional hierarchical data structures about ownership (e.g., a tree defining the managers of the engineer who made the commit), those hierarchical data structures can also be utilized.

[0035] Thus, embodiments provide improved actionability of credential discovery results. The overall idea breaks down two important barriers that hinder the actionability of results. These barriers include the fact that people don't know if the result they are looking at is a false positive. Manually verifying this adds overhead to the development process, and developers often lose trust in the tools. Another barrier is that people don't know who to contact when a search reports a discovery. Embodiments advantageously ensure that (i) questions are routed to the right person, and (ii) people can trust that the discovery they are viewing is real. Doing so greatly improves the actionability of scan / search results.

[0036] Because there is continuous code churn in every organization, it is often the case that searches are rarely run just once. Instead, they are typically configured to run at a specific cadence. The idea of ​​enriching fingerprints ensures that information from one run optimizes the performance of subsequent runs, resulting in significant savings in computational costs. Therefore, these and many other benefits will now be described in detail in the remaining sections of this disclosure.

[0037] Example scenario involving exposed credentials

[0038] Having just described several advantages of the disclosed embodiments, attention is now directed to Figure 1 . Figure 1 An example scenario is illustrated involving the use of a client device 100. In this example, the client device 100 belongs to a code developer who is developing source code, which is an engineering artifact, or simply artifact 105A.

[0039] Briefly turn to Figure 2 , which illustrates various other examples of article 200, which represent Figure 1 Artifact 105A. Artifact 200 can take various forms. These forms include, but are not limited to, any type of source code 205, work tickets 210, build definitions 215, emails 220, or even documents 225. Ellipses 230 illustrate how other data structures can be included in artifact 200. For example, the data structure may include other data structures associated with the build definition, such as possibly an automation artifact that includes (i) an automation script, descriptor, or other artifact that configures or otherwise drives the automation behavior, and (ii) automation output including logs or compilation output. The data structure may also include workflow artifacts. The data structure may include any type of source-controlled artifact, which may include source code 205 or any other artifact included in a data source.

[0040] Back to Figure 1 , artifact 105A is shown in the form of source code. At least two exposed credentials are embedded in the source code, as shown by exposed credentials 110 and exposed credentials 115. Exposed credentials 110 (also known as secrets) are shown as usernames, and exposed credentials 115 are shown as passwords. Figure 3 Provides some additional details about the various different types of exposed credentials.

[0041] Figure 3 An exposed credential 300 is shown, which indicates Figure 1In various embodiments, the exposed credential 300 may be in the form of a bearer token 305, an identity 310 (e.g., a username, a GUID, a sensitive identifier designator, or some other name), or a password 315. Ellipses 320 illustrate how other data structures may be designated as exposed credentials 300. For example, an exposed credential may be a certificate (e.g., an assigned data bundle assigned by an authority), a private key (e.g., a mathematically static value used for cryptographic purposes), a static credential repository (e.g., a credential bundle persisted for archiving, such as an archived copy of a password or a set of checked-in credentials), a container for multiple artifacts, or even compressed data. As some additional examples, it may be the case that a computer port is an exposed credential; an Internet Protocol (IP) address is an exposed credential; any type of token may be an exposed credential, and so forth.

[0042] In some implementations, an embodiment can identify a data structure as a credential based on a detected pattern 325 of the data structure. For example, an embodiment can cause a credential to include an embedded signature 330. Some credentials may include an embedded or associated checksum 335. An embodiment can scan and analyze a data source (e.g., a persistent artifact repository or a persistent data repository) that may include a credential to detect the credential based on its pattern. An embodiment can determine that the data structure is a credential if the pattern matches a known pattern that is linked or associated with a pattern known to belong to a credential. Therefore, the pattern can optionally be based on one or a combination of the signature 330 and / or the checksum 335. In some implementations, the credential can take a variety of forms. For example, the credential can be formatted as a 256-bit base64 encoded string.

[0043] With respect to signature 330, a fixed signature sometimes referred to as a "magic value" may be used. The fixed signature may be a constant numeric or text value that is persistently stored in a known location within the data stream to represent its format. This mechanism can be used to effectively eliminate a significant percentage of false positives via regular expression matching. Such practice is advantageous because constant values ​​can be expressed in the token / credential itself. If carefully designed, the process can allow 100% recall (i.e., 100% true positive retrieval) via simple (regular expression) pattern matching. This avoids the cost of performing additional runtime processing.

[0044] Regarding checksum 335, the checksum provides a known pattern for ensuring data integrity. The secret provider can reserve bytes within the secret to store the calculated checksum of the remaining data. Advantageously, a single security provider can uniquely identify their own secrets (e.g., within an otherwise shared format) by XORing the checksum with a known, stable "magic value." Because the checksum is distributed across its entire range of values ​​(i.e., a 32-bit checksum will distribute all possible inputs across 2^32 possible checksums), this greatly reduces the possibility of conflicts with different data generators.

[0045] In some embodiments, 8 to 10 characters are retained in each generated secret, token, or credential. These characters are retained to represent a fixed signature and a checksum (or a partial checksum). Optionally, the last 4 to 6 characters of the secret token are retained to hold the encoded checksum of the remainder of the secret. The checksum may include the fixed signature in its processing when it is generated.

[0046] Optionally, each resource provider may be tasked with defining a unique checksum seed that appropriately categorizes the generated secrets. For example, the generated keys provided to customers may use a different checksum seed than the code path that generates the keys used to encrypt customer data (which is entirely managed by the resource provider). For base64 encoded secrets, the checksum may be saved in the last byte of the decoded secret. For secrets distributed from a custom character set, the checksum may be encoded using that character set and appended to the remainder of the secret.

[0047] Different seed / secret classes can be versioned simply by incrementing the first assigned seed value (or by incrementing the value in the string literal used to generate the seed). The secret can include a four-character fixed signature that is saved immediately before the checksum.

[0048] In addition to or as an alternative to signatures and checksums, other techniques can be used to provide detectable patterns for credentials. For example, "hashcash" can be used. Hashcash is a proof-of-work algorithm that requires enough calculations to generate data that conforms to a highly recognizable pattern when hashed (e.g., such as by having a certain number of leading zeros). The technology works by first generating a secret that meets the length or other criteria. Then any data is appended to the secret until the hash of the candidate data has a recognizable signature (e.g., such as three leading zeros in the hash value). Once the correct additional data (e.g., "random number") is found, all of it (e.g., the original secret plus the random number that together results in a recognizable signature when hashed) is returned and acts as a secret. The technology provides a secret / password that is easily identified. The scanner can perform preliminary detection, and then all findings can be hashed to find an identifiable pattern in the hash. Detections that do not meet the hash pattern criteria are discarded as false positives. Therefore, there are various techniques for configuring secrets to have known patterns.

[0049] Return to Figure 1 , a user of the client device is currently developing source code. In this example, the user has decided to check his / her code into a data source for safekeeping or possibly for peer review. Figure 1 A scenario is shown in which client device 100 is connected to network 120 and in which artifact 105B, representing artifact 105A, is shown uploaded or checked into data source 125. Note that artifact 105B is shown to include exposed credential 110B, which represents one of exposed credentials 110 or 115.

[0050] In this scenario, data source 125 is a publicly accessible data source. Note that unauthorized entity 130 is shown as now having access to exposed credentials 110B. If the exposed credentials 110B are accessed by unauthorized entity 130, the entity can then potentially use the credentials to access resources that the entity would not otherwise be allowed to access. A "resource" can be any type of resource. Examples of resources include, but are not limited to, applications, services, executable files, or any other type of data structure that uses or relies on credential information.

[0051] therefore, Figure 1 An example scenario that may lead to a security breach is shown. The disclosed embodiments are advantageously tailored to remedy such scenarios and prevent the possibility of a security breach.

[0052] Example Architecture

[0053] Now turn your attention to Figure 4A, which illustrates an example architecture 400 that can be used to identify a responsible entity associated with exposed credentials. The architecture 400 is shown to include an analysis service 405.

[0054] In various embodiments, the analysis service 405 is a cloud service operating in a cloud environment. In other embodiments, the analysis service 405 is a local service operating on a local device. In still other embodiments, the analysis service 405 is a hybrid service that can operate both in the cloud and on a local device.

[0055] In some cases, the analysis service 405 is or includes a machine learning engine. As used herein, references to any type of machine learning may include any type of machine learning algorithm or device, (multiple) convolutional neural networks, (multiple) multi-layer neural networks, (multiple) recursive neural networks, (multiple) deep neural networks, (multiple) decision tree models (e.g., decision trees, random forests, and gradient boosted trees), (multiple) linear regression models, (multiple) logistic regression models, (multiple) support vector machines ("SVM"), (multiple) artificial intelligence devices, or any other type of intelligent computing system. Any amount of training data may be used (and possibly refined later) to train the machine learning algorithm to dynamically perform the disclosed operations.

[0056] Analysis service 405 operates in conjunction with scanning service 410. In some implementations, scanning service 410 is an integrated part of analysis service 405. In other implementations, scanning service 410 is distinct from analysis service 405. Alternatively, scanning service 410 may even be a third-party service.

[0057] In any case, the task of scanning service 410 is to scan (e.g., as shown by scanning 415) data source 420 or any data stream. Data source 420 can be any type of data source. In some instances, the data source is a controlled data source that restricts access to only authorized individuals with a security authorization threshold level. In some implementations, data source 420 is a publicly accessible data source with no or minimal security requirements to access data source 420. In some cases, data source 420 is controlled by an enterprise, but it is still generally accessible to entities associated with the enterprise. In any case, data source 420 is a data source whose access availability 420A (e.g., the option that enables an entity to access data source 420) does not meet the restricted access threshold 420B regarding credentials and / or resources. This generally means that the content uploaded or checked into the data source should be (but sometimes is not) content that will not present the possibility of potential security vulnerabilities for unauthorized entities. However, as previously mentioned, this is not always the case. In other words, it may be the case that confidential credential information has been inadvertently uploaded into data source 420 , and entities that do not have sufficient authorization to access a resource may otherwise access it because they now have access to the credentials for that resource via data source 420 .

[0058] exist Figure 4A In the invention, article 425 (e.g., Figure 2 Any of the artifacts 200) has been uploaded or checked into the data source 420. In this example, Figure 1 Similar to the scenario described in , artifact 425 is shown as including exposed credentials 430.

[0059] According to the disclosed principles, embodiments can scan data sources 420 and detect exposed credentials 430. Machine learning can be performed to detect credentials 430. In some cases, as previously described, credentials 430 can be detected based on patterns detected thereof.

[0060] Analysis service 405 obtains or accesses the now suspected potentially exposed credential 435, which represents the exposed credential 430. Optionally, instead of obtaining the actual credential, analysis service 405 obtains information describing the credential. Such information may include a specific location where the exposed credential 430 is located, such as its memory location or perhaps its location within the work-in-progress 425.

[0061] In some implementations, additional or alternative reporting data 445A may be provided to the analysis service 405. For example, a separate entity 445B (e.g., perhaps an external third-party service) or perhaps even a human may detect the presence of exposed credentials in a data source. The separate entity 445B may be an anonymous endpoint, a trusted entity, or even an internal enterprise entity. These entities may report their findings in the form of reporting data 445A, and may provide the reporting data 445A to the analysis service 405. Thus, in some scenarios, the scanning service 410 detects the presence of exposed credentials 430 and provides it to the analysis service 405, while in other scenarios, the exposed credentials 430 are detected by some other entity and reported to the analysis service 405 in the form of reporting data 445A. As such, the exposed credentials 430 may even be reported by an anonymous entity.

[0062] Receipt of report data 445A may trigger an embodiment to perform validation on report data 445A in an attempt to reduce or eliminate false positives regarding identifying exposed credentials. In some instances, receiving report data 445A may trigger scanning service 410 to scan and analyze any data sources identified by report data 445A in an attempt to identify not only potentially exposed credentials (as identified in report data 445A) but potentially other potentially exposed credentials in the data sources. Thus, receiving report data 445A may trigger identification of suspected exposed credentials 435, which may be identified via other techniques besides scanning service 410 (e.g., it may be identified via report data 445A).

[0063] In response to accessing the report data, an embodiment may perform one or more various actions. For example, an embodiment may filter the report data to determine the accuracy associated with the report data (e.g., whether the report data accurately identifies exposed credentials or an artifact containing exposed credentials). In other words, an embodiment may perform an evaluation on the data in an attempt to filter out false positives. Another action includes obtaining one or more artifacts pointed to by the report data and subjecting those artifacts to review or scanning. In some cases, an artifact including potentially exposed credentials may be accessed, downloaded, or otherwise contacted. An embodiment may then trigger a review of the artifact in an attempt to verify the authenticity of the report data.

[0064] In addition to accessing the exposed credentials 430, the analysis service 405 is also able to obtain the context 440 associated with the exposed credentials 430. As used herein, the term "context" can refer to any type of metadata associated with the exposed credentials 430, any type of container or data structure associated with the exposed credentials 430, and / or any other information inside or possibly outside the exposed credentials 430, where the information can provide clues or indications about what resources, subscriptions, or entities are associated with the exposed credentials 430. In some cases, the context includes historical information associated with the exposed credentials. For example, the historical information may include the duration that the exposed credentials have been in an exposed state. Typically, it is less complex to identify the responsible entity for newly exposed or recently exposed credentials. As the time that the credentials are exposed increases, it is usually more difficult to identify the responsible entity. Providing historical data can help identify the responsible entity and can optionally help set priorities for the search.

[0065] An example will be helpful. Assume that artifact 425 is source code, and that the source code includes exposed credentials 430. Analysis service 405 is able to scan the source code and determine various internal characteristics of exposed credentials 430 in an effort to determine context 440 of exposed credentials 430. As an example, it may be the case that the source code includes the name of a server that uses the source code; or it may be the case that the source code identifies a specific service that uses the source code; or it may be the case that the source code identifies a subscription. Such information may be used to identify which entity is ultimately responsible for the exposed credentials. In addition, such information may be included in context 440. Thus, context 440 for exposed credentials 430 may be obtained directly from the exposed credentials 430 themselves (e.g., such as embedded metadata that may be in exposed credentials 430) and / or context 440 may be derived from a document, file, or other data structure that is external to the exposed credentials 430 or may include the exposed credentials (e.g., source code that includes the credentials).

[0066] By way of additional illustration, context may be determined via a discovery process involving one or more of: reviewing the artifact itself; reviewing the nested artifact set that includes the above artifact; or even consulting the security model. The example of a "nested artifact set" is warranted.

[0067] An example of a nested set of artifacts may include a database included in a zip file that is part of a storage repository managed by a cloud service. These various artifacts may all depend on each other. If the database were to include exposed credentials and if other artifacts depend on the database, context may be obtained by analyzing not only the database itself but also the other artifacts.

[0068] Thus, an artifact may optionally be stored within another artifact, such as in a nested condition. An embodiment is able to provide or obtain contextual information about the entire chain of corresponding artifacts. An embodiment is also able to determine the responsible entity for each of those various artifacts. An embodiment may also build routing details to discover the most obvious entity to alert.

[0069] Additionally, an escalation path for feedback may be generated.If a resource fails, an embodiment may notify the responsible entity that it should take action.

[0070] From this, it can be discerned how there may be multiple chains of responsibility, where those chains include identifying and alerting entities about the source of exposure, and where those chains include identifying and alerting entities about the compromised resources themselves. If certain entities cannot be located, alert escalation may occur, and entities throughout the organization may be notified.

[0071] Building on the previous discussion, in some cases, context is determined based on one or more of: (i) identifying keywords in other artifacts that may be globally persisted or may be in a nested relationship with the credential; or (ii) identifying the security model of the credential and communicating with the allocator to obtain the context. Embodiments may also attempt to elaborate on the content provided, such as by estimating or inferring variations of the exposed credential, which will be discussed later.

[0072] An embodiment may consult a security model, which may be asked to provide information for searching other context items. As an example, an embodiment may ask a domain controller to provide all usernames it manages. An embodiment may also communicate directly with the security model to obtain other private information. Based on the context 440 associated with the exposed credentials 430, the analysis service 405 identifies a resource 450 associated with at least one of the artifact 425 or the exposed credentials 430. For example, the context 440 may identify a machine, service, application, path, URL, website, database, file, person, or some other identifying information associated with the exposed credentials 430.

[0073] In some implementations, the analysis service 405 reviews the exposed credential 430 to confirm that it is actually a credential that can be used to access the resource 450. Determining whether the exposed credential 430 can actually be used to access the resource 450 can be referred to as determining the liveness 450A of the exposed credential 430. For clarity, liveness 450A refers to the ability of the exposed credential to actually access the resource 450. If the credential can be used to access the resource 450, the liveness of the credential can be referred to as being in a "live" state. On the other hand, if the credential cannot be used to access the resource 450 (e.g., it is invalid), the liveness of the credential can be referred to as being in a "dead" state.

[0074] The process of determining the liveness of a credential 450A may be performed in a number of different ways.

[0075] For example, analysis service 405 may query resource 450 to ask whether resource 450 can use the credentials to gain access to resource 450. Resource 450 may then provide a response based on the query, and the response may be yes or no. In another scenario, analysis service 405 may actually attempt to use exposed credentials 430 to access resource 450. If the attempt is successful, analysis service 405 will know that the credentials are valid.

[0076] In yet another scenario, analysis service 405 can query a security service model associated with resource 450. For example, assume that resource 450 is a SQL database. The SQL database can be managed by a SQL server or service. Analysis service 405 can query the SQL service to determine whether exposed credentials 430 can be used to access the SQL database.

[0077] If analysis service 405 discovers that exposed credentials 430 represent credentials but that they cannot be used to access any resources, analysis service 405 can determine that no harm will come from exposed credentials 430 being left in data source 420. In this scenario, analysis service 405 can avoid performing any further inquiries to determine the responsible entity. In some scenarios, analysis service 405 can continue to attempt to identify the responsible entity, such that an instructive message can be provided to indicate that bad techniques may be used when allowing credentials to be exposed.

[0078] In an alternative scenario, analysis service 405 may determine that exposed credentials 430, if used, would provide access to resource 450, and potential damage may come from exposed credentials 430 being left in data source 420. In this scenario, analysis service 405 may proceed with additional operations to attempt to identify the responsible entity.

[0079] In some scenarios, an embodiment may generate one or more variations of exposed credential 430, and then test those variations against resource 450 to see if those variations can be used to access resource 450. As an example, assume the credential is the following password: "Duke2021". An embodiment may generate variations of the password based on characteristics or patterns of the password. For example, in this scenario, the password appears to include a year. An embodiment may generate a password such as "Duke2022" and then attempt to access resource 450 using that password. Machine learning may be implemented to generate a variety of different variations.

[0080] In one implementation, the analysis service 405 may query the resource 450 to attempt to identify an administrator 455 of the resource 450 (e.g., the responsible entity may be an entity that manages the resource, and the entity may be an administrator of the resource). For example, the resource 450 may have or may provide access to information identifying the responsible entity for managing the resource. As a result, in some instances, the resource 450 may provide identification information to enable the analysis service 405 to identify the responsible entity associated with the resource 450, and the responsible entity will also likely be responsible for the artifact 425 (which the resource 450 is using). The responsible entity is shown as the administrator 455. The analysis service 405 may then trigger the transmission of the warning 460. Optionally, the warning may be transmitted to the responsible entity (e.g., an administrator). The warning 460 may include information detailing how the exposed credential 430 is in an exposed state. In some cases, the details in the warning may include: information describing the characteristics of the exposed credential itself; information describing the security model associated with the exposed credential; information about where the exposed credential was found, who or what found the credential; or even information about what steps can be performed to invalidate the exposed credential (e.g., steps for remediation). In some cases, the details may include information about the relationship between the credential and the assumed responsible entity. The alert may be sent to the responsible entity, a security champion, or some other entity. Possibly, the alert may also detail the location of the artifact containing the credential and steps on how to invalidate the artifact.

[0081] In some cases, the process of determining the responsible entity (e.g., administrator 455) that manages a resource may be performed by querying a metadata repository associated with resource 450. The metadata repository may include registration information that links the responsible entity to the resource.

[0082] In some implementations, determining the responsible entity can be based on utilizing the credentials to perform additional discovery by consulting a service using the credentials to build information about the responsible entity. It can also be based on using the credentials to communicate directly with the security model to obtain information about the responsible entity. Additionally or alternatively, it can be based on analyzing telemetry data associated with at least one of the artifact, the credentials, or the resource.

[0083] Some embodiments identify resources and / or determine responsible entities based on telemetry data associated with at least one of an artifact, a credential, or a resource. The telemetry data may include usage data, creation data, access data, or any other type of data for those data structures.

[0084] Figure 4BSlight variations are shown. In some instances, a resource 450 may be associated with a specific subscription mapping 465, such as perhaps a billing subscription or perhaps even a notification subscription. In other words, it may be the case that the resource is a cloud service operating in a cloud environment, and the subscription mapping is a billing subscription for the cloud service. Beyond that, a resource may be a local application, a database management resource, an on-premises resource, an identity, or even a certificate issued by an authority.

[0085] In this scenario, analysis service 405 is able to identify subscription mapping 465 for resource 450. Subscription mapping 465 links resource 450 to a specific entity responsible for subscriptions and resource 450. That is, subscription mapping 465 includes a subscription identification for an entity associated with a resource. Resource 450 may include information or may have access to information to identify subscription mapping 465.

[0086] As an example, assume that the subscription is a billing subscription. Here, resource 450 may include a link or other indicator to a subscription map that identifies which entity is responsible for billing aspects related to resource 450. Analysis service 405 is able to access subscription map 465. Subscription map 465 will then identify administrator 455 associated with resource 450. Because resource 450 uses or is associated with artifact 425, and because exposed credentials 430 are included in artifact 425, analysis service 405 may then infer that administrator 455 is at least partially responsible for exposed credentials 430, or more precisely, it would be advantageous to notify administrator 455 of the exposed credentials 430 and the possibility of a security breach.

[0087] In some implementations, resource 450 may be associated with a secret manager or credential store. The task of the credential store is to manage keys, secrets, or credentials for resource 450. It may be the case that the credential store also includes information detailing who may be the responsible entity for resource 450. As a result, analysis service 405 may optionally query the credential store to attempt to identify administrator 455.

[0088] In some implementations, resource 450 can be associated with a security service model. A security service model can be a centralized model directed to managing security operations for resources under its scope, potentially including resource 450.

[0089] As an example, assume that resource 450 is a SQL database. The security service model may be a SQL server or a service whose task is to specifically manage security operations for SQL databases. In this scenario, analysis service 405 may attempt to identify the security service model. After identifying the model, analysis service 405 may then query the model to attempt to identify which entity is responsible for resource 450. The identified entity may then be notified about the exposed credentials 430.

[0090] After the responsible entity is identified, some embodiments maintain a log of this information so that subsequent searches can consult the log in an attempt to reduce the number of steps for the interrogation process. Figure 4C is illustrative.

[0091] Figure 4C 4 shows how the analysis service 405 may maintain a data source 470. The data source 470 is shown to include various credential characteristics 470A associated with the exposed credentials 430. These characteristics may be of any type. Such characteristics may include, but are not limited to, the creation time of the credential, the storage location of the credential, the credential type, the data structure of the credential, the signature or checksum characteristics of the credential, the length of the credential, the mode of the credential, or even the date when the credential was checked into the data source 420. Other characteristics may also be stored in the data source 470.

[0092] Data source 470 is also shown to include an indicator for resource 450 (e.g., resource pointer 470B), where the indicator points to or identifies resource 450 determined to be associated with exposed credential 430. That is, data source 470 may not store the actual resource itself, but rather data source 470 may store identification information for the resource so that the resource can be linked to credential property 470A. Resource point 470B represents the identification information for the resource.

[0093] The data source 470 also includes a link 470C or shows the relationship between the credential properties 470A and the resource pointer 470B. In this way, various credential properties can be linked to specific resources. Advantageously, the content of the data source 470 is searchable.

[0094] The next time an exposed credential is detected, analysis service 405 can determine various attributes / characteristics of the credential. Analysis service 405 can then use those attributes as query parameters to search within data source 470 to try to find another credential that was previously detected and has similar characteristics. The characteristics do not have to be exactly the same; instead, the level of similarity between the characteristics of the previously detected credential and the characteristics of the new credential can be determined to meet or exceed a similarity threshold. If the threshold is met, then analysis service 405 can infer that the resource associated with the previously detected credential is likely the same resource for the new credential, and that the same responsible entity for the previously detected credential is likely the same responsible entity for the current credential.

[0095] As a result, the analysis service 405 can trigger an alert to those same entities to notify them about the new credential. Therefore, some embodiments employ a rich data source 470 that includes the results of previous queries and relationships. It will be appreciated how using this data source 470 can significantly improve the search process because the data source 470 persistently builds a corpus of relationships and knowledge that can be used for future searches. This process can be viewed as a feedback loop that continuously builds a knowledge base. The knowledge base is searchable and can be used to help facilitate subsequent queries.

[0096] Figure 4D A scenario is shown in which an analysis service 405 can obtain characteristics and context about an exposed credential 430. The analysis service can then use this information as a parameter in a query 475 to scan data sources in an attempt to discover other credentials with similar characteristics. For clarity, the search parameters can include characteristics and context 440 about the exposed credential. By way of further clarification, credential characteristics 470A can include internal characteristics of the exposed credential as well as the context of the credential.

[0097] If sufficiently similar credentials are found in the data source (eg, credentials whose similarity based on a characteristic meets or exceeds a similarity threshold), the analysis service 405 can identify the resource. The analysis service 405 can then trigger the transmission of an alert to the resource.

[0098] Example Method

[0099] The following discussion now relates to a number of methods and method actions that may be performed. Although method actions may be discussed in a particular order or illustrated in a flowchart as occurring in a particular order, a particular order is not required unless specifically stated, or because an action depends on another action being completed before the action is performed.

[0100] Now turn your attention to Figure 5A , Figure 5A A flow chart of an example method 500 is illustrated for (i) using context information associated with exposed credentials to identify a resource that can be accessed using the exposed credentials, (ii) identifying a responsible entity for the resource, and (iii) alerting the responsible entity to the exposed credentials. The method 500 may be performed at Figures 4A to 4D In addition, the method 500 can be implemented by the analysis service 405.

[0101] Method 500 includes an act of identifying a credential located within the article (act 505). This identification process can be performed by scanning a data source for data structures that may be credential. For example, from Figure 4AThe scanning service 410 can scan the data source 420. The scanning parameters can optionally include known patterns that the credentials have.

[0102] In other words, the process of identifying credentials located within an artifact may include multiple steps. One step involves scanning a data source that includes the artifact. Another step involves identifying a suspicious credential that is suspected of being an exposed credential, which, if used, can potentially provide unauthorized entity access to a resource. Yet another step includes determining a characteristic of the suspicious credential. Optionally, the characteristic includes a detected pattern associated with the suspicious credential. Based on the determined characteristic of the suspicious credential, another step includes determining that the suspicious credential is an exposed credential.

[0103] Additionally or alternatively, reporting data may be accessed, wherein the reporting data includes an indication of the exposed credentials. In some implementations, based on the detected pattern associated with the credential, the credential is identified as an authorized credential (i.e., a credential that provides authorization to the bearer of the credential to access a resource).

[0104] Action 510 includes determining that the credential is in an exposed state. As a result, the credential is an "exposed" credential. If used, the exposed credential can potentially provide unauthorized entity access to the resource. In some embodiments, determining that the credential is in an exposed state includes determining the access availability of the data source storing the credential. If the access availability is lower than the access threshold for at least one of the credential, the artifact, or possibly the resource, the embodiment determines that the credential is in an exposed state. As an example, assume that the artifact and the credential are stored in a publicly accessible data source. If the resource is a private resource, public access should not be allowed. However, in this case, the credential is publicly available. Such a scenario can enable a malicious actor to use the credential to improperly obtain access to the resource. Therefore, this example describes a scenario where the access availability of a public data source does not meet (i.e., fails) an access requirement or threshold (e.g., an access requirement threshold) established by the resource (e.g., because the resource should not be accessed by anyone in the public).

[0105] To avoid possible security vulnerabilities, the task of an embodiment is to attempt to identify a responsible party or entity associated with the exposed credentials. The responsible party may be responsible for the artifact where the exposed credentials are located. Additionally or alternatively, the responsible party may be responsible for resources that depend on the artifact or are otherwise associated with the exposed credentials.

[0106] Action 515 includes analyzing one or more of the exposed credentials or artifacts to determine a context associated with the exposed credentials. The context may include internal context obtained directly from the exposed credentials, such as metadata associated with the credentials, the schema of the credentials, etc. The context may include external context obtained indirectly from the exposed credentials, such as details within a data structure that includes the credentials, the storage location of the credentials, or even an access, creation, or upload timestamp of the credentials. In some cases, the context includes one or more of the following: metadata associated with the exposed credentials or artifacts; identifying keywords included in the artifacts; or a file path associated with at least one of the exposed credentials, artifacts, or resources.

[0107] Based on the context associated with the exposed credentials, action 520 includes identifying the resource. Action 525 then includes determining a responsible entity that manages the resource or is associated with the resource. Finally, action 530 includes triggering transmission of an alert to the responsible entity. The alert includes information detailing how the exposed credentials are in an exposed state.

[0108] In some implementations, the method may also include periodically querying to determine whether the exposed credentials have been invalidated. In response to determining that the exposed credentials have not been invalidated, the method may include an action of providing an increased warning or at least a subsequent warning. For example, the increased or subsequent warning may be sent to a superior or manager of the identified entity. In some cases, the increased warning may include warnings sent to multiple different groups, individuals, or administrators.

[0109] In response to determining that the exposed credentials have been invalidated, an embodiment may complete actions related to the remediation of the exposed credentials. For example, an embodiment may terminate an active remedial action that may be queued or active with respect to the exposed credentials. An embodiment may terminate any active investigation related to the exposed credentials. An embodiment may also terminate, cancel, or delete warnings. Completion actions may also include participation in various other activities. For example, an embodiment may reduce or adjust the severity of a warning that has been sent. An embodiment may contribute telemetry or other signal data to a dashboard. An embodiment may report tracking data on unresolved issues and / or otherwise drive to complete ongoing investigations and release resolution activities. An embodiment may close an open ticket associated with the exposed credentials. An embodiment may also send an affirmative signal to a responsible entity to indicate that the exposed credentials have been invalidated (e.g., remediation is complete).

[0110] Optionally, after the resource has been identified, the method may include an action to determine whether the exposed credentials can actually provide access to the resource. For example, an embodiment may attempt to use the credentials to access the resource.

[0111] In some cases, the exposed credential is a password. In such a scenario, the method may also include determining that the password (in its current form) cannot be used to access the resource. That is, an embodiment may determine a characteristic of the password, such as that the password has a recognizable pattern. Based on the characteristic of the password (e.g., perhaps its recognizable pattern), an embodiment may generate one or more variations of the password. An embodiment may then attempt to access the resource using the one or more variations of the password. Examples will be helpful.

[0112] Assume that the detected password is "Egghead1234". An embodiment may attempt to access a resource using that password. It may be the case that the password is invalid. However, that being said, an embodiment may detect a pattern in the password. Here, it appears as if the password was generated by appending additional numbers to the end, the next number may be "5". An embodiment may then generate the following password: "Egghead12345" and attempt to access a resource using that password. In some cases, multiple variations may be generated and tested, such as perhaps "Egghead123456", "Egghead1234567", or perhaps even "Egghead1234A". In some cases, a machine learning algorithm may be applied to the detected password to learn the pattern, and then generate password variations based on the pattern.

[0113] An embodiment may also attempt to use the password, and possibly any derived variations, in different security scenarios. For example, an embodiment may attempt to use the password to access a resource that may be of the same type as a potentially compromised resource. Examples will be helpful. In one scenario, an embodiment may attempt to use the password to access a first email platform. Additionally, an embodiment may attempt to use the same password to access a second email platform. Thus, an embodiment may identify other resources of the same resource type, and an embodiment may then attempt to use the password on those other related resources. Thus, an embodiment may attempt to use the password to access different resources, where the different resources are of the same type as the original resource. Other data structures, such as a user's username, account name, alias, etc. may also be attempted.

[0114] In some cases, action 525 may include multiple sub-steps, such as Figure 5B For example, the method may include an act of identifying a subscription mapping associated with the resource (act 525A). The subscription mapping may include a subscription identification for an entity associated with the resource.

[0115] Action 525B then includes identifying the entity for the resource based on the subscription identification.In this scenario, an embodiment consults the subscription information in an effort to identify the responsible entity.

[0116] In some cases, method 500 may include additional actions, such as Figure 5C As shown. For example, action 535 includes determining a first characteristic of the exposed credential. As an example, the first characteristic may include: a creation, upload, or access timestamp of the credential; a storage location of the credential; an author of the credential; an artifact and its characteristics, etc. In fact, any type of characteristic may be identified.

[0117] Action 540 includes establishing a relationship between the first characteristic of the exposed credential and the resource. Additionally, a relationship between the exposed credential and the entity identified earlier is also established.

[0118] Action 545 includes storing an indication of these relationships in a data source. The data source and the indication are searchable.

[0119] Action 550 then includes identifying, at a later point in time, a second exposed credential having a second characteristic. The second characteristic is determined to be similar to the first characteristic. That is, the similarity level between the two credentials meets or exceeds a predetermined similarity threshold.

[0120] Based on the second characteristic being similar to the first characteristic, action 555 includes generating an inference that the second exposed credential is also associated with the same resource. The inference also includes an indication that the same responsible entity is also likely responsible for the second exposed credential. In some implementations, a confidence metric may be generated to provide a confidence level about the likelihood that the same entity is responsible for the second exposed credential. In some cases, the confidence level may depend on a level of similarity between the two credentials. A higher level of similarity may result in an increased confidence level, while a lower level of similarity may result in a lower confidence level.

[0121] Optionally, the method may include an action of testing the second exposed credential to determine whether the second exposed credential is usable to access the resource. The action may be part of a verification process. If the second exposed credential can be used to access the resource, the confidence level that the identified entity is responsible may be increased. An embodiment may trigger transmission of an alert to the entity to notify the entity about the second exposed credential.

[0122] Thus, the disclosed embodiments are advantageously constructed or configured to identify and alert entities determined to be associated with exposed credentials. Even in scenarios where the credentials, or perhaps even the artifact housing the credentials, do not identify the entity, the embodiments are able to identify the entity. Advantageously, the embodiments are tailored to perform a variety of different investigation and discovery processes in an attempt to identify the responsible entity. In doing so, the embodiments help to significantly reduce the risk of security breaches for resources.

[0123] In other words, embodiments are able to determine who can take remedial action for compromised credentials. The technology uses features within the credentials to identify the identity of the compromised asset. Embodiments then use the identity to determine the responsible and accountable individuals who can resolve the compromise. Thereafter, embodiments notify those individuals that the credentials have been compromised and allow them to take remedial action. Embodiments can also keep checking the compromised assets to alert the responsible and accountable individuals until they resolve the issue.

[0124] Another aspect of the disclosed principles is that embodiments can determine with complete accuracy whether credentials that have been compromised are still exploitable (i.e., whether they can be used to access resources). If not, even if the credentials have been exposed, those credentials are no longer relevant and no false positive flags need to be generated.

[0125] Example Computer / Computer System

[0126] Now turn your attention to Figure 6 , which illustrates an example computer system 600 that may include and / or be used to perform any of the operations described herein. For example, the computer system 600 may be 4A to 4D The computer system 600 may be implemented within the architecture 400 of the present invention, and the computer system 600 may implement the analysis service 405. The computer system 600 may take a variety of different forms. For example, the computer system 600 may be implemented as a tablet computer, a desktop computer, a laptop computer, a mobile device, or a stand-alone device, such as those described throughout this disclosure. The computer system 600 may also be a distributed system including one or more connected computing components / devices that communicate with the computer system 600.

[0127] In its most basic configuration, computer system 600 includes a variety of different components. Figure 6 Computer system 600 is shown including one or more processors 605 (also referred to as “hardware processing units”) and storage device 610 .

[0128] With respect to processor(s) 605, it will be appreciated that the functionality described herein may be performed, at least in part, by one or more hardware logic components (e.g., processor(s) 605). For example, and without limitation, illustrative types of hardware logic components / processors that may be used include field programmable gate arrays (“FPGAs”), program-specific or application-specific integrated circuits (“ASICs”), program-specific standard products (“ASSPs”), system-on-chips (“SOCs”), complex programmable logic devices (“CPLDs”), central processing units (“CPUs”), graphics processing units (“GPUs”), or any other type of programmable hardware.

[0129] As used herein, the terms "executable module," "executable component," "component," "module," or "engine" may refer to a hardware processing unit or a software object, routine, or method that may be executed on the computer system 600. The different components, modules, engines, and services described herein may be implemented as objects or processors that execute on the computer system 600 (e.g., as separate threads).

[0130] Storage device 610 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage devices, such as physical storage media. If computer system 600 is distributed, processing, memory, and / or storage capabilities may also be distributed.

[0131] Storage device 610 is shown as including executable instructions 615. Executable instructions 615 represent instructions executable by processor(s) 605 of computer system 600 to perform disclosed operations, such as those described in the various methods.

[0132] The disclosed embodiments may include or utilize a special or general-purpose computer including computer hardware, such as one or more processors (such as, (multiple) processors 605) and system memory (such as, storage device 610), as discussed in more detail below. Embodiments also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general or special-purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are "physical computer storage media" or "hardware storage devices." In addition, computer-readable storage media including physical computer storage media and hardware storage devices exclude signals, carriers, and propagation signals. On the other hand, computer-readable media that carry computer-executable instructions are "transmission media" and include signals, carriers, and propagation signals. Therefore, by way of example and not limitation, the current embodiments may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0133] Computer storage media (also referred to as "hardware storage devices") are computer-readable hardware storage devices such as RAM, ROM, EEPROM, CD-ROM, RAM-based solid-state drives ("SSD"), flash memory, phase-change memory ("PCM"), or other types of memory, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other media that can be used to store desired program code means in the form of computer-executable instructions, data or data structures and that can be accessed by a general purpose or special purpose computer.

[0134] The computer system 600 may also be connected (via a wired or wireless connection) to external sensors (e.g., one or more remote cameras) or devices via the network 620. For example, the computer system 600 may communicate with any number of devices or cloud services to obtain or process data. In some cases, the network 620 itself may be a cloud network. In addition, the computer system 600 may also be connected to a remote / separate (multiple) computer system via one or more wired or wireless networks, which is configured to perform any of the processes described with respect to the computer system 600.

[0135] A "network" similar to network 620 is defined as one or more data links and / or data switches capable of transmitting electronic data between computer systems, modules and / or other electronic devices. When information is transmitted or provided to a computer through a network (hardwired, wireless, or a combination of hardwired and wireless), the computer appropriately considers the connection as a transmission medium. Computer system 600 will include one or more communication channels used to communicate with network 620. Transmission media include networks that can be used to carry data or desired program code devices in the form of computer executable instructions or in the form of data structures. In addition, these computer executable instructions can be accessed by general or special computers. The above combination should also be included in the scope of computer-readable media.

[0136] Upon reaching various computer system components, program code means in the form of computer executable instructions or data structures may be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer executable instructions or data structures received over a network or data link may be cached in RAM within a network interface module (e.g., a network interface card or "NIC"), and then ultimately transferred to computer system RAM and / or to less volatile computer storage media at the computer system. Thus, it should be understood that computer storage media may be included in computer system components that also (or even primarily) utilize transmission media.

[0137] Computer executable (or computer interpretable) instructions include, for example, instructions that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. Computer executable instructions can be, for example, binary code, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in a language dedicated to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above. On the contrary, the described features and actions are disclosed as example forms of implementing the claims.

[0138] Those skilled in the art will appreciate that embodiments may be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, etc. Embodiments may also be practiced in a distributed system environment, where local and remote computer systems linked by a network (by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) each perform tasks (e.g., cloud computing, cloud services, etc.). In a distributed system environment, program modules may be located in local and remote memory storage devices.

[0139] The present invention may be implemented in other specific forms without departing from the characteristics of the present invention. The described embodiments are considered to be illustrative and non-restrictive in all aspects. Therefore, the scope of the present invention is indicated by the appended claims rather than by the preceding description. All changes within the meaning and scope of the equivalents of the claims are included within their scope.

Claims

1. A method for (i) using context information associated with exposed credentials to identify resources that can be accessed using the exposed credentials, (ii) identifying an entity responsible for the resources, and (iii) alerting the responsible entity about the exposed credentials, the method comprising: Identify the credentials located within the product; determining that the credential is in an exposed state, such that the credential is an exposed credential, wherein the exposed credential, if used, can potentially provide access to a resource; analyzing one or more of the exposed credentials or the artifact to determine a context associated with the exposed credentials; identifying the resource based on the context associated with the exposed credential; determining the responsible entity associated with the resource; and Transmission of an alert is triggered, wherein the alert includes information corresponding to the exposed credential.

2. A method according to claim 1, wherein the information corresponding to the exposed credentials includes one or more of the following: information describing characteristics of the exposed credentials; information describing a security model associated with the exposed credentials; information about where the exposed credentials were found; or information about what steps can be performed to invalidate the exposed credentials. 3 . The method of claim 1 , wherein the artifact is at least one of: a source controlled artifact, a work ticket, an automation artifact, a workflow artifact, an email, or a document.

4. The method of claim 1, wherein the exposed credential is at least one of: a bearer token, an identity, a certificate, a private key, a static credential repository, a container of artifacts, compressed data, or a password. The method of claim 1 , wherein the credential is identified based on a detected pattern associated with the credential.

6. The method of claim 1 , wherein determining that the credential is in the exposed state comprises: Access availability of a data source storing the credentials is determined.

7. The method of claim 1, wherein the context is determined via a discovery process involving one or more of: inspecting the artifact, inspecting a nested set of artifacts that includes the artifact, or consulting a security model.

8. The method of claim 1, wherein the resource is at least one of: a local application, a cloud service operating in a cloud environment, a database management resource, an on-premises resource, an identity, or a certificate.

9. The method of claim 1, wherein the responsible entity is one or more entities having permission to manage the resource.

10. The method of claim 1, wherein identifying the credential located within the article comprises: scanning a data source including the artifact; identifying a suspicious credential suspected of being the exposed credential that, if used, could provide access to the resource; determining characteristics of the suspicious credential, the characteristics comprising a detected pattern associated with the suspicious credential; as well as Based on the determined characteristics of the suspicious credential, it is determined that the suspicious credential is the exposed credential.

11. The method according to claim 1, wherein the method further comprises: After the resource has been identified, a determination is made as to whether the exposed credentials can actually provide access to the resource.

12. The method according to claim 1, wherein the method further comprises: periodically querying to determine whether the exposed credential has been invalidated; In response to determining that the exposed credential has not been invalidated, providing a subsequent warning; as well as In response to determining that the exposed credential has been invalidated, actions related to remediation of the exposed credential are performed.

13. The method of claim 12, wherein the exposed credential is a password, and wherein the method further comprises: determining that the password cannot be used to access the resource; determining characteristics of the password; generating one or more variations of the password based on the determined characteristics; attempting to access the resource using the one or more variations of the password; as well as An attempt is made to use the password to access a different resource, where the different resource is of the same type as the resource.

14. The method of claim 1, wherein determining the responsible entity is based on at least one of: querying a metadata repository associated with the resource, the metadata repository comprising registration information linking the responsible entity to the resource, utilizing the credentials to perform additional discovery by using the credentials to consult a service to construct information about the responsible entity, using the credentials to communicate directly with the security model to obtain information about the responsible entity, or Telemetry data associated with at least one of the artifact, the credential, or the resource is analyzed.

15. The method of claim 1, wherein the exposed credentials are included in a nested artifact collection.

Images