System and method for security monitoring processing

Abstract

To provide a method, a system and a non-transitory computer readable medium, for security event monitoring.SOLUTION: A method may include: receiving data from a security module of a first operating system; defining an audit classes data filter for collection by a security event monitoring application; comparing the data with the audit classes data filter; comparing the data with a series of blacklisted values; and outputting common structure format data based on the comparison of the data with the audit classes data filter and the blacklisted values.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] Various embodiments of the present disclosure relate generally to monitoring processes occurring in an operating system, and more specifically to taking security-related actions in an operating system environment. [Background technology]

[0002] Network attacks and cyber security are important issues for security-conscious enterprises. Business and regulatory environments in all markets require reliable auditing and logging measures for all computers connected to their networks. Traditional security solutions can provide enterprises with preventative endpoint defenses, where software reacts to new files entering a computing device and, if the file is deemed malicious, automatically prevents the file from executing on the device. However, attackers can still infiltrate a computing device without triggering such defenses.

[0003] Current operating systems may include built-in tools for collecting and monitoring operations performed on a computing device. For example, Apple™ ships the latest version of OpenBSM pre-installed on all computers that run macOS™. OpenBSM is an open source implementation of Sun Microsystems' Basic Security Module (BSM) audit API and file format. OpenBSM only collects login and audit events by default, and the events are not stored in a human-readable format.

[0004] However, existing security software tools ignore systems like OpenBSM that are pre-built into the operating system and build their own collection and monitoring methods, often introducing security issues into the operating system. Therefore, companies that use existing security software may unknowingly put their computers at risk. Furthermore, log collection tools cannot ingest logs generated by OpenBSM without an application or script that converts the OpenBSM logs at scheduled intervals. The native OpenBSM log format is not designed for real-time auditing or collection.

[0005] Furthermore, collecting all the events that OpenBSM generates would slow down existing computer systems so much that they would become unusable. For example, observing the flow of all events would create an infinite loop as more events are generated to detail the observations. This problem does not necessarily go away over time, as more events are generated, slowing down computers.

[0006] There are other existing tools that contain proof-of-concept code that can only be run on the developer's machine under special conditions. This tool is not complete, does not scale, and is not designed to be managed remotely. Furthermore, this tool does not use OpenBSM, which may be important in some aspects because OpenBSM uses Unix™ standards. OpenBSM may be the only way for non-kernel programs to collect security and audit information. Other collection methods require vendors to install kernel level code, which introduces instability and new security concerns. In some cases, only certain kernel extensions may be allowed to run on the first operating system, and kernel extensions for other operating systems may be prohibited by the first operating system.

[0007] Other tools ignore the native macOS system in favor of proprietary code for monitoring, collecting, and blocking security events. Non-native toolsets require integration testing for each sub-build of macOS. This vendor code leads to system-wide instability and performance issues because the vendor code must approve every action taken by the system before it can take action. This legacy system requires vendor kernel extensions (kexts). kexts introduce significant potential security vulnerabilities. Kexts run at the lowest level of the operating system, and any bugs or errors can cause the system to crash completely. On macOS 10.13.3+, kexts must be whitelisted or approved by the user.

[0008] Companies often have to delay macOS system updates so that vendors can update their own tools. Updating macOS without updating vendor tools often results in unusable systems that require specialized assistance from IT. It is nearly impossible to persistently determine the exact version that corresponds to the exact version of macOS. These tools upload data (including entire files) to the vendor's cloud for processing and threat analysis. Some tools send data directly to a cloud server hosted by the vendor that performs log analysis. No human-readable logs are left on the device or in the cloud. Even if it is done correctly, many organizations do not want their company data to be on a system other than the company's. Windows OS is the most used operating system in many companies, and most tools are developed for Windows first and then for macOS.

[0009] A kernel extension may be code that runs under the highest permissions on macOS (e.g., the first operating system) and may be a necessary link in the execution chain for related operations. Any errors in that code may cause catastrophic errors. A kernel extension that works with application execution may be a required step every time an app runs, regardless of whether the kernel module is doing anything with that particular application.

[0010] Other challenges for existing solutions include the low level of documentation for macOS, and the limited (and sometimes inadequate) documentation from Oracle's Sun operating system. Some security application vendors are more focused on blocking potential threats rather than reported threats.

[0011] Very few security applications are developed specifically for macOS, as macOS is typically a secondary platform and not the primary development focus, resulting in system crashes.

[0012] The present disclosure seeks to address one or more of these aforementioned problems. The background statements within this disclosure are generally provided for the purpose of presenting the content of the disclosure. Unless otherwise indicated in this disclosure, the content discussed in this section is not made prior art to the claims of this application by its incorporation into this section, nor is it an admission or suggestion that it is prior art. Summary of the Invention

[0013] According to certain aspects of the present disclosure, a non-transitory computer-readable medium, system, and method are disclosed for monitoring security events. Each of the examples disclosed in this disclosure includes one or more of the features described in connection with any of the other disclosed examples.

[0014] In one example, a computer implemented method can be used for monitoring security events, the method including one or more processors receiving data from a security module of a first operating system, the one or more processors defining an audit class data filter for collection by a security event monitoring application, the one or more processors receiving a detail level of the audit class data filter as a detail level defining an amount of audit class data collected, the one or more processors filtering the data based on the detail level of the audit class data filter, the one or more processors comparing the data to the audit class data filter, the one or more processors deleting the data if the data does not match the audit class data based on the comparison of the data to the audit class data filter, and the one or more processors filtering the data and a set of blacklists. the one or more processors capturing audit event data that is part of the audit class data and that relates to actions taken by the first computing device, the one or more processors determining at least one token for attributes of an audit event based on a token identifier, the one or more processors parsing the at least one token into a common structure format, and the one or more processors outputting the data in the common structure format based on a comparison of the data with the audit class data filter and the blacklisted values.

[0015] According to another aspect of the present disclosure, a non-transitory computer readable medium for monitoring security events is provided, the non-transitory computer readable medium storing instructions that, when executed by one or more processors, configure the one or more processors to: receive data from a first operating system; define an audit class data filter for collection by a security event monitoring application; compare the data to the audit class data filter; compare the data to a set of blacklisted values; and output data in a common structure format by the one or more processors based on a comparison of the processed data to the audit class data filter and the blacklisted values.

[0016] According to yet another aspect of the present disclosure, a computer-implemented method may be used for monitoring security events, the method including: the one or more processors receiving data from a first operating system, the one or more processors at least one of: (1) comparing the data to an audit class data filter and / or (2) comparing the data to a set of blacklisted values, and the one or more processors outputting data in a common structure format based on a comparison of the processed data to the audit class data filter and the blacklisted values.

[0017] Additional objects and advantages of the disclosed embodiments will be set forth in part in the detailed description of the invention which follows, and in part will be obvious from the detailed description, or may be learned by practice of the disclosed embodiments.

[0018] It is to be understood that both the foregoing general description and the following detailed description of the invention are exemplary and explanatory only and are not intended to be limiting to the disclosed embodiments, as claimed. [Brief description of the drawings]

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various representative embodiments and, together with the description, serve to explain basic principles of the disclosed embodiments.

[0020] [Figure 1] 1 illustrates a representative environment in which the systems, methods, and other aspects of the present disclosure may be implemented.

[0021] [Diagram 2] 1 illustrates an exemplary flow diagram for security event monitoring according to one aspect of the present disclosure.

[0022] [Diagram 3] 1 illustrates an exemplary flow diagram for security event monitoring using filters, according to one aspect of the present disclosure.

[0023] [Figure 4] 1 illustrates an exemplary flow diagram for event token processing according to one aspect of the present disclosure.

[0024] [Diagram 5] 1 illustrates an exemplary flow diagram for configuring security event monitoring according to one aspect of the present disclosure.

[0025] [Figure 6] 1 illustrates an exemplary flow diagram of cross-reference control according to one aspect of the present disclosure.

[0026] [Figure 7] 1 illustrates an exemplary flow diagram of a detailed cross-reference engine process according to one aspect of the present disclosure.

[0027] [Figure 8] 1 illustrates an exemplary flow diagram for updating a configuration of a security event monitoring tool according to one aspect of the present disclosure.

[0028] [Figure 9] 1 illustrates a representative computing device or system upon which embodiments of the present disclosure or portions thereof may be implemented. Detailed Description of the Invention

[0029] The subject matter of this specification will now be described more fully with reference to the accompanying drawings, which are a part of this application and which, by way of example, show certain representative embodiments. Any embodiment or implementation described in this disclosure as "representative" should not be construed as, for example, a preferred or advantageous example over other embodiments or implementations, but rather is intended to reflect or indicate that the embodiment is an "example" embodiment. The subject matter may be embodied in a variety of different forms, and as such, it is intended that the subject matter covered by and recited in the claims be construed as not being limited to the representative embodiments described in this disclosure. Representative embodiments are presented as examples only. Similarly, it is intended that the subject matter recited and covered by the claims have a reasonable breadth. Among other things, for example, the subject matter may be embodied as a method, an apparatus (device), a component, or a system. Thus, the embodiments may take the form of, for example, hardware, software, firmware, or any combination thereof (but excluding software per se). Accordingly, the following detailed description is not intended to be taken in a limiting sense.

[0030] Throughout the specification and claims, terms may have a nuanced meaning beyond the explicitly stated meaning as suggested or implied in the context. Similarly, the phrase "in one embodiment" as used in this disclosure does not necessarily refer to the same embodiment, and the phrase "in another embodiment" as used in this disclosure does not necessarily refer to separate embodiments. For example, the subject matter described in the claims is intended to include combinations of the representative embodiments in whole or in part.

[0031] The terms used below may be interpreted in their broadest reasonable sense, even when they are used in connection with the detailed description of certain examples of the present disclosure. Indeed, certain terms may be emphasized below. However, any terms intended to be interpreted in any limited sense will be expressly and specifically defined as being limited in this detailed description of the invention section. Both the general description above and the detailed description of the invention below are representative and explanatory only, and are not limiting, such as the features described in the claims.

[0032] In this disclosure, the term "based on" means "based at least in part on." The singular forms "a," "an," and "the" include plural referents unless the context dictates otherwise. The term "exemplary" is used in the sense of "example" rather than "ideal." The word "or" is intended to be inclusive, meaning either, any, some, or all of the listed items. The words "comprises," "comprising," "includes," "including," and variations thereof are intended to cover non-exclusive inclusion such that a process, method, or product that includes recited elements does not necessarily include only those elements, but may also include other elements not expressly recited, or elements inherent in the process, method, article, or device. Relative terms such as "substantially" and "generally" are used to indicate possible variations of ±10% of the stated or understood value.

[0033] As discussed above, software security solutions may not provide sufficient protection and may bring additional stability to a computing device. Thus, there is a need for a fully automated, intelligent, programmable system configured to detect an executable action or activity on a computing system, provide an alert indicating that an executable action or activity has been initiated on the system, verify the validity of the executable action or activity, process the executable action or activity if valid, and if not, generate a response that allows the action or activity to proceed with an alert or to stop or reduce the action or activity, and / or monitor and record such activity or activity.

[0034] The embodiments of the present disclosure relate to a system or method that can act as one or more of the security behavior detectors. For example, the systems and methods disclosed in the present disclosure may detect anything (e.g., software) that runs on a computer running a first operating system, such as macOS™, or anything that authenticates to that computer (e.g., software or a real person). The system then takes that detected data, formats it so that fields are named the same or similarly enough to the like events in a second operating system (e.g., Windows™), and writes it to a log file that may be specially formatted in such a way that a log collection tool can easily collect it. As used in the present disclosure, the first operating system may be a specific operating system selected from, for example, the macOS™ series or any operating system provided by Apple™, and the second operating system may be an operating system selected from the Microsoft™ OS products (e.g., Windows™).

[0035] The present disclosure describes systems and methods designed for real-time streaming of curated security event data and generation of data objects in a common data structure that can be analyzed by multiple different tools. For example, it receives streaming data of dynamic or unknown length audit content and parses the content into a structured data format that includes labeled pieces of content in a structured format that is easy to analyze. Additionally, the present disclosure may be designed to have low impact on computer resources (e.g., CPU, memory, etc.) and user experience.

[0036] Additionally, the disclosure describes an endpoint detection and response (EDR) tool having functionality such as monitoring file system changes and creations; collecting event data regarding processes, authentication, and critical system changes; translating collected and detected data fields into the field schema of a second operating system (e.g., Windows™); enriching a formatted results stream with cross-reference information from the detected data; a device quarantine function that shuts down all data connections except to a predefined device management server in response to a predefined action or event (e.g., in response to an Apple™ configuration profile being delivered to a device); and / or outputting the entire formatted results data (e.g., JSON, csv, xml) directly to a server defined by one or more configurations.

[0037] The OpenBSM API can be difficult to use and does not provide the flexibility required to collect corrected audit_event types because the default filter classes are overly broad and include a lot of irrelevant data. A system or method according to the present disclosure can solve these API problems and can run multiple levels of audit_event filters to collect only the relevant data. The print engine of the present disclosure is customizable and can output collected event data into JSON or other structured data formats that are easily readable by humans and machines.

[0038] A system according to the present disclosure may stream only relevant audit_events from OpenBSM and format the audit_events for easy collection by existing enterprise security tools. In some implementations, a specific class of audit_events may be declared for collection, and in some implementations, the audit_events may be further filtered from that class to collect only relevant and necessary data. The filtered audit_events may then be compared to a blacklist filter that may remove audit_events that have specific words or phrases in them. Audit_events that pass both filter tests may then be output to the local computer file system or forwarded over a network to a log collection server.

[0039] Referring now to the drawings, FIG. 1 illustrates a representative environment 100 in which the systems, methods, and other aspects of the present disclosure may be implemented. The environment 100 may include at least one (i.e., one or more) first computing device 105, at least one (i.e., one or more) second computing device 106, a network 110, and at least one (i.e., one or more) storage device 120. The at least one first computing device 105 and the at least one second computing device 106 are connected to the network 110. The network 110 may be any suitable network or combination of networks and may support any suitable protocol suitable for communicating data between various components in the system environment 100. The network 110 may include a public network (e.g., the Internet), a private network (e.g., a network within an organization), or a combination of public and / or private networks. The at least one storage device 120 may be a local hard drive, a network server, or any other user-defined destination repository.

[0040] The at least one first computing device 105 and the at least one second computing device 106 may be operated by one or more users. Examples of the first computing device 105 and the second computing device 106 may include a smartphone, a wearable computing device, a tablet computer, a laptop computer, and a desktop computer. The first computing device 105 may have various software and a specific operating system (first operating system) installed on the computing device. For example, the first operating system may be macOS (trademark) or any operating system provided by Apple (trademark). The second computing device 106 may have various software and a specific second operating system installed on the computing device. For example, the second operating system may be an operating system different from the first operating system, such as Windows (trademark), or any operating system provided by Microsoft (trademark), or any open source operating system, etc.

[0041] Environment 100 may include one or more first and second computing devices configured to collect, process, transmit, and / or receive data. In general, when environment 100 is described as performing an operation that collects, processes, transmits, or receives data, it is understood that the operation may be performed by the computer system. In general, the computer system may include one or more computing devices such as those shown in connection with FIG. 7 below.

[0042] FIG. 2 illustrates an exemplary flow method 200 for security event monitoring according to one aspect of the disclosure. Method 200 may begin with step 201 of collecting data by a Basic Security Module (BSM). The BSM may be a software module that generates a detailed audit trail for all operations on the first computing device 105. The BSM may describe a set of system calls and library interfaces for managing audit records, and a token stream file format that allows for extensible and generalized audit trail processing. The data collected by the BSM may be related to running processes (e.g., software execution), authentication processes (e.g., software authentication or user authentication), connection processes (e.g., network connections, hardware connections, or cable connections), and / or other processes on the first computing device 105. The BSM may be installed on the first computing device 105, and in one embodiment may be OpenBSM. After collection by the BSM, the collected data may be streamed to a security event monitoring application in step 202, which may declare audit classes for collection. The audit classes may be audit events grouped into logical categories. An example of an audit class may be actions taken by the CPU, network, and processes of the first computing device 105 related to file creation.

[0043] In step 203, the security event monitoring application may parse the stream of audit class data to obtain predefined audit events. The audit events may be actions generated by the BSM in response to actions taken by the CPU on the computer running the first operating system. The audit events may be actions related to security operations and / or application execution. Each auditable event is defined in the file by an identifying name, an event number, a set of preselected classes, and a short description. If an audit event is found to match a predefined audit event, then in step 204 the audit event may be removed from the stream of collected data, thereby generating a stream of filtered audit events. The stream of filtered audit events may then be checked or parsed for blacklisted strings in step 205. In this step, the stream of filtered audit events may be compared to one or more blacklist filters. If any audit event matches one or more blacklist filters, then in step 206 the matching audit event may be removed from the stream of audit events. In step 207, the stream of audit events that match the predetermined audit events but do not match one or more blacklist filters may be output to a local computer file system or forwarded over a network to a logging server, which may correspond to at least one storage device 120.

[0044] FIG. 3 illustrates an exemplary method 300 for security event monitoring using filters according to one aspect of the disclosure. The method 300 may be performed on a first computing device 105 and may begin at step 301. At step 301, a BSM kernel module resident in the kernel space of a first operating system of the first computing device 105 may log activities and information related to activities performed by and ways in which the first computing device 105 performs. The activity and information log may include one or more streams of data describing operations, failures, and changes occurring on or through the first operating system 105. The activity and information collection may be accessed at step 302 through calls to a pseudo device such as auditpipe. A security event monitoring application may call the pseudo device at step 303 to receive the activity and information collection data stream. The security event monitoring application may be a daemon process that may run invisibly in the background of the first operating system outside of the kernel space. The daemon process may run with system (e.g., root) permissions or may run on behalf of a specific user. Upon invocation of the security event monitoring application, a configuration of specific audit classes to be monitored and collected from the pseudo device may be defined in step 304.

[0045] In step 305, the binary encoded audit event may be captured by the security event monitoring application and stored in memory (e.g., storage device 120). In step 306, the classification process may be completed by classifying the captured audit event into attributeable and non-attributable events. In step 307, a comparison may be made between the collected audit event and the audit event types in the predefined filter, and if the collected audit event does not match the audit event types in the predefined filter, then in step 308, the collected audit event may be deleted from memory (e.g., storage device 120). If the collected audit event matches the audit event type in the predefined filter, then in step 309, a loop may begin for each token line in the binary encoded audit event. A token may be a sequence of audit data and may be stored in binary format. Each token may describe / represent an attribute of the audit event, such as a process, a path, or other object. Each token may have a token type identifier and associated data specific to the token. In step 310, it may be determined whether there is a filter configured for the type of token line entered. If a filter is configured for the input token type, then in step 311, the token line may be examined to determine whether it contains blacklist criteria. If it is determined that the token line contains blacklist criteria, then in step 312, the audit event to which the token belongs may be deleted from memory. If the determination in step 310 or step 311 is negative (e.g., there is no filter configured for the input token line type or the token line does not contain blacklist criteria), then in step 313, the token line may be parsed into a structured data format recognizable by a second operating system (e.g., JSON text event format, or csv, xml, etc.) and stored in memory (e.g., storage device 120).

[0046] In step 314, it is determined whether there are any other tokens in the audit event to process. If there are no other tokens in the audit event to process, then in step 315, it is determined whether a third filter is defined. If a third filter is defined, then in step 316, the collected audit event may be compared to the third predefined filter. If the audit event matches the third predefined filter, then in step 317, the audit event may be deleted from memory. If a third filter is not defined or if there are no audit events that match the third predefined filter, then in step 318, a complete structured data format event may be assembled and in step 319, the complete structured data format event may be logged and saved to storage 120. The complete structured data format event may include multiple structured data formats (e.g., JSON stanzas) that may be combined to create a structured data object (e.g., a JSON object).

[0047] FIG. 4 illustrates an exemplary method 400 of event token processing according to one aspect of the disclosure. The method 400 may be executed on a first computing device 105 and may begin with step 401, which involves collecting binary audit events that are streamed to a security event monitoring application resident on the first computing device 105. Each binary audit event may include at least one token (e.g., Token 1 through Token N). In step 402, each token in the audit event may be retrieved and received by a structure parsing engine of the security event monitoring application for mapping processing. In step 403, the token may be matched to an audit token type, and in step 404, the token may be mapped to a corresponding structured data format for the audit token type. In one embodiment, JSON may be used for the structured data format, and event lines may be mapped to corresponding JSON stanzas. Of course, other types of structured data formats may be utilized. Examples of header token mappings may be "EVENT-ID-LABEL "event-id", "EVENT-NAME-LABEL "event-name", "TIMESEC_LABEL "time_seconds_epoch", "TIMEMS_LABEL "time-milliseconds-offset", "VERSION-LABEL "version", "EVENT-MODIFIER "event-modifer", "NA-OR-A-EVENT-LABEL "is-non-attributeable-event", "FAILED_EVENT_LABEL "is_failed_audit_event". Other mappings may also be used to map the event naming convention of a first operating system to a naming convention recognized by a second operating system.Once the mapping process is complete, the output may be added to a final event record in memory or storage 120 in the first computing device in step 405. In step 406, a determination may be made as to whether there are more tokens in the audit event. If so, method 400 returns to step 402 where more tokens are received and parsed. Once all tokens in the audit event have been parsed and mapped to a corresponding structured data format, then in step 407, the final event formatted in a structured data format (e.g., JSON) may be stored in memory or storage 120 in the first computing device, and in step 408, the formatted event is logged at the first computer or storage 120, and the resulting structured data (e.g., JSON) object may have all relevant data from a single binary event.

[0048] FIG. 5 illustrates a method 500 for configuring security event monitoring according to one aspect of the disclosure. Method 500 may begin at step S1, where a feature list configuration file formatted for a first operating system may be loaded into a security event monitoring application 502 resident on the first computing device 105. The security event monitoring application 502 may read feature list file 501 to determine feature list key and feature list value combinations at step S2. The feature list file 501 may be used to configure a level of detail for the set of collection filters. There may be three levels of detail corresponding to the relative security risk of the audited system and a recommended level of information to be collected. In one embodiment, the level of detail may correspond to the relative security risk of the audited system as defined, for example, by a published risk management framework (e.g., SP800-37 of the National Institute of Standards and Technology). Examples of the three levels of detail and corresponding information to be collected may be as follows: “Log Level 1” (i.e., first log level) 503: Log level 1 may represent the lowest level of detail (lowest risk or “lowest risk level”) and may collect information regarding i) application execution, ii) scripts and interactive terminal commands, iii) all of the authentication prompts and authentication results (e.g., login), and / or iv) authentication prompts and authentication results (e.g., is user X allowed to do event Y). “Log Level 2” (i.e., a second log level different from the first log level) 504: Log level 2 may represent a medium level of detail (e.g., a higher risk level than the first log level or a “medium risk level”) and may collect information regarding i) all of the level 1 logged events, ii) application network connection creation, iii) scripts and interactive terminal network connections, and iv) web browser connection history (e.g., browser logs)."Log Level 3" (i.e., a third log level different from both the first log level and the second log level) 505: Log level 3 may represent the highest level of detail (e.g., a higher risk or "highest risk level" than the second log level) and may collect information regarding i) all of the logged events at levels 1 and 2, ii) inter-process communication events, and iii) additional detail on event types collected at the lower logging levels. Although three levels of detail are described in this disclosure, slightly different levels of detail are within the scope of this disclosure.

[0049] In other embodiments, "log level 1", "log level 2", and "log level 3" correspond to different risk levels. Notably, in some embodiments, the level of detail does not directly correlate to the risk level. For example, "log level 1" (i.e., the first log level) 503, which may represent the lowest level of detail, may have a risk level of "medium risk level" or "highest risk level". "log level 2" (i.e., a second log level different from the first log level) 504, which may represent a medium level of detail, may have a risk level of "lowest risk level" or "highest risk level". "log level 3" (i.e., a third log level different from the first and second log levels) 505, which may represent the highest level of detail, may have a risk level of "lowest risk level" or "medium risk level".

[0050] After the feature list key-value pairs are retrieved in step S2, an appropriate log level may be determined by the security event monitoring application. If log level 1 is desired, then in step S3, the desired data to be collected for the level 1 class may be defined on the pseudo device's auditpipe and a filter for that level class may be executed in step S4. The collected data may then be sent to the security event monitoring application filter engine in step S5 for parsing. If log level 2 is desired, then in step S6, the desired data to be collected for the level 2 class may be defined on the pseudo device's auditpipe and a filter for that level class may be activated in step S7. The collected data may then be sent to the security event monitoring application filter engine in step S8 for parsing. If log level 3 is desired, then in step S9, the desired data to be collected for the level 3 class may be defined on the pseudo device's auditpipe and a filter for that level class may be activated in step S10. The collected data may then be sent to the security event monitoring application filter engine for parsing in step S11. Once the collected data from the various log levels has been parsed by the security event monitoring application filter engine, the security event monitoring application then converts or normalizes the data into a format recognizable by the second operating system and outputs the data in step S12.

[0051] FIG. 6 illustrates an exemplary flow diagram 600 of cross-referencing control according to one aspect of the disclosure. As illustrated in FIG. 6, a security event monitoring application may collect information from multiple different sources on a first computing device and cross-reference the information for accuracy. Event data obtained from the BSM may be considered the authoritative record of truth for the event. In yet another embodiment, other sources of event data may also be considered the authoritative record of truth for the event. Attributes of the BSM records may be matched against other sources to cross-reference related events. Sources used for cross-referencing may include BSM records, network interface logs (e.g., traffic, successful connections, etc.), firewall logs (e.g., traffic, failed or successful connections), user security and privacy permission changes, application usage information from the first operating system, network interface configuration and attribute data, device location data from the first operating system, file change events, configuration change events, BSM socket notifications, and first operating system consolidated logs. Attributes used for cross-referencing may include process ID, auditToken, session ID, file or process path, audit user, valid user, BSM socket, unix file descriptor, signature ID, or timestamp. When an untrusted event is detected, it may be validated against the BSM data stored in the database. If the validation is successful, the trust level of the least trusted event may be increased or a higher trust level may be assigned. A trust score may be assigned to the incoming untrusted event based on the source of the untrusted event, the number of attributes that match trusted events, and / or the category of action reported by the event (e.g., login, configuration change, network activity, etc.). The trust score and information from the matching BSM event may be added to the untrusted event and sent to a customer-defined destination.The BSM events may be sent to a customer-defined destination and may be temporarily cached in a local database for cross-referencing purposes. The length of time that BSM events are stored in the cached database may vary based on the type of event. For example, high severity events may be stored for a longer period of time than low severity events. Furthermore, cross-referencing data from multiple trust levels may then be combined to create an enriched record of the event and action that occurred. The enriched record may be an untrusted event that is verified against and combined with the trusted BSM data. Trusted data from BSM may be added to the untrusted events to add additional context and consistent data fields for later analysis at a customer-defined destination.

[0052] The cross-referencing control process may be described in this disclosure with reference to FIG. 6. Flow diagram 600 may begin at step 601. At step 601, data regarding a trusted event (A) may be input to a security event monitoring application. The data regarding the trusted event (A) may be collected from the BSM or other trusted sources. If there is no untrusted event data to be cross-referenced, then at step 602, the data of the trusted event (A) may be sent directly to a log storage system (such as storage device 120). If there is untrusted event data for cross-referencing, then at step 603, the security event monitoring application may pass the data of the trusted event (A) to a cross-referencing engine. The security event monitoring application or the cross-referencing engine may also pass the data of the trusted event (A) to a temporary event cache where the data of the trusted event (A) may be stored at steps 604 and 605, respectively. At step 606, a determination may be made to determine whether there is an automatic response action decision. The automatic response action may include changing security-related settings or services on the system to increase or decrease the defensive posture of the protected system. These settings or services may modify the system behavior to reject local or external inputs that may place the computing device and / or enterprise data at potential risk. If the result of the determination is positive, then the actions taken and the resulting response may be logged in step 607 and sent to a log storage system in step 608. The log storage system may be storage device 120.

[0053] Upon obtaining data regarding an untrusted event (B), the untrusted event (B) data may be sent to a cross-referencing engine in step 609. The cross-referencing engine, having both trusted event (A) data and untrusted event (B) data, may add the verified untrusted event (B) data to the trusted event (A) data in step 610. In step 611, the aggregation of the untrusted event (B) data and the trusted event (A) data may be converted into composite enriched event (C) data, and in step 612, the composite enriched event (C) data may be sent to a log storage system (e.g., storage device 120).

[0054] FIG. 7 illustrates an exemplary flow diagram 700 of a detailed cross-reference engine process according to one embodiment of the present disclosure. Flow diagram 700 may begin with step 701. In step 701, reliable event (A) data may be collected. The reliable event (A) data may be collected from a reliable logging system and may include representative information such as "field 11", "field 22", and "field 33". In step 702, unreliable event (B) data may be collected. The unreliable event (B) data may be collected from an unreliable logging system and may include information not present in the reliable event (A) data. For example, the unreliable event (B) data may include representative information such as "field 1", "field 2", "field 3", "field AA", "field BB", and "field CC". The event (A) data and the event (B) data may be the result of another logging system reporting the same action that has already occurred. In step 703, the data fields of the event (A) may be mapped to the naming format of the event (B) based on a predefined mapping of the security event monitoring application and stored in a local database (e.g., storage device 120). In step 704, the data related to the event (B) may be used to look up the fields of the event (B) in the database of event (A) data. In step 705, a determination may be made to determine whether any of the data fields of the event (B) match data in the database of event (A). If the determination is negative, then in step 706, the data of the event (B) may be stored in a temporary cache for a short period of time, where the storage period may be associated with the type or category of the event (B). In step 707, the lookup process of the fields of the event (B) in the database of event (A) data may be retried, and if no match is found, then in step 708, the data of the event (B) may be deleted from memory or storage device.If a match is found as a result of the lookup process in step 705 or step 707, then in step 709, the trusted event (A) data and the untrusted event (B) data may be converted into composite enriched event (C) data. The composite enriched event (C) data may include representative information such as "field 1", "field 2", "field 3", "field 11", "field 22", and "field 33". The field data may indicate how an action is performed on the system and / or by which party (person or process). For example, the field data may include a process ID, an auditToken, a session ID, a file or process path, an audit user, a valid user, a BSM socket, a unix file descriptor, a signature ID, a timestamp, or associated data. In step 710, the composite enriched event (C) data may be sent to a log storage system (e.g., storage device 120).

[0055] 8 illustrates a method 800 of a security event monitoring tool response to a configuration update according to one aspect of the disclosure. Method 800 may begin at step 801, where a security event monitoring application daemon may listen and periodically scan for any configuration file changes. If an action setting is set and enforcement via a first operating system configuration profile is detected at step 802, then at step 803, the security event monitoring application may take the security response action assigned to the new configuration key-value pair. If no configuration file changes are detected, the process ends.

[0056] In one embodiment illustrated in FIG. 8, the new settings may be to disable all network connections on the first computing device as a result of pushing a configuration update to the first computing device. The security event monitoring application in step 803a may determine whether a whitelisted network connection is defined. If not, then in step 803b, a common mobile device management (MOM) configuration file may be checked for an allowed server URL. If an allowed server URL is found, then in step 803c, the MOM server URL may be added to the network connection whitelist. In step 803d, a new firewall configuration may be created with a whitelist of allowed network connections, application marker rules, and IP (Internet Protocol) space. In step 803e, the security event monitoring application may apply the generated configuration to verify whether a firewall service is active, and if not, in step 803f, activate the new firewall configuration to block all network connections except the whitelisted network connections. If the firewall configuration is active, then in step 803g, the security event monitoring application may maintain the configuration until a new configuration is created.

[0057] 9 illustrates a high-level functional block diagram of an exemplary computing device or system in which embodiments of the present disclosure or portions thereof, such as computer readable code, may be implemented. Additionally, each of the exemplary computing servers, databases, user interfaces, modules, and methods described above with reference to FIGS. 1-8 may be implemented in device 900 using hardware, software, firmware, tangible computer readable media having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. Hardware, software, or a combination thereof may implement each of the exemplary systems, user interfaces, and methods as described above with reference to FIGS. 1-8.

[0058] When programmable logic is used, the logic may be executed on a commercially available processing platform or a dedicated device. Those skilled in the art will recognize that embodiments of the disclosed subject matter may be practiced with a variety of computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functionality, and pervasive or miniature computers that may be incorporated into virtually any device.

[0059] For example, the embodiments described above may be implemented using at least one processor device and memory. A processor device may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor "cores."

[0060] Various embodiments of the present disclosure may be implemented using device 900 as described above in the examples of Figures 1-8. After reading this specification, it will become apparent to one of ordinary skill in the art how to implement embodiments of the present disclosure using other computer systems and / or computer architectures. Although operations may be described as sequential processes, in reality some of the operations may be performed in parallel, simultaneously, and / or in a distributed environment, using program code stored locally or remotely for access by single or multi-processor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0061] As shown in FIG. 9, device 900 may include a central processing unit (CPU) 920. CPU 920 may be any type of processor device, including, for example, any type of dedicated or general purpose microprocessor device. As will be appreciated by those skilled in the art, CPU 920 may also be a single processor in a multi-core / multi-processor system, which is a system operating alone, or may be a single processor in a cluster of computing devices operating in a cluster or server farm. CPU 920 may be connected to a data communications infrastructure 910, such as, for example, a bus, a message queue, a network, or a multi-core message transfer scheme.

[0062] Additionally, device 900 may include a main memory 940, e.g., random access memory (RAM), and may include a secondary memory 930. Secondary memory 930, e.g., read only memory (ROM), may be, e.g., a hard disk drive or a removable storage drive. Such removable storage drives may include, e.g., floppy disk drives, magnetic tape drives, optical disk drives, flash memory, etc. The removable storage drives in this example read from and / or write to the removable storage units in a well-known manner. The removable storage units may include floppy disks, magnetic tapes, optical disks, etc., which are read from or written to by the removable storage drives. As will be appreciated by those skilled in the art, such removable storage units typically include computer usable storage media having computer software and / or data stored thereon.

[0063] In alternative implementations, secondary memory 930 may include other similar means for allowing computer programs or other instructions to be loaded into device 900. Examples of such means may include program cartridges and cartridge interfaces (such as those found in video game devices), removable memory chips (such as EPROMs or PROMs) and associated sockets, and other removable storage units and interfaces that allow software or data to be transferred from a removable storage unit to device 900.

[0064] Device 900 may further include a communications interface ("COM") 960. Communications interface 960 allows software and data to be transferred between device 900 and external devices. Communications interface 960 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. The software and data transferred through communications interface 960 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 960. These signals may be provided to communications interface 960 via a communications path in device 900, which may be implemented using, for example, wires or cables, fiber optics, a telephone line, a cellular phone link, an RF link, or other communications channels.

[0065] The hardware elements, operating systems, and programming languages ​​of the device are conventional in nature and are assumed to be sufficiently familiar to those skilled in the art. The device 900 may further include input / output ports 950 for connecting input / output devices such as a keyboard, mouse, touch screen, monitor, display, etc. Of course, the various server functions may be distributed and executed on several similar platforms, thereby distributing the processing load. The server may also be executed by suitable programming of a computer hardware platform.

[0066] detail

[0067] Consistent with the above-described embodiments, and in accordance with the present disclosure, a system or method may collect security event logs from a computer executing a first operating system and store the logs in a common structural format (e.g., JSON, csv, xml, etc.) on one or more hard drives for ease of collection and analysis by security monitoring tools. Such a system or method may be performed to perform these steps without introducing security or stability issues to the computer executing the first operating system.

[0068] In one implementation, examples of advantages provided by the system disclosed in this disclosure may include: (1) Integrating with native macOS (first operating system) subsystems (e.g., OpenBSM) to collect activity and information about what macOS computers are doing and how they are operating; (2) Leveraging higher level permission codes (kexts) of the first operating system to collect forensically sound information and declare desired audit_classes to collect without requiring these higher level permissions via API access provided by the first operating system; (3) Collecting and translating binary OpenBSM events of unknown length, token (line) type, and content within token lines; (4) Filtering events from audit_classes based on the audit_event type defined in the header token of each OpenBSM event, removing audit_event types not defined at the active collection level; and (5) Normalizing collected data to fit Windows-based (second operating system-based) log collection or security tool naming conventions (e.g., mac login events to windows login events). (6) formatting the collected data so that it can be ingested natively into security operations tools already in use by the enterprise; (7) storing these renamed or formatted events in JSON log files on the audited systems for collection by security operations tools; (8) streaming the completed output data directly to a customer-hosted and customer-managed security monitoring server; and / or (9) taking action depending on an Apple™ configuration profile that configures a specific configuration file with specific key=value pairs (e.g., turning off all networks on the fly depending on the configured configuration file and via a configuration profile).

[0069] JSON is a human-readable format that organizes data into (key=value) fields. JSON is an open web standard for transmitting data and can be parsed by nearly all logging and security tools. Configuration profiles are the first operating system-specific device management payloads.

[0070] A system or method according to the present disclosure may not require a vendor kernel extension. In one or more embodiments, the system or method may utilize the OpenBSM kernel extension that ships with the first operating system.

[0071] The first operating system may continue to allow third party kexts in future versions of the operating system.

[0072] In one or more embodiments, the system or method may define the audit_classes and collection parameters to be collected on macOS' / dev / auditpipe.

[0073] In one or more embodiments, the system or method may filter the binary coded events collected from / dev / auditpipe to retain only audit_events that are predefined for collection.

[0074] Embodiments of the present disclosure may include normalization of events to Windows tools (second operating system). For example, rather than AUE_user_login (e.g., the event naming convention for the first operating system), log headers may be renamed so that existing second operating system tools can recognize first operating system login events in the same way (or in a manner sufficiently similar) as second operating system login events.

[0075] To increase accuracy, these normalizations may include, for example, manual input.

[0076] The disclosed method and system may include code portability within the first operating system. The disclosed system and method may run without modification on macOS, for example, from macOS 2012 to the latest beta version. This capability and portability is achieved by utilizing the kernel code of the first operating system (macOS), and the disclosed implementations may only run in a normal system context. This is in contrast to, for example, traditional security tools that run their own kext modules. Furthermore, the disclosed implementations may run on older systems (pre-2012) as well. Tools that leverage kexts may only run on a specific version of macOS (first operating system) and for a specific version of a security application to keep the system running normally.

[0077] The embodiments of the present disclosure may also satisfy stringent specifications of the first operating system on how modern security applications should be executed and configured on the first operating system. For example, the systems and methods disclosed in this disclosure may be executed on system context daemons in the following list of context levels from lowest to highest permission: (1) user specific actions, (2) user specific daemons, (3) all user daemons, (4) system context daemons, (5) system daemons specific to the first operating system, and (6) kernel context.

[0078] Application settings may be configured via plist format files in the first operating system. These files can be quickly applied and enforced via Apple's configuration profiles, which may be important in configuration management of the first operating system.

[0079] In one or more embodiments, the systems and methods of the present disclosure may be designed for real-time streaming of specially curated security event data with a common data structure that can be analyzed by many different tools.

[0080] In one or more embodiments, the present disclosure may be designed to have minimal impact on computer resources (e.g., CPU, memory, etc.) and user experience. This focus on user experience and monitoring rather than blocking process execution may be unique to the security space of the first operating system.

[0081] One or more embodiments may allow one or more capabilities to support a configuration profile of a first operating system implementing a settings file, a mobile device management (MOM) implementation, and all of these settings and actions may be created in one or more code associated with the systems or methods disclosed in this disclosure, rather than functionality provided by an operating system or MOM provider.

[0082] For example, a configuration profile having a setting that sets "shouldKillNetword?" to "true" may modify a system firewall setting to disable all network traffic on a computer. If a second setting, "allowedNetworklocations," whitelists certain websites, such as a corporate MOM server or a server of the first operating system, the computer can be remotely controlled to mitigate threats.

[0083] The systems or methods disclosed in this disclosure may not require extensive use of graphical user interfaces or visual elements.

[0084] In some implementations, the systems or methods disclosed in this disclosure may be a very light security tool, as other security tools will periodically slow down even the newest and fastest Macs.

[0085] All configuration can be done remotely using configuration profiles of the first operating system (macOS).

[0086] The systems or methods disclosed in this disclosure may not require recalling to their own "cloud", but rather the logs are stored locally until they are collected using the enterprise's logging tools.

[0087] In some embodiments, the system of the present disclosure collects only logs that have security or operational value.

[0088] Collecting all logs from OpenBSM may not be practical - in fact, the resource usage (CPU and storage) on the endpoints can slow down laptops and desktops excessively - and financially, storing more than 300MB per computer per day is prohibitively expensive in terms of licenses, hosted storage costs, and Internet bandwidth.

[0089] Collecting incorrect audit_classes for the first audit_event filter is CPU intensive. For example, collecting incorrect audit_classes on / dev / auditpipe has been observed to consistently cause CPU usage of over 40%.

[0090] The embodiments of the present disclosure help ensure that all relevant security events are captured. The collected audit_classes may include the type of audit_event and may be classified into categories such as network events, login events, and process executions. All audit_classes and audit_events may be configured by the original developers of the operating system that are installed by default on macOS. The success rate of detecting failure conditions that are negative outcomes may be high. For each action such as logging into the system, for example, 3-10 different audit_events may be generated. Each of these, for example, 3-10 audit_events, may contain different important information.

[0091] A system or method disclosed in this disclosure may define the audit_classes desired for collection from the audit kernel component on / dev / auditpipe, from which one or more embodiments disclosed in this disclosure may further filter the data stream to retain only audit_events from each relevant audit_class.

[0092] Embodiments of the present disclosure may include Kext-free application designs. For example, an embodiment may leverage code from the first operating system for kernel access, which may provide many stability and security benefits, but may also pose operational challenges such as tamper resistance.

[0093] A system or method according to the present disclosure may warn malicious applications or users with sufficient privileges about removing the tool from a computer system.

[0094] In one or more embodiments, the system may be vulnerable only to users or apps with "administrator" or higher privileges.

[0095] In one or more embodiments, the binaries and configuration files may be protected from malicious tampering.

[0096] In one or more embodiments, these protections force an attacker to take multiple actions to remove the tools described in this disclosure from a computing device, thus providing sufficient time to log a tampering event.

[0097] Associated files may be protected with a "uchg" flag native to the first operating system. "uchg" may require a second command, "nouchg", for all users and apps that can modify or delete the file. This change to a two-step configuration thwarts low-skilled attackers and provides sufficient time to log highly skilled attackers. All settings may be set using configuration profiles that are enforced at the kernel level by the first operating system. Malicious modifications to configuration files on the system will have no effect if configuration profiles are used. In one or more embodiments, applications that run in the background are automatically restarted if the application is terminated or "killed". Background process files are protected with the same "uchg" flag as other supported files.

[0098] To format the application output, in one implementation, JSON stanzas may be manually entered, thereby mapping the event naming conventions of a first operating system to the naming conventions of a security tool of a second operating system. Each stanza may be mapped to the OpenBSM audit token format. Each event may have multiple JSON stanzas that are ultimately combined to create a JSON object that represents the event. The filtered event may then be parsed into a JSON object. The flow of a single event through the parsing engine is described below. For example, a single binary audit_event is received by the parsing engine, the binary event is read token by token into the parser, the event lines are mapped to corresponding JSON stanzas, and the JSON stanzas from a single filtered event are combined into a JSON object. The resulting JSON object may contain all the data from a single binary event.

[0099] The systems and methods disclosed in this disclosure may not have a large percentage of the CPU available in the background, slowing down the system.

[0100] A large volume of events may be filtered by the first audit_event matching filter, and to achieve this capability the code must be highly optimized.

[0101] In some embodiments, the disclosed systems or methods do not block the threats they detect. In some cases, to block a threat, an application may require its own kext in the kernel, which may lead to other problems as discussed in this disclosure. However, it is believed that the disclosed systems and methods can block a threat if necessary.

[0102] In the foregoing description of representative embodiments of the invention, it will be appreciated that various features of the invention are sometimes grouped together in a single embodiment, figure, or description for the purposes of streamlining the disclosure and aiding in understanding one or more of the various inventive aspects. This method of disclosure, however, should not be interpreted as reflecting an intention that the invention requires more features than are expressly recited in each claim. Rather, as the claims reflect, inventive aspects lie in less than all features of a single, above-disclosed embodiment. Thus, the claims following the Detailed Description of the Invention are hereby expressly incorporated into this Detailed Description of the Invention, with each claim standing on its own as a separate embodiment of the invention.

[0103] Furthermore, although some of the embodiments described in this disclosure may include some features but not others included in other embodiments, it will be understood by those skilled in the art that combinations of features from different embodiments are within the scope of the present invention and are meant to form different embodiments. For example, in the following claims, any of the embodiments described in the claims may be used in any combination.

[0104] Thus, although certain embodiments have been described, those skilled in the art will recognize that other and further modifications may be made without departing from the spirit of the present invention, and it is intended that all such changes and modifications be claimed as being within the scope of the present invention. For example, functions may be added to or removed from the block diagrams, and operations may be interchanged between functional blocks. Steps may be added or removed from the described methods within the scope of the present invention. The subject matter disclosed above should be considered as illustrative and not limiting, and the appended claims are intended to cover all modifications, variations, extensions, and other implementations that fall within the true spirit and scope of the disclosure. Thus, to the maximum extent permitted by law, the scope of the disclosure shall be determined by the broadest possible interpretation of the claims and their equivalents, and shall not be limited or restricted by the above detailed description. Although various implementations of the disclosure have been described, it will be apparent to one of ordinary skill in the art that there are many more implementations that may be implemented within the scope of the disclosure. Thus, the disclosure is not intended to be limited, except as by the appended claims and their equivalents.

Claims

1. 1. A computer-implemented method for monitoring security events, comprising: one or more processors receiving data from a security module of the first operating system; the one or more processors defining an audit class data filter for collection by a security event monitoring application; the one or more processors receive the detail level of the audit class data filter as a detail level defining an amount of audit class data collected; the one or more processors filtering the data based on the detail level of the audit class data filter; the one or more processors comparing the data to the audit class data filters; the one or more processors delete the data if the data does not match the audit class data based on a comparison of the data to the audit class data filter; the one or more processors comparing the data to a set of blacklisted values; the one or more processors delete the data if, based on a comparison of the data to the set of blacklisted values, it is determined that the data matches one or more blacklisted values ​​in the set of blacklisted values; the one or more processors capture audit event data that is part of the audit class data and that relates to actions taken by the first computing device; The one or more processors determine at least one token related to an attribute of the audit event based on the token identifier; the processor parses the at least one token into a common structure format; The one or more processors output the data in the common structure format based on a comparison of the data to the audit class data filters and the blacklisted values.

2. The computer-implemented method of claim 1 , wherein the common structure format is at least one of JSON, csv, or xml.

3. receiving, by the one or more processors, a configuration file change for a first computing device executing the first operating system; 2. The computer implemented method of claim 1, further comprising the one or more processors: performing a responsive action by the security event monitoring application based on the configuration file change.

4. 1. A non-transitory computer readable medium for security event monitoring, the non-transitory computer readable medium storing instructions that, when executed by one or more processors, perform the following steps: the one or more processors receiving data from a first operating system; the one or more processors defining an audit class data filter for collection by a security event monitoring application; the one or more processors comparing the data to the audit class data filters; the one or more processors comparing the data to a set of blacklisted values; The one or more processors output data in a common structure format based on a comparison of the processed data to the audit class data filters and the blacklisted values. A non-transitory computer-readable medium that is instructions for configuring the one or more processors to perform a process.

5. 5. The non-transitory computer-readable medium of claim 4, further comprising the one or more processors deleting the data if, based on a comparison of the data to the audit class data filter, it is determined that the data does not match the audit class data.

6. 5. The non-transitory computer-readable medium of claim 4, further comprising the one or more processors deleting the data if, based on a comparison of the data to the set of blacklisted values, it is determined that the data matches one or more blacklisted strings in the set of blacklisted values.

7. The non-transitory computer-readable medium of claim 4 , further comprising the one or more processors capturing audit event data that is part of an audit class of data and that relates to actions taken by the first computing device.

8. The non-transitory computer-readable medium of claim 7 , further comprising the one or more processors determining at least one token for an attribute of the audit event based on the token identifier.

9. The non-transitory computer-readable medium of claim 8 , further comprising the one or more processors parsing the at least one token into the common structure format.

10. 10. The non-transitory computer-readable medium of claim 9, wherein the common structure format is at least one of JSON, csv, or xml.

11. 5. The non-transitory computer-readable medium of claim 4, further comprising the one or more processors receiving the detail level of the audit class filter as a detail level defining an amount of audit class data collected.

12. The non-transitory computer-readable medium of claim 11 , wherein the one or more processors further comprise filtering the data based on the verbosity level of the audit class filter.

13. receiving, by the one or more processors, a configuration file change for a first computing device executing the first operating system; The non-transitory computer-readable medium of claim 11 , further comprising the one or more processors: performing a responsive action by the security event monitoring application based on the configuration file change.

14. 1. A computer-implemented method for monitoring security events, comprising: the one or more processors receiving data from a first operating system; the one or more processors at least one of: (1) comparing the data to an audit class data filter; and / or (2) comparing the data to a set of blacklisted values; The one or more processors output data in a common structure format based on a comparison of the processed data to the audit class data filters and / or the blacklisted values.

15. 15. The computer implemented method of claim 14, further comprising the one or more processors deleting the data if, based on a comparison of the data to the audit class data filter, it is determined that the data does not match the audit class data.

16. 15. The computer-implemented method of claim 14, further comprising the one or more processors deleting the data if, based on a comparison of the data to the set of blacklisted values, it is determined that the data matches one or more blacklisted values ​​in the set of blacklisted values.

17. 15. The computer implemented method of claim 14, further comprising the one or more processors capturing audit event data that is part of an audit class of data and that relates to actions taken by the first computing device.

18. 20. The computer implemented method of claim 17, further comprising the one or more processors determining at least one token for an attribute of the audit event based on the token identifier.

19. 20. The computer implemented method of claim 18, further comprising the one or more processors parsing the at least one token into the common structure format, the common structure format being at least one of JSON, csv, or xml.

20. receiving, by the one or more processors, the detail level of the audit class data filter as a detail level defining an amount of audit class data collected; 15. The computer implemented method of claim 14, further comprising the one or more processors filtering the data based on the detail level of the audit class data filter.

Images