EP4599349A1 - Gestion de risque interne de cybersécurité - Google Patents

Gestion de risque interne de cybersécurité

Info

Publication number
EP4599349A1
EP4599349A1 EP23786826.0A EP23786826A EP4599349A1 EP 4599349 A1 EP4599349 A1 EP 4599349A1 EP 23786826 A EP23786826 A EP 23786826A EP 4599349 A1 EP4599349 A1 EP 4599349A1
Authority
EP
European Patent Office
Prior art keywords
user
access
computing system
risk
authorized user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23786826.0A
Other languages
German (de)
English (en)
Inventor
Erin K. MIYAKE
Sudarson TM
Robert Mccann
Maria SIDDIQUI
Ashish Mishra
Talhah Munawar Mir
Sakshi Mittal
Jovan KALAJDJIESKI
Diego RUVALCABA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/990,667 external-priority patent/US20240121242A1/en
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Publication of EP4599349A1 publication Critical patent/EP4599349A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis

Definitions

  • Attacks on a computing system may take many different forms, including some forms which are difficult to predict, and forms which may vary from one situation to another. Accordingly, one of the guiding principles of cybersecurity is “defense in depth”. In practice, defense in depth is often pursed by forcing attackers to encounter multiple different kinds of security mechanisms at multiple different locations around or within the computing system. No single security mechanism is able to detect every kind of cyberattack, or able to end every detected cyberattack. But sometimes combining and layering a sufficient number and variety of defenses will deter an attacker, or at least limit the scope of harm from an attack.
  • cybersecurity professionals To implement defense in depth, cybersecurity professionals consider the different kinds of attacks that could be made against a computing system. They select defenses based on criteria such as: which attacks are most likely to occur, which attacks are most likely to succeed, which attacks are most harmful if successful, which defenses are in place, which defenses could be put in place, and the costs and procedural changes and training involved in putting a particular defense in place. Some defenses might not be feasible or cost-effective for the computing system. However, improvements in cybersecurity remain possible, and worth pursuing.
  • an unauthorized activity impact risk represents an impact of unauthorized activity of an authorized user or future unauthorized activity of the authorized user or both.
  • activity by a user refers to activity by a user device or activity by a user account, or by software on behalf of a user, or by hardware on behalf of a user. Activity is represented by digital data or machine operations or both in a computing system. “Activity” within the scope of any claim based on the present disclosure excludes human actions per se. Software or hardware activity “on behalf of a user” accordingly refers to software or hardware activity on behalf of a user device or on behalf of a user account or on behalf of another computational mechanism or computational artifact, and thus does not bring human behavior per se within the scope of any embodiment or any claim.
  • unauthorized activity includes accidental (unintentional) activity, or malicious activity, or both.
  • an impact risk is computed based on at least an authorized user influence pillar value and an authorized user access pillar value.
  • the authorized user influence pillar value represents an extent of influence of the authorized user within a managed computing system or within an organization which utilizes the managed computing system, or both.
  • the authorized user access pillar value represents an extent of authorized access to the managed computing system resources by the authorized user.
  • exfiltration is tracked as one kind of access.
  • a cybersecurity characteristic of the managed computing system is adjusted, based on at least the impact risk.
  • Figure 1 is a diagram illustrating aspects of computer systems and also illustrating configured storage media
  • Figure 2 is a diagram illustrating aspects of a computing environment which has one or more of the insider risk management enhancements taught herein;
  • Figure 3 is a block diagram illustrating an enhanced system configured with insider risk management functionality
  • Figure 4 is a block diagram illustrating some aspects of insider risk management
  • Figure 5 is a flowchart illustrating steps in some insider risk management methods, with particular attention to the presentation of a variety of steps which are performed in different combinations, and incorporating Figures 6 through 11;
  • Figure 6 is a flowchart illustrating steps in some insider risk management methods, with particular attention to adjusting a cybersecurity characteristic in response to a computed impact risk value
  • Figure 7 is a flowchart illustrating steps in some insider risk management methods, with particular attention to tuning impact risk computations on the basis of data signal availability (per a physical presence of certain data or a customer preference for or against certain data or both), data signal strength, data signal reliability, or a combination thereof;
  • Figure 8 is a flowchart illustrating steps in some insider risk management methods, with particular attention to providing a human-readable explanation of a potential high impact user designation or providing a human-readable explanation of a risk score based on or otherwise related to a computed impact risk value;
  • Figure 9 is a flowchart illustrating steps in a risk impact computation, in which access signals are obtained and added or both weighted and added to calculate an access pillar value, influence signals are obtained and added or both weighted and added to calculate an influence pillar value, and the two pillar values are added or both weighted and added to compute the risk impact;
  • Figure 10 is a flowchart further illustrating steps in some insider risk management methods
  • Figure 11 is a flowchart further illustrating steps in some insider risk management methods; and Figure 12 is a block diagram illustrating some additional aspects of insider risk management.
  • Microsoft innovators noted characteristics that apply to many if not all organizations, including businesses, educational institutions, government agencies, and other organizations that utilize computing technology. Within a given organization, there are users that have roles that provide them with more authorized access to highly sensitive information or more powerful privileges than an average user. As a result, if these users abuse or misuse their privileges accidentally or intentionally, they could cause major harm to the organization.
  • Some examples of these types of roles include members of highly confidential projects (e.g., tented projects), users who have access to pre-release financial information that is highly regulated, highly privileged administrators who can access account secrets, can create or remove users, and so on, and users who regularly access sensitive information (e.g., human resources specialists with access to compensation data, government identifications, and other personally identifying information (PII). These are but a few of the many examples.
  • highly confidential projects e.g., tented projects
  • users who have access to pre-release financial information that is highly regulated e.g., highly privileged administrators who can access account secrets, can create or remove users, and so on
  • users who regularly access sensitive information e.g., human resources specialists with access to compensation data, government identifications, and other personally identifying information (PII).
  • “managing” insider risk includes one or more of: identifying possible sources of security risk within an organization, identifying possible event sequences and other aspects of risk scenarios involving such sources, assessing the potential impact of accidental or intentional damage in such scenarios, and formulating tools and techniques to identify, assess, simulate, reduce, prevent, mitigate, investigate, or document such scenarios.
  • the innovators arrived at a view in which insider risk is a combination of an insider (user role, predispositions), insider motives and other actor motives (stressors), digital assets and their characteristics (e.g., sensitivity), and activities (e.g., data exfiltration, system takedown).
  • the innovators determined that a scoring model would reflect these factors and patterns.
  • a PHIU (potential high impact user) scoring model focuses on the insider (e.g., user role) and aims to identify users who are more capable than others to cause material harm to their organization due to their access to sensitive information, their influence at their organization, their privileges, their administrative access, or other factors.
  • Priority User groups can manually define Priority User groups and scope these groups into policy templates that focus on priority users.
  • manual definitions of Priority User groups are tedious, and fail to be maintained as users change job responsibilities or employers, and are subject to error.
  • a tented project (a.k.a. “disclosure project” or “skunk works” or “off the books” project) is sometimes a closely held secret within an organization, so an admin in charge of manually defined Priority User groups does not necessarily know who is part of the tented project and what sensitive information the tented project involves.
  • some embodiments taught herein provide an automated method to identify users in high-risk roles who can cause more harm to an organization due to the nature of their role and access. More generally, some embodiments drive detection and prioritization of the riskiest activity in an organization by enhancing context around users, help manage noise by surfacing alerts that are more likely to be risky or concerning because they were performed by a user who can have more damaging impact to the organization, and build context enrichment about user for activity detected in IRM. Some embodiments rank users who have high potential for impact (e.g., high position, high access privileges, high activity on sensitive information type (SITs)).
  • SITs sensitive information type
  • Some embodiments increase risk score weighting of the higher ranked user(s), or automatically add the higher ranked user(s) to a priority user group, or do both. Some embodiments increase monitoring or triggering (or both) of insider risk alert(s) based on action(s) of higher user(s) who are ranked higher as to potential impact.
  • System administrators, network administrators, cloud administrators, security analysts and other security personnel, operations personnel, developers, testers, engineers, auditors, and end-users are each a particular type of human user 104.
  • automated agents, scripts, playback software, devices, and the like running or otherwise serving on behalf of one or more humans also have user accounts, e.g., service accounts.
  • service accounts Sometimes a user account is created or otherwise provisioned as a human user account but in practice is used primarily or solely by one or more services; such an account is a de facto service account.
  • service account and “machine-driven account” are used interchangeably herein with no limitation to any particular vendor.
  • Storage devices or networking devices or both are considered peripheral equipment in some embodiments and part of a system 102 in other embodiments, depending on their detachability from the processor 110.
  • other computer systems not shown in Figure 1 interact in technological ways with the computer system 102 or with another system embodiment using one or more connections to a cloud 136 and/or other network 108 via network interface equipment, for example.
  • Each computer system 102 includes at least one processor 110.
  • the computer system 102 like other suitable systems, also includes one or more computer-readable storage media 112, also referred to as computer-readable storage devices 112.
  • tools 122 include software apps on mobile devices 102 or workstations 102 or servers 102, as well as APIs, browsers, or webpages and the corresponding software for protocols such as HTTPS, for example.
  • Storage media 112 occurs in different physical types. Some examples of storage media 112 are volatile memory, nonvolatile memory, fixed in place media, removable media, magnetic media, optical media, solid-state media, and other types of physical durable storage media (as opposed to merely a propagated signal or mere energy).
  • a configured storage medium 114 such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable nonvolatile memory medium becomes functionally a technological part of the computer system when inserted or otherwise installed, making its content accessible for interaction with and use by processor 110.
  • the removable configured storage medium 114 is an example of a computer-readable storage medium 112.
  • Some other examples of computer-readable storage media 112 include built-in RAM, ROM, hard disks, and other memory storage devices which are not readily removable by users 104.
  • neither a computer-readable medium nor a computer-readable storage medium nor a computer-readable memory is a signal per se or mere energy under any claim pending or granted in the United States.
  • the storage device 114 is configured with binary instructions 116 that are executable by a processor 110; “executable” is used in a broad sense herein to include machine code, interpretable code, bytecode, and/or code that runs on a virtual machine, for example.
  • the storage medium 114 is also configured with data 118 which is created, modified, referenced, and/or otherwise used for technical effect by execution of the instructions 116.
  • the instructions 116 and the data 118 configure the memory or other storage medium 114 in which they reside; when that memory or other computer readable storage medium is a functional part of a given computer system, the instructions 116 and data 118 also configure that computer system.
  • a portion of the data 118 is representative of real -world items such as events manifested in the system 102 hardware, product characteristics, inventories, physical measurements, settings, images, readings, volumes, and so forth. Such data is also transformed by backup, restore, commits, aborts, reformatting, and/or other technical operations.
  • a computing device e.g., general purpose computer, server, or cluster
  • a computing device e.g., general purpose computer, server, or cluster
  • the same or similar functionality can also often be implemented, in whole or in part, directly in hardware logic, to provide the same or similar technical effects.
  • the technical functionality described herein can be performed, at least in part, by one or more hardware logic components.
  • some embodiments include one of more of: hardware logic components 110, 128 such as Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip components (SOCs), Complex Programmable Logic Devices (CPLDs), and similar components.
  • FPGAs Field-Programmable Gate Arrays
  • ASICs Application-Specific Integrated Circuits
  • ASSPs Application-Specific Standard Products
  • SOCs System-on-a-Chip components
  • CPLDs Complex Programmable Logic Devices
  • components are grouped into interacting functional modules based on their inputs, outputs, or their technical effects, for example.
  • processors 110 e.g., CPUs, ALUs, FPUs, TPUs, GPUs, and/or quantum processors
  • memory / storage media 112 peripherals 106, and displays 126
  • some operating environments also include other hardware 128, such as batteries, buses, power supplies, wired and wireless network interface cards, for instance.
  • the nouns “screen” and “display” are used interchangeably herein.
  • a display 126 includes one or more touch screens, screens responsive to input from a pen or tablet, or screens which operate solely for output.
  • peripherals 106 such as human user I/O devices (screen, keyboard, mouse, tablet, microphone, speaker, motion sensor, etc.) will be present in operable communication with one or more processors 110 and memory 112.
  • the system includes multiple computers connected by a wired and/or wireless network 108.
  • Networking interface equipment 128 can provide access to networks 108, using network components such as a packet-switched network interface card, a wireless transceiver, or a telephone network interface, for example, which are present in some computer systems.
  • virtualizations of networking interface equipment and other network components such as switches or routers or firewalls are also present, e.g., in a software-defined network or a sandboxed or other secure cloud computing environment.
  • one or more computers are partially or fully “air gapped” by reason of being disconnected or only intermittently connected to another networked device or remote cloud.
  • insider risk management functionality 210 could be installed on an air gapped network and then be updated periodically or on occasion using removable media 114, or not updated at all.
  • Some embodiments also communicate technical data or technical instructions or both through direct memory access, removable or non-removable volatile or nonvolatile storage media, or other information storageretrieval and/or transmission approaches.
  • reference numerals may be added to designate items disclosed in the current application.
  • Such items may include, e.g., software, hardware, steps, methods, systems, functionalities, mechanisms, data structures, resources, or other items in a computing environment, which are disclosed herein but not associated with a particular reference numeral herein.
  • Corresponding drawings may also be added, e.g., drawings along the lines of Figure 4 or Figure 5 of the current application.
  • Figure 2 illustrates a computing system 102 configured by one or more of the insider risk management enhancements taught herein, resulting in an enhanced system 202.
  • this enhanced system 202 includes a single machine, a local network of machines, machines in a particular building, machines used by a particular entity, machines in a particular datacenter, machines in a particular cloud, or another computing environment 100 that is suitably enhanced.
  • Figure 2 items are discussed at various points herein, and additional details regarding them are provided in the discussion of a List of Reference Numerals later in this disclosure document.
  • Figure 3 illustrates an example enhanced system 202 which is configured with insider risk management software 302 to provide functionality 210.
  • Software 302 and other Figure 3 items are discussed at various points herein, and additional details regarding them are provided in the discussion of a List of Reference Numerals later in this disclosure document.
  • Figure 4 shows some aspects of insider risk management. This is not a comprehensive summary of all aspects of insider risk management 208 or all aspects of insider risk management functionality 210. Nor is it a comprehensive summary of all aspects of an environment 100 or system 202 or other context of insider risk management, or a comprehensive summary of all insider risk management mechanisms for potential use in or with a system 102.
  • Figure 4 items are discussed at various points herein, and additional details regarding them are provided in the discussion of a List of Reference Numerals later in this disclosure document.
  • an interface 330 includes hardware such as network interface cards, software such as network stacks, APIs, or sockets, combination items such as network connections, or a combination thereof.
  • an enhanced system 202 includes a managing computing system 202 (also called the management computing system or the management system) which is configured to manage insider risk to help protect a managed system 216.
  • the managing computing system 202 and the managed system 216 are disjunct in terms of the machines 101 they respectively include, whereas in other cases they overlap, or one system is contained wholly within the other system, or they are coextensive.
  • the managing system 202 and managed system 216 are coextensive with each other in terms of machines 101 and coextensive with a local network 108 that uses private IP addresses and contains multiple machines 101. Also, in these embodiments the pillar values 310 used to compute impact risk 214 are not based on any event data which represents any activity 410 or 412 which occurred in any system 102 outside the systems 202 and 216.
  • the managing system 202 and managed system 216 are coextensive with each other in terms of machines 101 and coextensive with a local network 108 that uses private IP addresses and contains multiple machines 101.
  • at least one pillar value 310 used to compute impact risk 214 is based at least in part on event data which represents activity 410 or 412 or both which occurred in a system 102 outside the systems 202 and 216; the activity data was then imported to the managing system 202 and used in impact risk 214 computation 502.
  • an influence pillar 318, 310 is based 502 on data representing activity on a social network outside the systems 202 and 216.
  • the managing system 202 includes at least one machine A 101 which is not part of the managed system 216.
  • Machine A performs risk management 208 operations that are not performed within the managed system 216, or has functionality 210 not present within the managed system 216, or both.
  • machine A performs impact risk 214 computation 502, and within the managed system 216 the impact risk 214 values are write-once (upon importation from machine A) and read-only after that unless and until the impact risk 214 values are recomputed by machine A.
  • the enhanced system 202 includes a digital memory 112 and at least one processor 110 in operable communication with the memory.
  • the digital memory 112 is volatile or nonvolatile or a mix.
  • the at least one processor is configured to collectively perform insider risk management.
  • an insider risk management computing system 202 is configured to manage insider risks to a managed computing system 216 that contains resources 132, the insider risk management computing system including: a digital memory 112, at least a portion of the digital memory being external to the managed computing system; a processor 110 in operable communication with the digital memory, the processor configured to perform insider risk management operations including automatically: computing 502 an impact risk 214 of an authorized user 104 of the managed computing system, and adjusting 504 a cybersecurity characteristic 304 of the managed computing system based on at least the impact risk.
  • the digital memory is not external to the managed computing system.
  • the impact risk includes a digital value which represents an impact 212 of unauthorized activity 410 of the authorized user or future unauthorized activity 410 of the authorized user or both.
  • the impact risk is computed 502 based on at least an authorized user influence pillar value 318, 310 and an authorized user access pillar value 308, 310.
  • the authorized user influence pillar value 318 (also referred to as the influence pillar) represents an extent of influence 316 of the authorized user within the managed computing system 216 or within an organization 424 which utilizes the managed computing system, or both.
  • the authorized user access pillar value 308 (also referred to as the influence pillar) represents an extent of authorized access 306 to the managed computing system resources by the authorized user.
  • the access 306 is actual access (authorized or not), or potential but currently authorized access, or both, depending on the embodiment.
  • Some embodiments include the insider risk management computing system 202 in combination with the managed computing system 216. Other embodiments include the insider risk management computing system 202 but exclude the managed computing system 216. In some embodiments, the insider risk management computing system 202 and the managed computing system 216 are coextensive, e.g., an enhanced system that manages its own insider risk using functionality 210.
  • the managed computing system 216 contains a security control 420 and a security group 322, and the security control is applied differently to users who are members of the security group than to users who are not members of the security group.
  • the adjusting 504 includes at least one of: altering 506 user membership of the security group based on at least the impact risk, or modifying 508 application of the security control to at least one user based on at least the impact risk.
  • a given embodiment may include additional or different kinds of insider risk management functionality, for example, as well as different technical features, aspects, security controls, mechanisms, rules, criteria, expressions, hierarchies, operational sequences, data structures, environment or system characteristics, or other insider risk management functionality 210 teachings noted herein, and may otherwise depart from the particular illustrative examples provided.
  • Figure 5 illustrates a family of methods 500 that are performed or assisted by some enhanced systems, such some systems 202 or another functionality 210 enhanced system as taught herein.
  • Figures 1 through 4 show insider risk management architectures with implicit or explicit actions, e.g., steps for obtaining, calculating, comparing, combining, and otherwise processing data 118, in which data 118 include, e.g., pillars 310, pillar signals 314, scores 426, alerts 428, insights 432, events 410 or 412, thresholds 430, detection results 408 or 414, or explanations 326, among other examples disclosed herein.
  • Steps in an embodiment may also be done in a different order than the top-to-bottom order that is laid out in Figures 5, 10, and 11.
  • Figures 5 through 11 are a supplement to the textual examples of embodiments provided herein and the textual descriptions of embodiments provided herein. In the event of any alleged inconsistency, lack of clarity, or excessive breadth due to an aspect or interpretation of Figures 5, 10, or 11, the text of this disclosure shall prevail over that aspect or interpretation of Figure 5, 10, or 11.
  • Arrows in method or data flow figures indicate allowable flows; arrows pointing in more than one direction thus indicate that flow may proceed in more than one direction. Steps may be performed serially, in a partially overlapping manner, or fully in parallel within a given flow.
  • the influence signal 320 represents at least one of the following: a position 1218 of the authorized user within a hierarchy of an organization; a title or a role 1218 of the authorized user within an organization; a count of people who report to the authorized user within an organization; or an administrative role 1218 of the authorized user within a computing environment.
  • the access signal 312 represents at least one of the following: a count of computing system resources accessed by the authorized user; a count of computing system resources the authorized user is authorized to access; a count of computing system resources of a specified sensitivity which have been accessed by the authorized user; or a count of computing system resources of a specified sensitivity which the authorized user is authorized to access.
  • the method includes automatically adjusting 504 a cybersecurity characteristic based on at least the impact risk by doing at least one of the following: automatically boosting 536, 508 a risk score 426 in a cybersecurity tool 122 which has alerting functionality; automatically disabling 528, automatically suspending 528, or automatically deleting 528 an account 532 in a computing environment; automatically altering 506 membership of the authorized user in a computing system security group 322; automatically turning on 508, 530 a particular security threat detection mechanism 534; automatically turning off 508, 530 a particular security threat detection mechanism 534; automatically changing 508, 538 a particular security alert threshold 430; or training 524 a machine learning model 526 with training data 118, wherein at least one quarter of the training data includes influence signals 320, access signals 312, pillar values 310, or impact risks 214, as measured by data size or training data examples count or both.
  • automatically computing 502 the impact risk 214 is also based on at least a cumulative potential exfiltration anomaly 520 access signal 3
  • the method includes detecting 518 the anomalous cumulative potential exfiltration 406 of data by the authorized user at least in part by comparing 522 potential exfiltration activity of the authorized user to first activities of a first peer group 404 of the authorized user and to second activities of a second peer group 404 of the authorized user.
  • the method includes calculating 512 a weighted combination by calculating a mean risk score of each algorithm (signal or pillar or both) by a tenant or organization or other entity, for each users’ score finding a distance from the mean, normalizing the distance from mean, for each risk score against a user, assigning a weight, calculating a weighted risk score, computing an average of weighted risk scores defined as a RawScore for internal debugging, and normalizing the weighted risk score and returning it as a user risk score, e.g., a PHIU score 426 or an HPU score 426 (these are the same herein; different terminology was used internally at different points in the innovation development process).
  • computing an average of weighted risk scores defined as a RawScore for internal debugging is omitted.
  • normalizing the distance from mean is performed using a min-max normalizer.
  • the method includes marking 1004 the authorized user with a potential high impact user designation 408 based on the impact risk 214 exceeding a specified threshold 430, and persisting 1016 the designation after the impact risk is below the specified threshold.
  • a user designation as an PHIU is not reversible within a timeframe defined by a policy. For instance, if the user is detected as a PHIU on day 1, and on day 3 they are no longer a PHIU, the designation is nonetheless not removed. The reason is that the user possessed the influence or access or both to cause increased harm in the time near the activity that corresponds to the designation.
  • Some embodiments include a configured computer-readable storage medium 112.
  • storage medium 112 include disks (magnetic, optical, or otherwise), RAM, EEPROMS or other ROMs, and other configurable memory, including in particular computer-readable storage media (which are not mere propagated signals).
  • the storage medium which is configured is in particular a removable storage medium 114 such as a CD, DVD, or flash memory.
  • a general-purpose memory which is be removable or not, and is volatile or not, depending on the embodiment, can be configured in the embodiment using items such as insider risk management software 302, impact risks 214, pillars 310, pillar signals 314, security groups 322, weight combinations 324 of pillars or signals or both, explanations 326, detectors 534, designations 408, alerts 428, insights 432, thresholds 430, roles 134, and privileges 130, in the form of data 118 and instructions 116, read from a removable storage medium 114 and/or another source such as a network connection, to form a configured storage medium.
  • the configured storage medium 112 is capable of causing a computer system 202 to perform technical process steps for insider risk management, as disclosed herein.
  • Some embodiments use or provide a computer-readable storage device 112, 114 configured with data 118 and instructions 116 which upon execution by a processor 110 cause a computing system to perform a method of insider risk management in a cloud computing environment 136, 100 or another computing environment 100.
  • This method includes any one or more steps disclosed herein, performed in any order.
  • a rank 214 is assigned each user based on how much potential damage the user could do to the organization if they are involved in an attack (active or passive or both). This impact rank does not measure the possibility of an attack by the user, but instead quantifies an estimate of how much damage 212 can be caused by an attack involving the user, that is, an attack by the user or by means of authorization 130 or 134 granted to the user.
  • an algorithm which computes 502 the impact rank or computes an underlying impact risk score 426 provides flexibility to end users (e.g., security personnel) by allowing them to receive an interpretable HPU score 426 for each user in an organization 424, e.g., each cloud tenant.
  • the algorithm is tunable 542 in that it provides flexibility by allowing end users to adjust 542 weights 332 of signals which contribute to a pillar value, or adjust 542 weights 332 of pillar values, or both.
  • interpretability some embodiments provide a straightforward usable score 426, and some provide an explanation 326 as to why a user x has a higher HPU score than a user y; some do both.
  • the algorithm is flexible in that new signals 314 or pillars 310 can be added 1018 easily.
  • the algorithm is flexible in that it is easy to adjust 542 weights of the signals or pillars or both.
  • Some embodiments utilize HPU scores by increasing 508 a riskiness value for users who have a high HPU score.
  • IRM insider risk management
  • This riskiness value increase is achieved in some embodiments through dynamic 538 thresholds, or score boosters 422, for example.
  • Some embodiments add 536, 508 a booster 422 to any policy score if a user is HPU, e.g., the booster is applied to an alert 428 score by being added on top of a highest scoring insight 432 to calculate a total risk score for the alert and a severity of the alert.
  • Some embodiments reduce 538, 508 one or more alerting thresholds 430 for activity if a user is HPU.
  • the access pillar value is weighted at 40% and the influence pillar value is weighted at 60% in a combination that determines the risk impact 214.
  • Other embodiments or configurations use different weighting values.
  • an influence pillar value 318 represents and quantifies how much influence 316 (a.k.a. power) a particular user or a particular set of users has in an organization 424 or in a specified computing environment 100, or both.
  • influence 316 is not necessarily direct influence in a computing system.
  • a Chief Executive Officer CEO
  • CEO Chief Executive Officer
  • influence 316 includes influence directly within a computing system 216, e.g., an admin role 134 or greater privileges 130 than other users of the system 216.
  • Various embodiments measure either or both kinds of influence for PHIU detection.
  • an influence signal 320 includes a numeric field Level From Top which provides hierarchical information.
  • an influence signal 320 includes a numeric field Report Count 1220 which represents a cumulative number of reportees under an employee.
  • an influence signal 320 includes a Boolean whose value specifies if the user is or is not an admin.
  • an influence signal 320 includes a set of Admin Role IDs which indicates admin role(s) 134, if any, of the user.
  • an access signal 312 includes inferred file access 306 from enriched audit log(s), sensitivity label identification(s) 416, or both.
  • an access signal 312 includes a total number of files accessed, e.g., a count of unique files accessed based on a file ID such as an ObjectID.
  • an access signal 312 includes categorical data based on counts of categories 418 of sensitive data accessed.
  • an access signal 312 includes not only actually accessed resources 132 but also accessible resources which have not been accessed (at least according to the access logs or similar records of actual access that are checked, if any). Otherwise, an actor A that has access to 10,000 files but has touched 10 would be considered less risky than another actor B that has access to 100 and touched 99, which would be a less optimal assessment; it is better in this example to treat A as riskier than B with regard to impact 212.
  • PHIU identification 408 is an enrichment to insider risk activity, not meant to identify a user themselves as a risk in an insulting manner. Users being identified as PHIU does not, in and of itself, mean that those users themselves are insider risks. It means that use of their authority, whether accidental or malicious or both, has greater potential for damage 212. It does not mean the damage will occur. In terms of risk posed by a user per se, a PHIU with a very high risk score 214 who has a long history of trustworthiness and reliability despite opportunities and incentives to abuse their authority or make damaging errors is reasonably viewed as less risky than a non-PHIU whose loyalties and competence are low or unknown.
  • Some embodiments include a machine learning model 526 or a statistical model, or both.
  • machine learning model features or statistical model features or both include a count of unique files accessed by the users, a count of unique files sensitivity tagged 416 or 418 as “general”, and a count of unique files sensitivity tagged 416 or 418 as “confidential”.
  • sensitivity tags are inferred, and subject to a confidence threshold, e.g., 0.85.
  • file counts are separated into buckets, e.g., a bucket representing the number of confidential files a user has is in a bucket representing a file count of zero, or in a bucket representing a file count of one to three, or in a bucket representing a file count of four to six, and so on.
  • These count delimiters (0, 1 to 3, 4 to 6, etc.) are only examples; in other cases buckets are defined to have different count delimiters.
  • Some embodiments are based on one or more of the following assumptions: users who have more access than others to sensitive data could be targeted or can exfiltrate sensitive data; users with admin privileges can cause more damage than other users; although users with hierarchical power don’t necessarily have direct access to sensitive files, they can create lateral damage by using the powers of people who report to them.
  • signals 314 are individually treated and a statistical p value for each signal is calculated.
  • the HPU score is a composite linear function of influence and data access a user has.
  • access is solely actual access while in other embodiments access represents accessible resources, including resources 132 not necessarily actually accessed as yet.
  • the scoring algorithm provides importance to certain signals over others by adjusting the weights.
  • Some embodiments utilize a Fisher score, but that approach sometimes yields a multinode distribution which does not have any direct lookup to get a final p value.
  • Some embodiments utilize a Stouffer method to convert the individual p values into z scores, making it possible to combine two or more normally distributed data to get the final p value.
  • percentages are reported 516, as a basis for an end user to intepret why the algorithm scored a user X higher than a user Y.
  • Cutoffs are used in setting 542 weights in some embodiments, e.g., if the data is less reliable or has fewer sources. For example, if only actual access data is available and sensitivity is not used, then an embodiment might only use the top 0.1% of access data for HPU scores. But if more access data and sensitivity data is available, some embodiments increase the cutoff to use the top 1%.
  • one data flow proceeds as follows. Enriched audit logs, Microsoft Information Protection (MIP) lookup results and Microsoft Sensitive Information Type (SIT) 418 lookup results are analyzed to infer 1034 which resources 132, e.g., which sites, have been accessed by a user. Influence signals such as blast radius, level from top, and count 1220 of reportees, as well as admin roles data, are analyzed to infer 1036 organizational power of the user. The access resource inferences and the organizational power inferences undergo feature engineering, e.g., per familiar data science techniques for cleaning and organizing given data, and the results are fed to the HPU scoring algorithm described herein. The HPU scoring algorithm produces a ranked list of HPU candidates. In some embodiments, the HPU scoring algorithm instead or also produces a trained HPU scoring inference engine, e.g., a statistical or machine learning model.
  • MIP Microsoft Information Protection
  • SIT Microsoft Sensitive Information Type
  • Some embodiments also utilize one or more of the following data sources as input to the algorithm.
  • Priority content namely, a customer can specify content to be scored higher, e.g., specified shared sites, content with specific sensitivity labels, content of specific sensitivity types.
  • Historical attack information about the user e.g., whether the user was a target of phishing or other attacks.
  • this attack information is Boolean (has or has not been a target), and in some it is more fine-grained (e.g., has been a target N times in past 6 months, or has been a target N times since the most recent job role change).
  • this social media influence data is Boolean (e.g., user is or is not authorized to post on behalf of the organization), and in some it is more fine-grained (e.g., user has N thousand followers, user has posted on behalf of the organization an average of K times in the past 30 days, user has sent or received N communications in the past week, user mentioned the organization by name N times in the past month in public postings not necessarily speaking on behalf of the organization, user mentioned the organization or an organization officer or an organization product by name N times in the past six months, etc.).
  • Boolean e.g., user is or is not authorized to post on behalf of the organization
  • more fine-grained e.g., user has N thousand followers, user has posted on behalf of the organization an average of K times in the past 30 days, user has sent or received N communications in the past week, user mentioned the organization by name N times in the past month in public postings not necessarily speaking on behalf of the organization, user mentioned the organization or an organization officer or an organization product by name N times in the past six months
  • Some embodiments compute a user access pillar using actual access event (logs), or using potential access events (e.g., total number of SharePoint® sites user has access to), or using both. Some embodiments iterate thru sites and enumerate authorized users of each site to populate a data structure representing sites and their authorized users, and then use information such as the number of sites the user is authorized to access, and the sensitivity label of each site, when computing the user access pillar value.
  • Some embodiments provide 516 an explanation of an HPU score, which is different than a machine learning score that has no accompanying human-legible explanation of the reasoning that led to the score.
  • an explanation 326 for a hypothetical user X is along the following lines: X has been identified as a possible high potential user due to: X accesses more files with sensitive information types than the average user, X is in a Global Admin role, X’s level from the top of the organizational hierarchy.
  • some or all relevant actual values are shown, such as the count of files for X and for the average user.
  • an explanation 326 includes a statement along the lines of “This user is in the top 17% of the organization for accessing sensitive information”.
  • a visual indicator shows in an alert overview that the user is a priority user with the top reasons why to drive explainability.
  • Some reasons 328 are, e.g., access to sensitive content with labels, access to sensitive content with sensitive information types, level from top of organization, admin role (role name), cumulative reports involving user, or membership in a named Priority User Group.
  • these top reasons 328 are passed to a user interface from a PHIU model, for example.
  • a cloud tenant who wishes to obtain the enhanced security benefits of HPU scoring of its constituent users is able to opt in to sharing the access signal data and the influence signal data with the cloud service provider or with another entity that processes the signal data to compute HPU scores on behalf of the tenant.
  • tenants are also notified 1038 that without access to data, HPU detections could be less accurate, or otherwise limited in comparison to situations where more data is available to the tool 302 computing the HPU scores.
  • PHIU e.g., users with HPU scores above a specified threshold
  • PAG Priority User Group
  • RBAC granular role-based access control
  • an IRM tool 122 settings control screen or other user interface 124 includes an option for enabling or disabling risk score boosters for policy alerts.
  • Some example booster 422 conditions include “Activity is above user’s usual activity for that day”, and “User is a member of a priority user group”, “User is detected as a potential high impact user”. In some embodiments, only one of the following boosters is applied: member of a priority user group, or potential high impact user. In other embodiments, both booster conditions are applied.
  • an IRM tool settings control screen or other user interface 124 provides 1038 a message such as “User are detected as potential high impact users based on access to sensitive labelled information and Sensitive Information Types compared to the rest of your organization, Azure® Active Directory® hierarchy, and if they are a member of an Azure® Active Directory® Role.” (marks of Microsoft Corporation).
  • an IRM tool settings control screen or other user interface 124 provides 1038 a message such as “Note: If you select this risk booster, you’re agreeing to sharing Azure® Blast Radius information. If your organization does not use Microsoft Information Protection labels, or Azure® Active Directory® Hierarchy, then the detection accuracy may be lower.” (marks of Microsoft Corporation).
  • a user is a HPU for a proper subset of policies the user is in scope for, and the user’s status for various individual policies is listed accordingly.
  • the user can be labeled as HPU (or not).
  • user identification as a PHIU is not reversible within a scope of policy timeframe. If the user is detected 408 as a PHIU on day 1, and on day 3 they are no longer meeting the criteria for initial identification as a PHIU, the identification as a PHIU is nonetheless kept 1016 in place. The user had the power or access to cause increased harm in the time near the activity performed. Similarly, a score of an alert is not decreased, so the PHIU booster is not removed from an alert after the user is out of scope of a policy. In summary, in these examples if a user is identified as a PHIU within their policy timeframe, then they will remain 1016 a PHIU until their policy timeframe ends. Some embodiments update 516 the PHIU explanation reasons in an interface to reflect the most recent reasons for a user to be treated as PHIU.
  • a user if a user receives a booster because they’re in a PUG 322, and later they’re removed from PUG membership, the embodiment does not remove the booster (the booster is maintained 1042). Some embodiments notate 1044 the PUG that they were a part of, to indicate that former membership led to the booster being applied. If a user receives a booster because they’re in more than one PUG and then they’re removed from one of those PUGs, some embodiments show 1046 the current PUG(s) that they’re still in.
  • access signals are computationally derived 1048 from all file events in enriched audit logs.
  • access signals 312 include sensitivity labels 416, or sensitivity information types 418, or both.
  • influence signals are computationally derived 1048 from one or more of: cumulative reports or cumulative direct reports, a directory service organizational hierarchy, a directory service organizational role, or a directory service administrative role.
  • admin identification looks 1048 at the types of permissions associated with the admin roles and applies 1048 scores, e.g., a user who has permissions necessary to reset a password for a user or an app receives a higher score.
  • admin identification also looks at 1048 service principals owned by the user.
  • an access pillar is computationally derived 1048 based on inferring 1034 the files accessed by a user by checking 1034 a file activity pattern of an user from enriched audit logs with a SharePoint® workload using one or more of the following Events (or similar events in other environments):
  • Some embodiments utilize 518 exfiltration detection infrastructure to generate and store a research detection that includes a list of prioritized users per tenant as well as the reasons that the user was marked 1004 as high priority. Some read from the research detection storage.
  • Some embodiments filter out 1006 users that are not in scope. Some parse 1050 the information as a user insight with a new Insight Category, e.g., UserEnrichmentlnsight, and send 1050 it through an insight event hub. Some run 540 a PHIU job periodically, e.g., once a day, and resend the insights to an orchestrator periodically, e.g., every hour. Some update 514 a user PHIU status to show the objects in scope or policies, or both, found as PHIU. Some filter out 1008 boosters in a policy that aren’t used for scoring, e.g., InsiderRiskCaseClosed. Some include a feedback mechanism to provide 1102 feedback 1104 from users generally or from admins in particular on PHIU identifications.
  • a feedback mechanism to provide 1102 feedback 1104 from users generally or from admins in particular on PHIU identifications.
  • Some embodiments aggregate 1108 access data.
  • some reuse sensitivity label and sensitivity type aggregates, and re-aggregate them over a period, e.g., the past 30 days.
  • an embodiment filters 1010 and reads only activities that have sensitivity label or sensitivity type information for all users in the last 30 days. Then the embodiment extracts 1110 relevant information on each activity.
  • the embodiment groups 1112 by user, label name and whether the label was prioritized or is in the top 10% ranked by order of sensitivity label priority order.
  • the embodiment counts 1108 the number of sensitivity types on each activity and sets that to a sensitivity type count. Then the embodiment groups 1112 by user and sums 1108 the sensitivity type count over the window, e.g., 30 days. Results are inputs for a PHIU model 526.
  • a weights computation step 542 is performed once per tenant. This will assign the weights 332 that will be used to show the availability of the input signals received for this tenant. It is assumed in this example that the weights do not change across daily runs of the PHIU model.
  • the weights can be cached, e.g., for use in snapshots.
  • embodiment data flow also includes flow from a UserlnsightProcessor to filters that filter 1008 HPU boosters out of raw insights to be processed (not scored). If HPU is found, data flow updates all active objects in scope and updates a risky user entity to designate priority with the reasoning found. Then data flow scores user insights; when scoring an object in scope, a booster is applied if the object is marked as priority.
  • access pillar signals 312 in an embodiment and respective implementation data types include Tenantld: String, Userid: String (represents the user principal name (UPN)), AadUserld: String (null if user is not in scope, AAD refers to Azure® Active Directory®), SIT O Count: Long, SIT_l_3_Count (from 30-day historical aggregates), SIT_4_6_Count, ..., SIT_10_12_Count, SIT_G_12_Count, MIP Priority Count, MIP Inferred Priority Count.
  • Tenantld String
  • Userid String (represents the user principal name (UPN)
  • AadUserld String (null if user is not in scope, AAD refers to Azure® Active Directory®)
  • SIT O Count Long
  • SIT_l_3_Count from 30-day historical aggregates
  • SIT_4_6_Count ...
  • SIT_10_12_Count SIT_G_12_
  • a weights contract specifies weights 332 to be calculated once per tenant and persisted in storage.
  • these weights and some associated data include Tenantld, Level_From_Top_Weight (from blast radius), Cumulative_Report_Count_Weight (from blast radius), Is_Admin_Weight (from blast radius), MIP_Priority_Count_Weight(from 30-day historical aggregates), MIP_Inferred_Priority_Count_Weight (from 30-day historical aggregates), SIT_0_Count_W eight, SIT_l_3_Count_Weight (from 30-day historical aggregates), SIT_4_6_Count_Weight, ..., SIT_10_12_Count_Weight, SIT_G_12_Count_Weight, Influence_Weight, Access_Weight, CreatedTime.
  • Some embodiments include or utilize a Cumulative Exfiltration Anomaly Detection (CEAD) detector 414, 534 which detects exfiltration activity performed by a user over a period of time and over different methods of exfiltration 406.
  • CEAD detector spots sophisticated insider risk activity performed by insiders who takes a more methodical approach to exfiltrating sensitive content from their organization (e.g., “low and slow” exfiltration).
  • exfiltration means sending data from inside an organization’s computing system to a location outside that computing system. Exfiltration might be authorized or unauthorized, and might be intentional or accidental, depending on the situation.
  • CEAD functionality operates along the following lines.
  • the CEAD detector calculates 1114 a median exfiltration activity for the customer’s tenant for last 30 days (by exfiltration activity type and total exfiltration activity), calculates 1114 a cumulative exfiltration for user for last 30 days (by exfiltration activity type and total exfiltration activity), identifies 1114 a standard deviation from tenant median for a user’s activity across exfiltration activity type and total exfiltration activity over 30 days, feeds 1114 this result through a calibration function, and assigns 1116 a CEAD score 426.
  • Some embodiments present 1056 an insight 432 for the CEAD risk, and some generate 540 an alert 428 if the CEAD score meets an alert threshold 430.
  • Some embodiments calculate 522 a user’s distance from an organizational average for exfiltration activities over time. Some add 522 a CEAD computation 1114 OR 116 to compare a user’s cumulative activities against one or more of the user’s peer groups 404. In some embodiments, comparison results from multiple peer groups are combined by summation, by weighted combination, by individual comparison to a threshold, or otherwise, in a given embodiment.
  • a user in a sales organization frequently sends emails with attachments to external recipients, to help close deals with customers.
  • Some embodiments measure this user’s cumulative exfiltration relative to a peer group 404 of other sales employees with similar activity patterns, instead of measuring this user’s exfiltration activities compared to users who rarely have a need to send emails to external recipients.
  • a user’s peer group(s) 404 is identified based on one or more criteria.
  • a user has multiple peer groups based, e.g., on organizational distance (e.g., users who work on Product X), the user’ s role (e.g., engineers who work on Product X), or users who access similar resources (e.g., users who access the shared site for Product X). More particularly, some embodiments identify one or more of the following peer groups, or peer groups 404 along similar lines.
  • Peer Group #1 Organization or Management Chain - Identify peer group based on org distance, based on user’s peers, user’s manager’ s peers, reportees and reportees’ reportees.
  • a variation uses a proper subset of the listed bases.
  • Peer Group #2 Role name - Identify peer groups based on similar job title using vector-based cosine similarity. could also take into account org distance.
  • Peer Group #3 Users that access similar resources - Identify peer groups based on common online sites that are accessed. Some embodiments remove 1118 common sites from this computation to remove noise from general purpose sites such as search engine sites or a company’s human resources site.
  • M is an IRM analyst at a hypothetical example company Contoso. M is reviewing an alert generated for J. J is a data scientist at Contoso. J’s alert was generated due to cumulative exfiltration activity. M sees that J’ s exfiltration volume is moderate and about the same as the organizational average. However, J’s volume is nearly twice the average of J’s peer group 404. When M takes a closer look at J’s activity, M sees that J has a high volume of upload to cloud activity exfiltrating pre-release features to J’s personal cloud service. Thus, comparison 522 to a peer group smaller than the organization detects anomalous exfiltration that a simple comparison to the organizational average would have missed.
  • M moves on to an alert generated for C.
  • C is a sales rep.
  • C’s alert was also generated due to cumulative exfiltration activity.
  • M sees that C’s exfiltration volume is higher than the organizational average.
  • C’s volume is about the same as C’s peer group’s average.
  • M is not so concerned now and from a quick scan, sees that most of C’s activities are related to contract negotiations with customers, which is expected for C’s job.
  • comparison 522 to a peer group smaller than the organization avoids a false positive that a simple comparison to the organizational average would have caused.
  • a CEAD detector generates 1120 peer groups for a user and computes CEAD for a user based on that user’s activity compared to organization median, as well as generating 1122 peer group medians and comparing 522 user activity to them.
  • the activity types measured for a user include exfiltration activity types, such as external email, copy to cloud, copy to removable media, copy to file share, copy to shared platform, copy to chat, and print, for example.
  • exfiltration activity types such as external email, copy to cloud, copy to removable media, copy to file share, copy to shared platform, copy to chat, and print, for example.
  • the CEAD detector will send a CEAD insight 432 with the top three reasons 328 and a score to an orchestrator.
  • the reasons include a user’s activity comparison to their peer groups and the score represents this.
  • the top three reasons are those within each peer group, and in some, across all peer groups, depending on configuration and embodiment. Three is only an example; the top N reasons are shown in some cases, where N is in the range from one to ten.
  • CEAD insights reflect a user’s cumulative exfiltration compared to the org and their peer groups.
  • CEAD insights 432 specify or include one or more of: the total cumulative activity, a link to that activity detail, any groups where the user is most anomalous, a score that indicates a user is riskier relative to other users if they are anomalous compared to multiple peer groups, or whether the exfiltration activity contains priority content, for example.
  • CEAD insight explanations 326 The following are some of the many possible examples of CEAD insight explanations 326.
  • org means organization
  • UTC means coordinated universal time
  • exfil means exfiltration.
  • CEAD Explanation A Show the top 3 most anomalous groups and the top reason within each group). March 18 - March 28. More events than 100% of others in org (5500 events: copy to cloud). More events than 90% of others with similar role (4000 events: email). More events than 50% of others that access similar resources (20,000 events: all exfiltration activity).
  • a higher score is assigned when activity involves priority content.
  • content includes content with one or more of: sensitivity labels configured as priority content, sensitive information types configured as priority content, shared platforms (e.g., SharePoint® sites) configured as priority content, file extensions configured as priority content, or inferred priority sensitivity labels (e.g., top 10% prioritized sensitivity labels).
  • data used to generate peer groups 404 is obtained, e.g., from a directory service, and includes, e.g., manager’s alias + jobTitle, and manager’s direct reportee list + their jobTitles.
  • peer groups 404 are defined based on organizational hierarchy, access to shared resources, and job titles. In variations, only two of these bases are used, or only one of these bases is used.
  • an IRM tool settings control screen or other user interface 124 provides 1038 a message such as “Note: If you select this detection, you’re agreeing to sharing your Azure® Active Directory® data, including organizational hierarchy and job titles to identify peer groups. If your organization does not use Azure® Active Directory® to maintain organizational hierarchy and job titles, then the detection accuracy may be lower.”
  • a tenant can select whether their CEAD is computed for a user compared to Org norms, Peer norms, or both. By selecting peer group norms, the tenant is consenting to share directory service data with IRM, including organizational hierarchy and job titles to identify peer groups.
  • tenant settings an event hub, an event listener, an orchestrator, cruncher storage
  • raw policy data enriched logs
  • PHIU Potential High Impact User
  • C is also an employee at Contoso.
  • C is a senior director with a large team in the information technology (IT) organization.
  • C also has Global Admin privileges for Contoso’ s tenant for Azure® services and Microsoft 365® services and is a SharePoint® administrator (marks of Microsoft Corporation). These administrative roles grant C access to all of Contoso’ s SharePoint® sites.
  • C is working on a highly confidential project with Contoso’s Security Red Team and has access to reports on Contoso control gaps and vulnerabilities across their critical business processes.
  • the Contoso security team sees two insider risk alerts 428 for potential data theft.
  • One alert is for J and one alert is for C.
  • the security team sees that C is a Potential High Impact User at Contoso and they prioritize the review and response of C’s activity. If C were to abuse admin privileges, it could wreak havoc on Contoso. If C were to maliciously sell the Red Team report, it could put Contoso in a vulnerable position to be compromised by external attackers.
  • the PHIU model can be implemented in several ways. One approach involves alert prioritization, e.g., a risk score booster.
  • Some embodiments leverage the potential for user impact, as opposed to actual user impact. Estimating, tracking, modifying alerting, and otherwise managing potential impact offers advantages over insider risk approaches that merely look for impactful or risky behavior. Some embodiments “shift left” CEAD or other detections, i.e., they perform detections earlier than other approaches. For instance, some embodiments surface questionable behaviors earlier for attention by security controls or by security personnel or both, which enhances an organization’s ability to avoid large damage to the organization. Furthermore, by decoupling 1124 these impact categories (potential vs. actual impact), an embodiment gets the statistical benefits of independence. For instance, even if behavioral alerts were noisy for a particular tenant, the independently computed PHIU augmentation could still help alleviate that noise and separate out alerts that pose greater danger.
  • an embodiment will apply 512 the influence measurement differently than if the organization has a pyramid hierarchy, e.g., by reducing 542 (possibly to zero) the weight 332 of signals such as a user’s position from the top of the org hierarchy and a count of the user’s reportees.
  • an embodiment will automatically decrease 542 emphasis on that aspect of a user’s potential impact.
  • Some embodiments provide 516 explanations 326. Instead of simply stating “this user is potentially high impact”, they provide 516 reasons 328 that help an analyst or investigator interpret the PHIU designation.
  • the explanation 326 specifies why the user is (or is not) designated as a PHIU.
  • Risky insider activity can be challenging for organizations to detect because the risks are coming from users who have authorized access to assets 132 at the organization; this access is required so these users can perform their expected job duties. As a result, detecting activity performed by these users that is unexpected and harmful can be very difficult.
  • a technical challenge that security professionals face is how to tell if a user’s activity is expected and they are just doing their job, or if it’s potentially risky and able to harm the organization.
  • Some embodiments simultaneously look for 518 abnormality in specific exfiltration activity types (e.g., copying to USB) as well as cumulative or “all up” activity (e.g., copying to USB + printing + ). This allows an embodiment to find people who are spreading exfiltration over different data transfer mechanisms or different data communication channels, or both. Furthermore, some embodiments include a modular framework that allows per-tenant customization, e.g., to leverage action types available from a given tenant or action types important to a given tenant, or both.
  • Some embodiments look for 518 abnormality 520 by simultaneously or sequentially comparing 522 a user’s activity to what’s normal for each of multiple definitions of the user’s peer group 404 (e.g., peer groups based on org structure, on job titles, and on co-access to documents).
  • a user’s peer group 404 is an entire organization, but the default and presumption herein is that any peer group 404 is smaller than the organization as a whole.
  • This multi -peer-group method allows embodiments to find 518 hard-to-find risk 520 that might be missed if the user’s activities are compared to only one population slice (a.k.a. one peer group).
  • this multi -peer-group method is done modularly to support per-tenant customization, e.g., to leverage action types available from a given tenant or action types important to a given tenant, or both.
  • Some embodiments leverage file sensitivity info to improve detections (CEAD, or PHIU, or both). Some embodiments do this while inferring peer groups (e.g., co-access to sensitive files implies peers), or while assessing the abnormality of potential exfiltration activity (e.g., is a user copying too many sensitive files to USB), or both.
  • a related advantage is how some embodiments gracefully auto fit 542 each customer. Even without a customer stating their detailed preference and fine tuning, algorithms in some embodiments are designed to function largely right out of the box. For example, some embodiments automatically downplay 542 a particular definition of CEAD peer group or PHIU signal if a necessary data ingredient is lacking. Some do that tuning 542 in a non-binary way to get as much value out of the available data ingredients as possible (e.g., by using weighted combinations with non-zero weights instead of a simple on or off). Likewise, in some embodiments anomaly detection algorithms automatically determine 518 concerning behavior despite whatever normal looks like for each tenant.
  • DLP data loss prevention
  • weighting some embodiments base signal weighting or pillar weighting, or both, on the quality of available data, which in some cases includes data that is about the organization or data that is from the organization, or both.
  • Weights 332 are set 542 or adjusted 542, e.g., based on whether an organization is flat or has a management hierarchy, based on whether an organization defines admin roles in a computing system, and so on. Absence or presence is the granularity of the weighted data in some embodiments, or data may be more fine-grained.
  • an insight 432 is a detection from a PHIU detector, a CEAD detector, or another detection in IRM. Some examples are: CEAD detection found a specific user to have anomalous activity when compared to their peer group, and a user X was found to have 100 file downloads for a given day.
  • alerts 428 are how an embodiment surfaces insights to a customer via their security or admin personnel.
  • alerts are per user and show all the insights detected on the user since tracking of that user started in a system 216, or for another period. Not all insights are risky behavior, so some embodiments also have a risk score threshold to be met before insights for a user are surfaced in the form of an alert. In some, this risk score threshold is customizable for the customer.
  • IRM data is viewed as organized in a hierarchy.
  • Raw events These are atomic activity events logged for a user, e.g., user E had a download on 9/26 at 12:25pm.
  • Some embodiments utilize similar metrics for measuring PHIU detection accuracy, e.g., for the PHIU detections users confirm or dismiss, except that metadata provided in the insight is specific to PHIU.
  • This metadata includes all the feature values and weights that created the PHIU detection.
  • the overall PHIU metrics are the same as CEAD which include, number of insights generated, how many insights detected each feature as anomalous, and user alerts that were created in IRM where PHIU was the highest scored insight in the alert.
  • CEAD an embodiment can use the metadata and customer feedback to attempt to identify false positive detections.
  • CEAD control parameters include which activity types to consider (e.g., copying to USB, printing, uploading to personal cloud storage, %), what granularity of file sensitivity levels to use (e.g., ignore sensitivity and treat all files equal, versus 2-buckets (all, sensitive only), ...), the relative importance of those activityType+fileSensitivityLevel combinations (e.g., copy to USB on sensitive files is twice as important as everything else for Tenant X, or Tenant Y barely cares about printing), and which core anomaly detection and calibration options to use (e.g., z-score with mean versus median, calibrate with linear or nonlinear scaling).
  • activity types to consider e.g., copying to USB, printing, uploading to personal cloud storage, .
  • what granularity of file sensitivity levels to use e.g., ignore sensitivity and treat all files equal, versus 2-buckets (all, sensitive only)
  • the relative importance of those activityType+fileSensitivityLevel combinations
  • PHIU control parameters include the relative importance weights of the pillars.
  • adjustable hyperparameters for PHIU include the top percent of users that an embodiment detects as potential high impact users as well as the activity types the embodiment considers for the access pillar.
  • guardrails are employed 1130 to avoid undesirable customer experiences for CEAD limit volume and velocity. For instance, some embodiments are configured to not send more than N medium-severity alerts to any tenant in a day, to prevent the number of alerts per day from doubling between one day and the next day. These are examples, e.g., other periods than a day are also used, and other alert categories than medium severity are also used, or both, in some embodiments.
  • PHIU is an annotator on existing alerts and thereby inherits these or other guardrails.
  • guardrails in place for PHIU insights can entirely filter 1014 or partially filter 1014 based on the PHIU rank the model outputs. These filters 1014 can be per organization or for all detections.
  • an anomaly scores combination function is consistent with the following constraints.
  • One constraint is that the more peer groups a user is anomalous compared to, the higher their overall score should be. For example, when a user X is anomalous compared to users that access the same sites, users with a similar job title, and users in their team, then this user X is riskier than a user Y that is only anomalous compared to one peer group.
  • Some embodiments provide customizability so an organization can weight one peer group higher than another. For example, a customer could decide that if a user is anomalous compared to their team, it is riskier than if they are anomalous compared to others with the same job title.
  • N number of different peer group definitions. Then one anomaly scores combination method proceeds as follows to arrive at a single risk score which an analyst can use.
  • Step 1 Calculate mean risk score of each algorithm by tenant.
  • Step 2 For each users’ score, find distance from mean.
  • Step 3 Normalize the distance from mean using min-max normalizer.
  • Step 4 For each risk score against user, assign weight.
  • Step 6 Average of Weighted Risk Score is computed and defined as RawScore (used for internal debugging).
  • Step 7 The Weighted Risk Score is normalized and returned as Ri skyUser Score (used by product 302).
  • step 6 is skipped.
  • the tenant is replaced by a different kind of entity, e.g., a group or department.
  • Some embodiments combine org level attributes from a directory service with historical usage patterns of the user and with sensitivity content. Some can infer what sensitive content is based on out of box types 418 and labels 416. Some embodiments are tunable 542 based on the data that is relevant for the organization. In some embodiments, users are stack ranked across the entire organization to identify impact 212 potential relative to the organization’s norm.
  • Some embodiments combine peer group identification with cumulative anomaly detection to detect if an activity is anomalous by understanding the norms of a user’s peer group. Some embodiments also assign risk scores based on what is anomalous compared to organizational norms. Some embodiments combine these operations if a user has cumulative exfiltration risk compared to their peer groups and they are identified as a PHIU.
  • Some embodiments use or include an exfiltration detector utilizing a combination of components: file actions and sensitivity info, multiple types of computed peer groups, multi-modal exfiltration detection across all of that, and a possibly-preemptive boost to activity for users who have an inherent ability to do high damage.
  • the boost is computed from org info and file access behaviors plus sensitivity.
  • these embodiments are robust to different ingredients being available from different customers, or different customers expressing their own preferences on which components are the most meaningful to their view of risk, or both.
  • each ExfiltrationDetector includes multivariate AD across multi-modal activities (w/ config importance) & leveraging file sensitivity possibleExfilRiskScore detectedByComparingEachUserToTheirTypelPeerGroup ⁇ - ExfiltrationDetector(peerGroupsOfType 1 ) possibleExfilRiskScore_detectedByComparingEachUserToTheirType2PeerGroup ⁇ - ExfiltrationDetector(peerGroupsOfType2) possibleExfilRiskScore detectedByComparingEachUserToTheirTypeNPeerGroup ⁇ - ExfiltrationDetector(peerGroupsOfTypeN) overallExfilRi skScoreF orEachU ser
  • CombineAndCalibratePerGroupRiskScores (possibleExfilRiskScore_detectedByCompari ngEachUserT o A11U sers, possibleExfilRiskScore detectedByComparingEachUserToTheirTypelPeerGroup, possibleExfilRiskScore detectedByComparingEachUserToTheirTyp eNPeerGroup) # robustness to missings and configurable importance
  • Some embodiments weight at least one of the signals 314 based on a strength of the signal, or weight at least one of the pillars 310 based on a strength of at least one of the signals of the pillar.
  • signal strength is measured as availability, usefulness (e.g., infer to be not merely noise), or desirability (e.g., embodiment or customer assigns a relative importance weight).
  • Some embodiments boost a risk score in a policy-based cybersecurity tool based on at least the computed impact risk.
  • a policy-based cybersecurity tool is guided solely or partially by policies, by detectors, or both.
  • Some embodiments address technical activities such as computing 502 impact risk 214, altering 506 security group 322 membership, modifying 508 security control 420 behavior, detecting 518 anomalous exfiltration 406, and comparing 522 user activity to activity of user peer groups 404, which are each an activity deeply rooted in computing technology.
  • Some of the technical mechanisms discussed include, e.g., PHIU detectors 408, CEAD detectors 414, statistical or machine learning models 526, security tools 122, and insider risk management software 302.
  • Some embodiments described herein may be viewed by some people in a broader context. For instance, concepts such as efficiency, reliability, user satisfaction, or waste may be deemed relevant to a particular embodiment. However, it does not follow from the availability of a broad context that exclusive rights are being sought herein for abstract ideas; they are not. Rather, the present disclosure is focused on providing appropriately specific embodiments whose technical effects fully or partially solve particular technical problems, such as how to efficiently and effectively distinguish between users based on their potential impact 212 as opposed to their actual behavior alone, and how to tune 542 cybersecurity impact risk mechanisms 302, 122 based on which data signals 314 are available or based on which are priorities for a customer, or both. Other configured storage media, systems, and processes involving efficiency, reliability, user satisfaction, or waste are outside the present scope. Accordingly, vagueness, mere abstractness, lack of technical character, and accompanying proof problems are also avoided under a proper understanding of the present disclosure.
  • a process may include any steps described herein in any subset or combination or sequence which is operable. Each variant may occur alone, or in combination with any one or more of the other variants. Each variant may occur with any of the processes and each process may be combined with any one or more of the other processes. Each process or combination of processes, including variants, may be combined with any of the configured storage medium combinations and variants described above.
  • ALU arithmetic and logic unit
  • BIOS basic input/output system
  • CD compact disc
  • CPU central processing unit
  • DVD digital versatile disk or digital video disc
  • FPGA field-programmable gate array
  • FPU floating point processing unit
  • GPU graphical processing unit
  • GUI graphical user interface
  • HTTPS hypertext transfer protocol
  • secure laaS or IAAS infrastructure-as-a-service ID: identification or identity
  • LAN local area network OS: operating system
  • PaaS or PAAS platform-as-a-service
  • RAM random access memory
  • ROM read only memory
  • TPU tensor processing unit
  • WAN wide area network
  • a “computer system” may include, for example, one or more servers, motherboards, processing nodes, laptops, tablets, personal computers (portable or not), personal digital assistants, smartphones, smartwatches, smart bands, cell or mobile phones, other mobile devices having at least a processor and a memory, video game systems, augmented reality systems, holographic projection systems, televisions, wearable computing systems, and/or other device(s) providing one or more processors controlled at least in part by instructions.
  • the instructions may be in the form of firmware or other software in memory and/or specialized circuitry.
  • a “multithreaded” computer system is a computer system which supports multiple execution threads.
  • the term “thread” should be understood to include code capable of or subject to scheduling, and possibly to synchronization.
  • a thread may also be known outside this disclosure by another name, such as “task,” “process,” or “coroutine,” for example.
  • a distinction is made herein between threads and processes, in that a thread defines an execution path inside a process. Also, threads of a process share a given address space, whereas different processes have different respective address spaces.
  • the threads of a process may run in parallel, in sequence, or in a combination of parallel execution and sequential execution (e.g., time-sliced).
  • a “processor” is a thread-processing unit, such as a core in a simultaneous multithreading implementation.
  • a processor includes hardware.
  • a given chip may hold one or more processors.
  • Processors may be general purpose, or they may be tailored for specific uses such as vector processing, graphics processing, signal processing, floating-point arithmetic processing, encryption, I/O processing, machine learning, and so on.
  • Kernels include operating systems, hypervisors, virtual machines, BIOS or UEFI code, and similar hardware interface software.
  • Code means processor instructions, data (which includes constants, variables, and data structures), or both instructions and data. “Code” and “software” are used interchangeably herein. Executable code, interpreted code, and firmware are some examples of code.
  • Program is used broadly herein, to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (who are also referred to as developers) and/or automatically generated.
  • a “routine” is a callable piece of code which normally returns control to an instruction just after the point in a program execution at which the routine was called. Depending on the terminology used, a distinction is sometimes made elsewhere between a “function” and a “procedure”: a function normally returns a value, while a procedure does not. As used herein, “routine” includes both functions and procedures. A routine may have code that returns a value (e.g., sin(x)) or it may simply return without also providing a value (e.g., void functions).
  • Service means a consumable program offering, in a cloud computing environment or other network or computing system environment, which provides resources to multiple programs or provides resource access to multiple programs, or does both.
  • a service implementation may itself include multiple applications or other programs.
  • Cloud means pooled resources for computing, storage, and networking which are elastically available for measured on-demand service.
  • a cloud may be private, public, community, or a hybrid, and cloud services may be offered in the form of infrastructure as a service (laaS), platform as a service (PaaS), software as a service (SaaS), or another service.
  • laaS service
  • PaaS platform as a service
  • SaaS software as a service
  • a cloud may also be referred to as a “cloud environment” or a “cloud computing environment”.
  • network admin may be digital or computational or both
  • insider risk management as taught herein; e.g., software or specialized hardware which performs or is configured to perform steps 502 and 504, or any software or hardware which performs or is configured to perform a method 500 or a computational insider risk management activity first disclosed herein
  • cybersecurity characteristic e.g., presence of a security group 322, membership in a security group 322, behavior of a security control 420, behavior of a security tool 122, behavior of a security detection mechanism 408, 404, 122, behavior of a security model 526, privilege 130 per se or user association with a privilege 130, role 134 per se or user association with a role 134, sensitivity label 416 per se or resource association with a sensitivity label 416, or sensitivity type 418 per se or resource association with a sensitivity type 418
  • influence includes uses herein of “influence” in examples; digital or computational and as represented in a computing system; “influence” by a user refers to a result or other condition in a computing system of activity by a user device, by a user account, by software on behalf of a user, or by hardware on behalf of a user; influence is represented by digital data or machine operations or both; influence or any other pillar value or any pillar signal within the scope of any claim based on the present disclosure excludes human actions per se; computing an impact risk of a user accordingly means computing an impact risk of software or hardware activity on behalf of a user, subject to the exclusion of human behavior per se from the scope of any embodiment or any claim, as noted herein in the definition of “on behalf of’
  • 330 interface generally; also refers in context to particular interfaces such as user interface 124, web API, etc.
  • alert threshold or other security-related threshold in a computing system
  • 500 flowchart; 500 also refers to insider risk management methods that are illustrated by or consistent with the Figure 5 flowchart; incorporates the flowcharts of Figures 6 to 11 per the “any other step taught in text or drawings” step at the bottom of Figure 5
  • computationally means performed in a computing system, as opposed to mentally or on paper
  • a security group membership e.g., by adding a member, removing a member, creating a security group, or disabling or deleting a security group
  • a security control 508 computationally modify behavior (current or prospective or both) of a security control, e.g., by changing a threshold or frequency or intensity or other setting, or by enabling or disabling or adding or removing a control
  • PHIU designation 408 computationally display a PHIU designation 408, e.g., on a display 126 or via other electronic- to-human communication
  • 522 computationally compare user activity to user peer group activity, directly or by comparing statistics such as means, medians, etc.
  • 600 flowchart; 600 also refers to insider risk management methods that are illustrated by or consistent with the Figure 6 flowchart
  • 700 flowchart; 700 also refers to insider risk management methods that are illustrated by or consistent with the Figure 7 flowchart
  • 1000 flowchart; 1000 also refers to insider risk management methods that are illustrated by or consistent with the Figure 10 flowchart
  • 1128 computationally tune an embodiment, e.g., by changing a weight 332, threshold 430, or algorithm (e.g., which signals 314 or which pillars 310 or both) are used in response to absence or presence or strength of available data or in response to user preference as represented in a system 202
  • An authorized user influence pillar value 318 is based on one or more influence signals 320 representing the user’s actual or potential influence 316 in a computing environment 100.
  • An authorized user access pillar value 308 is based on one or more access signals 312 representing the user’s actual or potential access 306 to resources 132.
  • An impact risk value 214 is calculated 502 as a non-weighted or weighted combination 324 (depending on the embodiment) of the pillar values 310.
  • an embodiment automatically adjusts 504 a cybersecurity characteristic 304, such as a security risk score 426, security group 322 membership, threat detection mechanism 420, or alert threshold 430.
  • impact risk 214 is also based on a cumulative potential exfiltration anomaly 520 access signal 312. In some cases, impact risk 214 is based on one or more values which represent user public visibility 1202, user social network influence 1204, brand damage risk 1206, resource mission criticality 1208, access request response speed 1212 or success rate 1214, or a known cybersecurity attack 1216. Some embodiments automatically compute 502 an impact risk 214 of an authorized user of a managed computing system 216, and adjust 504 a cybersecurity characteristic 304 of a managed computing system 216 based on at least the impact risk 214. This beneficially helps security teams and security controls 420 prioritize insider risk prevention, alert review, investigation, and response activities to reduce or prevent harm from data leaks, data theft, sabotage, negative workplace cultural activity, etc. Security teams and security controls are often resource constrained and thus it is beneficial to focus their efforts on the most impactful threats first to protect an organization.
  • Some embodiments automatically display a human-readable explanation 326 of a computational basis 328 which was utilized while computing 502 the impact risk 214. This beneficially informs security personnel, admins, and other people of how the user matches, or does not match, criteria for being designated as a PHIU 402. Explanations enhance security control and impact risk usefulness, and in some situations lead to refinements of PHIU criteria.
  • automatically computing 502 the impact risk includes computing 512 a weighted combination 324 in which the pillar values 310 have different weights 324. This beneficially allows the managing system 202 or risk management software 302 to be tuned 542 according to data availability or customer preferences or both.
  • Embodiments are understood to also themselves include or benefit from tested and appropriate security controls and privacy controls such as the General Data Protection Regulation (GDPR).
  • GDPR General Data Protection Regulation
  • the teachings herein are not limited to use in technology supplied or administered by Microsoft. Under a suitable license, for example, the present teachings could be embodied in software or services provided by other cloud service providers.
  • Headings are for convenience only; information on a given topic may be found outside the section whose heading indicates that topic.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Selon certains modes de réalisation, l'invention aide à gérer un risque interne de cybersécurité. Une valeur de pilier d'influence d'un utilisateur autorisé est basée sur un signal d'influence représentant l'influence réelle ou potentielle de l'utilisateur dans un environnement informatique. Une valeur de pilier d'accès d'un utilisateur autorisé est basée sur un signal d'accès représentant l'accès réel ou potentiel de l'utilisateur à des ressources. Une valeur de risque d'impact est calculée sous la forme d'une combinaison pondérée des valeurs de pilier. En réponse, un mode de réalisation ajuste automatiquement une caractéristique de cybersécurité, telle qu'un score de risque de sécurité, une appartenance à un groupe de sécurité, un mécanisme de détection de menace ou un seuil d'alerte. Dans certains cas, le risque d'impact est également basé sur un signal d'accès à anomalie d'exfiltration potentielle cumulative. Dans certains cas, le risque d'impact est basé sur une ou plusieurs valeurs qui représentent une visibilité publique de l'utilisateur, une influence de l'utilisateur sur les réseaux sociaux, un risque d'endommagement de l'image de marque, une criticité des ressources, une vitesse de réponse aux demandes d'accès ou un taux de réussite, ou une attaque de cybersécurité connue.
EP23786826.0A 2022-10-06 2023-09-12 Gestion de risque interne de cybersécurité Pending EP4599349A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IN202241057264 2022-10-06
US17/990,667 US20240121242A1 (en) 2022-10-06 2022-11-19 Cybersecurity insider risk management
PCT/US2023/032562 WO2024076453A1 (fr) 2022-10-06 2023-09-12 Gestion de risque interne de cybersécurité

Publications (1)

Publication Number Publication Date
EP4599349A1 true EP4599349A1 (fr) 2025-08-13

Family

ID=88315851

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23786826.0A Pending EP4599349A1 (fr) 2022-10-06 2023-09-12 Gestion de risque interne de cybersécurité

Country Status (3)

Country Link
EP (1) EP4599349A1 (fr)
CN (1) CN119895417A (fr)
WO (1) WO2024076453A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250335584A1 (en) * 2024-04-30 2025-10-30 Microsoft Technology Licensing, Llc Cybersecurity tools for managing anomalous security data items

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0518405D0 (en) * 2005-09-09 2005-10-19 Ibm Operational risk control apparatus and method for data processing
US10701094B2 (en) * 2017-06-22 2020-06-30 Oracle International Corporation Techniques for monitoring privileged users and detecting anomalous activities in a computing environment
US11288385B2 (en) * 2018-04-13 2022-03-29 Sophos Limited Chain of custody for enterprise documents

Also Published As

Publication number Publication date
CN119895417A (zh) 2025-04-25
WO2024076453A1 (fr) 2024-04-11

Similar Documents

Publication Publication Date Title
US20240121242A1 (en) Cybersecurity insider risk management
US11647034B2 (en) Service access data enrichment for cybersecurity
US20250337742A1 (en) Anomaly-based mitigation of access request risk
US11783062B2 (en) Risk-based access to computing environment secrets
US12536319B2 (en) Controlling application access to sensitive data
US11303432B2 (en) Label-based double key encryption
US11483327B2 (en) Collaborative filtering anomaly detection explainability
US11310257B2 (en) Anomaly scoring using collaborative filtering
US20230259632A1 (en) Response activity-based security coverage management
US12526304B2 (en) Adaptive protection mechanisms loop
US20220368696A1 (en) Processing management for high data i/o ratio modules
US20210326744A1 (en) Security alert-incident grouping based on investigation history
EP3841502A1 (fr) Amélioration de la cybersécurité et surveillance opérationnelle avec attributions de confiance d'alerte
US20240056486A1 (en) Resource policy adjustment based on data characterization
US12615297B2 (en) Data security grouping and ranking
Kapoor et al. Platform and Model Design for Responsible AI
EP4599349A1 (fr) Gestion de risque interne de cybersécurité
Kumar et al. Admin: Attacks on dataset, model and input. a threat model for ai based software
WO2025058795A1 (fr) Regroupement et classement de sécurité de données

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250404

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)