Defining a security perimeter using knowledge of user behavior within a content management system

The present application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 63/413,210 titled “ZERO TRUST ARCHITECTURES IN CONTENT MANAGEMENT SYSTEMS” filed on Oct. 4, 2022, and the present application is related to co-pending U.S. patent application Ser. No. 18/346,156 titled “DELIVERING AUGMENTED THREAT ASSESSMENT VALUES TO A SECURITY THREAT MANAGEMENT FACILITY”, filed on even date herewith, both of which are hereby incorporated by reference in their entirety.

This disclosure relates to content management systems, and more particularly to techniques for coordinating security parameters between a third-party security threat management facility and a content management system.

With every passing day comes news of computer hacking, intellectual property theft, denials of service, and general mayhem in cyberspace. A sort of cat-and-mouse game between malefactors and those who seek to protect computer systems from malicious acts has been playing out since the earlies days of computers. An entire industry has been formed around protecting computer systems from malfeasance. These days, virus checkers have become commonplace, many cloaking strategies used by malefactors have been thwarted, and ransomware attacks are quickly detected and quenched. Nevertheless malaprops continue to reap mayhem using ever more and more sophisticated techniques.

Certain antidotes to such malfeasance have relied on having virus and other malware detection software running on literally millions or billions of computers worldwide. While this is at least hypothetically helpful in quickly identifying the occurrence of breaches, viruses, ransomware and other malware, this technique has proved to be insufficient. This is because generally, such identification comes too late, that is, breaches, viruses, ransomware and other forms of malware are identified only after there has already been some occurrence of some malfeasance. What is needed is a way to gauge the likelihood that some sort of security breach or other malfeasance is incipient. Moreover, what is needed is a way to share the existence of security vulnerabilities and as well as the likelihood of a breach such that remediation can take place before incurring a security risk or a security breach, and/or remediating before incurring the effects of other forms of malfeasance.

The problem to be solved is therefore rooted in various technological limitations of legacy approaches. Improved technologies are needed. In particular, improved applications of technologies are needed to address the aforementioned technological limitations of legacy approaches.

This summary is provided to introduce a selection of concepts that are further described elsewhere in the written description and in the figures. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Moreover, the individual embodiments of this disclosure each have several innovative aspects, where no single one of said innovative aspects is solely responsible for any particular desirable attribute or end result.

The present disclosure describes techniques used in systems, methods, and computer program products for defining a security perimeter using knowledge of user behavior within a content management system, which techniques advance the relevant technologies to address technological issues with legacy approaches. More specifically, the present disclosure describes techniques used in systems, methods, and in computer program products for defining a security perimeter based on content management system observations of user behavior. Certain embodiments are directed to technological solutions for continuously updating content object-specific risk assessments.

The disclosed embodiments modify and improve beyond legacy approaches. In particular, the herein-disclosed techniques provide technical solutions that address the technical problems attendant to failure of security threat management facilities to consider user behavior with respect to actual content. Such technical solutions involve specific implementations (e.g., data organization, data communication paths, module-to-module interrelationships, etc.) that relate to the software arts for improving computer functionality.

The ordered combination of steps of the embodiments serve in the context of practical applications that perform steps for continuously updating content object-specific risk assessments. As such, techniques for continuously updating and sharing content object-specific risk assessments overcome long-standing yet heretofore unsolved technological problems associated with failure of security threat management facilities to consider user behavior with respect to actual content.

Many of the herein-disclosed embodiments for continuously updating content object-specific risk assessments are technological solutions pertaining to technological problems that arise in the hardware and software arts that underlie collaboration systems. Aspects of the present disclosure achieve performance and other improvements in peripheral technical fields including, but not limited to dynamic security risk assessment and security policy codification.

Some embodiments include a sequence of instructions that are stored on a non-transitory computer readable medium. Such a sequence of instructions, when stored in memory and executed by one or more processors, causes the one or more processors to perform a set of acts for continuously updating content object-specific risk assessments.

Some embodiments include the aforementioned sequence of instructions that are stored in a memory, which memory is interfaced to one or more processors such that the one or more processors can execute the sequence of instructions to cause the one or more processors to implement acts for continuously updating content object-specific risk assessments.

In various embodiments, any combinations of any of the above can be organized to perform any variation of acts for defining a security perimeter based on content management system observations of user behavior, and many such combinations of aspects of the above elements are contemplated.

Further details of aspects, objectives and advantages of the technological embodiments are described herein and in the figures and claims.

Aspects of the present disclosure solve problems associated with using computer systems for failure of security threat management facilities to consider user behavior with respect to actual content. These problems are unique to, and may have been created by, various computer-implemented methods for failure of security threat management facilities to consider user behavior with respect to actual content in the context of collaboration systems. Some embodiments are directed to approaches for continuously updating content object-specific risk assessments. The accompanying figures and discussions herein present example environments, systems, methods, and computer program products for defining a security perimeter based on content management system observations of user behavior.

Overview

Disclosed herein are techniques for collecting, analyzing, and sharing data such that the likelihood of some sort of security breach or other malfeasance can be known and widely shared in advance of such a security breach or other malfeasance. Some of such techniques are implemented in or interfaced with a content management system. Data captured by a content management system can span a long period of time (e.g., years or decades), and can be specific to a particular user and/or his/her collaborators. Such data can be analyzed with respect to calculating a security threat risk assessment value. Strictly as one example, consider a content management system that hosts trade secret information that is accessible by only those who have a bona fide need to know. Historically, those who have a bona fide need to know have been vetted and are beyond reproach. However, recent security breaches (e.g., resulting in ‘leaks’) have been perpetrated by exactly those persons who had been deemed to be beyond reproach.

Unlike the types of data that is collected from widely-deployed virus checkers and other desktop computer system agents, the types of data collected by content management systems goes far beyond the frontier of data that is collected by such widely-deployed virus checkers and other desktop computer system agents. To illustrate, consider that each time a user device accesses a particular content object (e.g., file) of the content management system, an enormous amount of information is known at that moment.

For example, far beyond merely pairing the user device action (e.g., preview, READ, WRITE, download, etc.) with one or more content objects, the data available at that moment in time (e.g., in a MICROSOFT™ active directory domain service) includes a log of historical accesses to content objects by time and type of access and/or activity (e.g., create collab, add collab, remove collab, apply a security watermark), a log of historical accesses by collaborators, changes in security classifications of certain content objects, occurrences and location of personally identifiable information embedded in the bits of the content objects, the identity of the user associated with the user device, the role of said user in his/her enterprise (e.g., the user's title, department affiliation, etc.), the user's period of employment, the user's planned retirement date or the user's resignation date, the user's scheduled termination date, various security classifications of respective content objects, a precalculated risk tolerance value pertaining to a particular content object, the user's overall relationship with the full set of content objects of the content management system, the user's overall relationships (e.g., via collabs and/or exceptions) with other users of the content management system, and so on.

Some or all of this data can be used to define a machine learning model, specifically a predictive model where some set of incoming signals (e.g., versions or derivations of the aforementioned content management system data) is trained to generate outputs in the form of calculated risk values. Take for example, the following fact pattern:

When taken individually, none of the foregoing facts would, by itself, portend malfeasance; however, when taken together, the fact pattern suggests that the risk of malfeasance, specifically, risk of data ‘leakage’ is very high. Any operational element of the computing ecosystem that can ingest information (e.g., via ingress module) such as a risk value pertaining to the existential “risk of malfeasance” and/or a risk value pertaining to the existential “risk of ‘leakage’” can and should ingest such risk values. Such operational elements can use the aforementioned risk values in combination with other information so as to calculate a combined risk assessment.

In Internet settings, where multiple computing systems are interconnected by the world wide web, there are often many third-party players who bring to bear risk assessment tools. In some cases, such risk assessment tools have devised ways to get information about the network topology and network endpoints. Many of these third-party players implement crowd sourcing, where any ecosystem participant can provide further additional information pertaining to the network topology, network endpoints, and network activity. In spite of this massive amount of incoming (e.g., 100 billion tracked events per day), none of the aforementioned third parties nor any of the aforementioned ecosystem participants can provide the content-object based information that a content management system can provide.

Some of the terms used in this description are defined below for easy reference. The presented terms and their respective definitions are not rigidly restricted to these definitions—a term may be further defined by the term's use within this disclosure. The term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application and the appended claims, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or is clear from the context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A, X employs B, or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. As used herein, at least one of A or B means at least one of A, or at least one of B, or at least one of both A and B. In other words, this phrase is disjunctive. The articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or is clear from the context to be directed to a singular form.

Various embodiments are described herein with reference to the figures. It should be noted that the figures are not necessarily drawn to scale, and that elements of similar structures or functions are sometimes represented by like reference characters throughout the figures. It should also be noted that the figures are only intended to facilitate the description of the disclosed embodiments—they are not representative of an exhaustive treatment of all possible embodiments, and they are not intended to impute any limitation as to the scope of the claims. In addition, an illustrated embodiment need not portray all aspects or advantages of usage in any particular environment.

An aspect or an advantage described in conjunction with a particular embodiment is not necessarily limited to that embodiment and can be practiced in any other embodiments even if not so illustrated. References throughout this specification to “some embodiments” or “other embodiments” refer to a particular feature, structure, material, or characteristic described in connection with the embodiments as being included in at least one embodiment. Thus, the appearance of the phrases “in some embodiments” or “in other embodiments” in various places throughout this specification are not necessarily referring to the same embodiment or embodiments. The disclosed embodiments are not intended to be limiting of the claims.

exemplifies an environmentAin which various techniques for defining a security perimeter based on content management system observations of user behavior as disclosed herein can be practiced. As an option, one or more variations of environmentor any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and/or in any environment.

The figure is being presented to illustrate an exemplary environment in which operational components might be configured for practicing the herein-disclosed techniques. More particularly, the figure is being shown to illustrate how content management systemcan be operatively connected to a security threat management facility.

One possible technique for connecting a content management system (CMS) to a security threat management facility (STMF) involves configuring a CMS to ingest security information that is received from or derived from an STMF. In the shown example, CMSingests known threats a received from or derived from STMF. The known threats may derive based on operation of the STMF itself, or the known threats may derive from an identity access management (IAM) facility (e.g., the shown IAM), possibly in conjunction with identity datathat is accessed by the IAM facility.

As used herein, an identity access management facility is a framework of processes, policies and technologies that facilitates maintenance and promulgation of electronic identities (e.g., digital identities). Given an IAM framework, information technology (IT) managers can control user access to critical information. Technologies used in or by IAMs include single sign-on technologies, two-factor authentication technologies, multifactor authentication technologies, and privileged access management technologies. These technologies also provide the ability to securely store and share identity data. In some IAM implementations, profile data as well as data governance requirements serve to define the boundaries of data to be shared. IAM systems can be deployed on premises, and/or provided by a third-party vendor (e.g., through a cloud-based subscription model), and/or deployed in a hybrid model involving both on-premises infrastructure in combination with cloud-based infrastructure.

The aforementioned known threats might be received directly from an STMF, or the known threats might be received from an STMF that integrates with one or more third-party applications. Regardless of the origin of the foregoing known threats, such known threats, possibly represented in normalized forms (e.g., security parameters), can be combined with other security parameters that derive from and/or are known by the CMS (e.g., security parameters).

The shown CMS is capable of defining and maintaining threat or security parameters. This is because the CMS, in particular security perimeter moduleof the CMS, is able to ingest and analyze a great deal of information available to the CMS. Strictly to illustrate the wide range of information available to the CMS, which wide range of information can be used to define and maintain threat or security parameters (e.g., suspicious IP Accessesand/or suspicious file activities), consider that a CMS, either by virtue of use of its own native mechanisms (e.g., maintenance of user device profilesand maintenance of an event history), or by virtue of the CMS's abilities to avail itself of external facilities (e.g., the shown content object deep inspection module), can amalgamate security parameters into the form of a security perimeter.

As used herein, a security perimeter is a collection of values that correspond to respective vulnerabilities. The bounds of a security perimeter can be defined by a shape (e.g., a convex shape having a plurality of vertices that in turn correspond to respective risk values). Additionally or alternatively, the bounds of a security perimeter can be defined by a surface defined by a plurality of values which in turn correspond to a respective plurality of variables.

As shown, content objectsinclude precalculated instances of security metadata. Such security parameters may in turn correspond to the nature and extent of the contents of the content objects themselves. For example, a content object that is marked as “Confidential” or that contains information that is deemed to be sensitive might be associated with a high risk value, whereas a content object that contains non-proprietary information (e.g., a birthday card to the boss) might be associated with a low risk value. The shown content object deep inspection moduleis configured to be able to identify risk-informing items such as existence of personally identifiable information (PII), existence of an embedded security legend, and/or existence of a security watermark (e.g., “Confidential,” “Secret,” “Eyes Only,” “Export Controlled,” references to business transactions, etc.). In some cases, an outboard data processing service (e.g., a third-party service) performs the actual reading and assessment of the nature of the contents of a particular content object.

Further details regarding techniques for quantifying user-to-user relationships can be found in U.S. Pat. No. 10,867,209 titled “COMBINING OUTPUTS OF DATA PROCESSING SERVICES IN A CLOUD-BASED COLLABORATION PLATFORM” issued on Dec. 15, 2020, which is hereby incorporated by reference in its entirety.

The event history may contain any one or more of: a history of operations performed over the content object, and/or a constituent of groups of users who access the content object, and/or results of content object deep inspection, and/or various tracking of events and/or metadata pertaining to behavioral assessments. As shown, the event historyincludes precalculated behavioral assessments. Event histories comprise computer representations of events as captured and analyzed over any span of time. Moreover the results of analysis might be captured by or associated with the foregoing computer representations of events. Strictly as some examples, event historymight include any number of deep content inspection results, any number of occurrences of anomalous downloads, and number of occurrences of access pattern deviations, and/or any number of user vectors. Individual ones of the user vectors in turn might codify a user (e.g., where userID=“1234567”), a URL or other indication of an endpoint (e.g., “123.345.56.78:3333”), and/or an action (e.g., “PREVIEW”) that corresponds to an action of the user via the endpoint. In some cases, a user is not a natural person, but rather an agent (e.g., a computer program that is run in lieu of a person).

Additionally or alternatively, event historymight include any of a variety of signals. In the particular environment of, signals include impossible travel signalsand rogue agent signals.

Further details regarding techniques forming and using impossible travel signals can be found in U.S. Pat. No. 11,403,413 titled “AVOIDING USER SESSION MISCLASSIFICATION USING CONFIGURATION AND ACTIVITY FINGERPRINTS” issued on Aug. 2, 2022, which is hereby incorporated by reference in its entirety.

Further details regarding techniques for forming and using rogue agent signals can be found in U.S. Pat. No. 10,911,539 titled “MANAGING SHARED CONTENT DIRECTORY STRUCTURE METADATA” issued on Feb. 2, 2021, which is hereby incorporated by reference in its entirety.

The environment comprehended in the foregoing presents merely one way of combining information from a security threat management facility with information from a content management system. There are many alternative approaches for combining information from a security threat management facility with information from a content management system, an example of which is shown and described as pertains to.

exemplifies a security perimeter formulation technique as used in systems that define a security perimeter based on content management system observations of user behavior. As an option, one or more variations of security perimeter formulation techniqueBor any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and/or in any environment.

The figure is being presented to illustrate one technique of how to form security perimeter. More particularly, the figure is being presented to illustrate one technique of how to form a normalized security perimeter.

As used herein, a threat vector is a collection of threat assessment values where each one of the threat assessment values correspond to a risk value derived from a set of content-based threat values (CBTVs), and/or derived from a set of non-content-based threat values (NCBTVs). In some embodiments, at least some of the CBTVs and at least some of the NCBTVs are normalized (e.g., for purposes of comparison).

The figure includes a pair of example perimeters (first perimeterand second perimeter). For purposes of illustration, the two perimeters are superimposed onto respective graphs (e.g., non-content-based vulnerabilities graphand content-based vulnerabilities graph). In ongoing operations, the information used to form the non-content-based vulnerabilities graph is combined with the information used to form the content-based vulnerabilities graph, and this combination results in a combined security graph.

More specifically, and in accordance with this illustrative example, the information that is used to form the first perimeterand second perimeteris provided to a projector/combiner module. This projector/combiner module considers the provided information and produces a combined perimeter (e.g., the shown normalized security perimeter). The projector/combiner module operates to assess overall vulnerability considering both non-content-based vulnerabilities values as well as content-based vulnerabilities values.

As can be understood by those of ordinary skill in the art, the set of non-content-based vulnerabilities values and the set of content-based vulnerabilities values may be disjoint, or the set of non-content-based vulnerabilities values and the set of content-based vulnerabilities values may overlap. To explain, consider that an STMF reports a “high” vulnerability value for a particular IP address, and consider that a CMS reports a “medium” vulnerability value for the same IP address. Once normalized (e.g., within the projector/combiner module) such that the “high” vulnerability value of the STMF can be compared to the “medium” vulnerability value of the CMS, a risk value corresponding to exposing some operation to the higher vulnerability is assessed. This risk calculation can be done for any/all vulnerabilities as reported by the STMF and by the CMS, and the projector/combiner module can output a normalized security perimeter. This security perimeter can then be used to determine whether or not, or in some cases, how to perform an operation within the CMS.

In various embodiments, the STMF and the CMS operate substantially independently with respect to determining risks and/or vulnerabilities. Moreover, the STMF and the CMS operate over substantially different corpora of information and use substantially different techniques in calculating risk or vulnerability values. Strictly as a non-limiting example, using a first technique, an STMF establishes its set of security parameters based on calculations over information derived from packet inspection, whereas the CMS, using a second technique, establishes its set of security parameters based on calculations performed over information derived from analysis of user activities performed in the CMS or on content objects of the CMS. One of the advantages here is the ability to combine findings from both techniques in order to consider a more complete picture of risks and vulnerabilities. Moreover, one of the advantages here is the ability to combine findings (e.g., normalized values) from both techniques in order to define a normalized security perimeter.

In some cases, such a normalized security perimeter is formed by repeatedly selecting the higher of two risk values as reported by the STMF and by the CMS, and then plotting the selected higher of the two risk values as vertices of a shape (e.g., a polygonal shape). In such a case the area of the shape can be considered the total risk. If the total risk (e.g., total risk of performing a subject CMS operation) is greater than some risk threshold (e.g., as established by the CMS), then the subject operation at the CMS might be denied.

In some cases, such a normalized security perimeter is formed by repeatedly selecting the higher of two vulnerability values as reported by the STMF and by the CMS, and then plotting the selected higher of the two vulnerability values as vertices of a shape (e.g., a polygonal shape). In such a case the area of the shape can be considered the total vulnerability. If the total vulnerability (e.g., total vulnerability of performing a subject CMS operation) is greater than some vulnerability threshold (e.g., as established by the CMS), then the subject operation at the CMS might be denied.

In some embodiments, the calculated total risk and/or the calculated total vulnerability is compared against security policies. A security policy might codify semantics of, “Do not allow operations that correspond to a risk value greater than X.” Or, a security policy might codify semantics of, “Do not allow operations that correspond to a vulnerability value greater than Y.” Or, a security policy might codify semantics of, “Allow the operation to take place only after remediation.” Accordingly, upon completion of comparing the normalized security perimeter to one or more security policies (step), an evaluation of choices is undertaken (decision).

The result of evaluation of choices is a determination of an option. This is shown by the three branches of decision, specifically “Allow” (i.e., allow the subject operation to proceed), “Deny” (i.e., deny further processing of the subject operation), or “Remediate.” In this latter case of “Remediate,” the CMS can take actions to lower the risks or vulnerabilities. Strictly as one example, a document containing personally identifiable information (PII) can be redacted to remove such PII.