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 generally relate to monitoring processes performed in an operating system, and more specifically, to performing security-related actions in an operating system environment.

Background Art

[0002] Network attacks and cybersecurity are important issues for companies concerned about security. In all markets' business and regulatory environments, reliable auditing and logging measures are required for all computers connected to the network. Traditional security solutions can provide preventive endpoint protection for companies. In this case, the software reacts to new files entering the computing device, and if the file is recognized as malicious, the file is automatically prevented from being executed within the device. However, an attacker can still penetrate the computing device without activating such protection.

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

[0004] However, existing security software tools often ignore systems like OpenBSM that are built into the operating system, instead building their own collection and monitoring methods, frequently introducing security vulnerabilities into the operating system. Therefore, companies using existing security software may unknowingly be putting their computers at risk. Furthermore, log collection tools cannot capture logs generated by OpenBSM without applications or scripts that convert OpenBSM logs at predetermined intervals. The native OpenBSM log format is not designed for real-time auditing or collection.

[0005] Furthermore, collecting all events generated by OpenBSM would significantly slow down and render existing computer systems unusable. For example, observing the entire flow of events would generate additional events to detail that observation, creating an infinite loop. Because each event generation slows down the computer, this problem will not necessarily resolve itself over time.

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

[0007] Some tools prioritize proprietary code for monitoring, collecting, and blocking security events, ignoring macOS's native systems. Non-native toolsets require integration testing for every macOS subbuild. Vendor code can lead to system-wide instability and performance issues because it must approve all actions performed by the system before executing them. This legacy system requires vendor kernel extensions (kexts), which introduce the potential for critical security vulnerabilities. Kexts run at the lowest level of the operating system, and 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 to allow vendors to update their own tools. Updating macOS without updating vendor tools frequently renders systems requiring specialized IT support unusable. It is nearly impossible to consistently obtain the exact version corresponding 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 are cloud servers that perform log analysis and send data directly to vendor-hosted cloud servers. Human-readable logs do not remain on devices or in the cloud. Even if this were done correctly, many organizations do not want company data on systems outside of their own company. Windows OS is the most widely used operating system in many companies, and most tools are developed first for Windows and then later for macOS.

[0009] Kernel extensions may be code that runs under the highest permissions on macOS (for example, the first operating system), or they may be links necessary for the execution chain for related operations. Errors in that code can lead to catastrophic errors. Kernel extensions that work with application execution may be steps required for each application run, regardless of whether the kernel module does anything with that particular application.

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

[0011] Very few security applications are developed specifically for macOS. Typically, macOS is a secondary platform and not the primary focus of development, which can lead to system crashes.

[0012] This disclosure aims to address one or more of the aforementioned issues. The background information within this disclosure is generally provided for the purpose of presenting the content of this disclosure. Unless otherwise indicated in this disclosure, the content described in this section does not constitute, acknowledge as, or suggest prior art to the claims of this application by being incorporated into this section. [Overview of the project]

[0013] In some aspects of this disclosure, non-transient computer-readable media, systems, and methods are disclosed for the purpose of monitoring security events. Each example disclosed in this disclosure includes one or more features described in relation to any of the other disclosed examples.

[0014] In one example, a method performed by a computer can be used for monitoring security events. The method involves one or more processors receiving data from a security module of a first operating system; one or more processors defining an audit class data filter for collection by a security event monitoring application; one or more processors receiving the level of detail of the audit class data filter as a level of detail that defines the amount of audit class data collected; one or more processors filtering the data based on the level of detail of the audit class data filter; one or more processors comparing the data with the audit class data filter; one or more processors deleting the data if, based on the comparison of the data with the audit class data filter, it is determined that the data does not match the audit class data; and one or more processors comparing the data with a series of blacklists. This may include comparing the data with values ​​registered in the blacklist, and if, based on the comparison of the data with the values ​​registered in the series of blacklists, it is determined that the data matches one or more blacklisted values ​​among the series of blacklisted values, the one or more processors delete the data; the one or more processors capture audit event data relating to an Action performed by the first computing device, which is part of the audit class data; the one or more processors determine at least one token relating to the attributes of the audit event based on a token identifier; the processors parse the at least one token into a common structure format; and the one or more processors output data in the common structure format based on the comparison of the data with the audit class data filter and the values ​​registered in the blacklist.

[0015] In another aspect of the present disclosure, a non-temporary computer-readable medium is provided for monitoring security events, the non-temporary computer-readable medium storing instructions, the instructions being instructions that, when executed by one or more processors, cause 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 with the audit class data filter, compare the data with a set of blacklisted values, and output data in a common structure format based on the comparison of the processed data with the audit class data filter and the blacklisted values.

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

[0017] Additional objectives and advantages of the disclosed embodiments are some of those stated in the following detailed description of the invention, some of those that are evident from the detailed description, and some that can be understood by carrying out the disclosed embodiments.

[0018] It should be understood that both the foregoing general description and the following detailed description of the invention are merely illustrative and explanatory, and are not intended to limit the disclosed embodiments to the content described in the claims.

Brief Description of the Drawings

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

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

[0021] [Figure 2] Shows a representative flowchart of security event monitoring according to one aspect of the present disclosure. [[ID=二十]]

[0022] [Figure 3] Shows a representative flowchart of security event monitoring using a filter according to one aspect of the present disclosure.

[0023] [Figure 4] Shows a representative flowchart of event token processing according to one aspect of the present disclosure.

[0024] [Figure 5] Shows a representative flowchart of the configuration of security event monitoring according to one aspect of the present disclosure.

[0025] [Figure 6] Shows a representative flowchart of cross-reference control according to one aspect of the present disclosure.

[0026] [Figure 7] Shows a representative flowchart of a detailed cross-reference engine process according to one aspect of the present disclosure.

[0027] [Figure 8] This diagram shows a typical flow chart of updating the configuration of a security event monitoring tool according to one aspect of this disclosure.

[0028] [Figure 9] The following are representative computer devices or systems in which embodiments or parts thereof of this disclosure may be implemented. Detailed description of the invention

[0029] The subject matter of this specification will be described more fully below with reference to the accompanying drawings. The drawings are part of this application and illustrate specific representative embodiments by exemplary means. Embodiments and implementations described in this disclosure as “representative” are not to be interpreted as preferred or advantageous examples, for example, that outperform other embodiments or implementations, but rather are intended to reflect or indicate that the embodiment is an “exemplary” embodiment. The subject matter can be embodied in a variety of different forms and is therefore covered in the claims and the subject matter described in the claims is not intended to be limited to the representative embodiments described in this disclosure. Representative embodiments are presented only as examples. Similarly, the subject matter described in the claims and covered by the claims is intended to have a reasonable breadth. In particular, for example, the subject matter may be embodied as a method, apparatus (device), component, or system. Thus, embodiments may take the form of, for example, hardware, software, firmware, or any combination thereof (except software itself). Accordingly, the detailed description below is not intended to be interpreted as restrictive.

[0030] Throughout the specification and claims, terms may have nuances beyond their explicitly stated meaning, such as those implied or suggested in the context. Similarly, the phrase “in one embodiment” as used in this disclosure does not necessarily refer to the same embodiment, nor does the phrase “in another embodiment” as used in this disclosure necessarily refer to a distinct embodiment. For example, the subject matter described in the claims is intended to include all or some combinations of representative embodiments.

[0031] The terms used below may be interpreted in their broadest reasonable sense, even when used in connection with the detailed description of a particular example of this disclosure. In fact, certain terms may be emphasized below. However, any term intended to be interpreted in a restrictive sense is clearly and specifically defined as restrictive in the chapter describing the detailed invention. Both the above general description and the following detailed description of the invention are representative and descriptive only, and not restrictive like the features described in the claims.

[0032] In this disclosure, the word "based on" means "based on at least partially." The singular forms "a," "an," and "the" refer to multiple objects unless otherwise indicated by the context. The word "representative" is used to mean "example" rather than "ideal." The word "or" means comprehensive and refers to either, any, several, or all of the listed items. "Includes" and its variations are intended to cover non-exclusive inclusion, meaning that a process, method, or product containing the enumerated elements does not necessarily not include anything other than those elements, but may also include other elements not explicitly enumerated, or elements inherent to those processes, methods, articles, or devices. Relative words such as "substantially" and "generally" are used to indicate a possible variation of ±10% of the stated or understood values.

[0033] As mentioned above, software security solutions may not provide sufficient protection and may even bring further stability to computing devices. Therefore, there is a need for a fully automated intelligent programmable system configured to detect, for example, executable actions and activities on a disclosed system, issue warnings when such actions or activities are initiated on the system, verify the validity of such actions or activities, process them if valid, or, if not valid, create a response that proceeds with the action or activity accompanied by a warning, or stops or reduces the action or activity, and / or monitor and record such activities or actions.

[0034] Embodiments of the present disclosure relate to systems or methods capable of performing one or more security activity detector roles. For example, the systems and methods disclosed herein may detect anything (e.g., software) running on a computer on which a first operating system, such as macOS®, is running, or anything (e.g., software or a real person) authenticated to that computer. The system then extracts the detected data, formats it so that the fields are given the same or sufficiently similar names as similar events in a second operating system (e.g., Windows®), and writes it to a log file which may be specially formatted in a way that allows a log collection tool to 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 Microsoft® OS products (e.g., Windows®).

[0035] This disclosure describes a system and method designed for real-time streaming of curated security event data and generating data objects with a common data structure that can be analyzed by multiple different tools. For example, it takes streaming data of dynamic or unknown length audit content and parses that content into a structured data format that includes labeled pieces of content in an easily analyzable structured format. Furthermore, this disclosure may be designed to have minimal impact on computing resources (e.g., CPU and memory) and user experience.

[0036] In addition, this disclosure describes an endpoint discovery and response (EDR) tool having functions such as, for example, monitoring file system changes and creations; collecting event data relating to processes, authentications, and significant system changes; translating collected and detected data fields into a field scheme of a second operating system (e.g., Windows®); enriching a formatted result stream with cross-referencing information from detected data; device quarantine functionality that shuts down all data connections except 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 direct output of the entire formatted result data (e.g., JSON, csv, xml) to a server defined by one or more settings.

[0037] The OpenBSM API can be difficult to use, and its default filter classes are extremely broad, including a lot of irrelevant data, thus lacking the flexibility needed to collect corrected audit_event types. The system or method relating to this disclosure can solve the problems of these APIs and can perform multiple levels of audit_event filtering to collect only the relevant data. The printing engine relating to this disclosure is customizable and can output the collected event data in JSON or other structured data formats that are easily readable by humans and machines.

[0038] The system relating to this disclosure can stream only relevant audit_events from OpenBSM and may format those audit_events so that they can be easily collected by existing enterprise security tools. In one implementation, a specific class for audit_events to be collected may be declared. In that implementation, the audit_events may be further filtered from that class to collect only the relevant and necessary data. These filtered audit_events may then be compared with a blacklist filter that can remove audit_events containing specific words or phrases. Audit_events that pass both filters may then be output to the local computer file system or transferred to a log collection server over the network.

[0039] Referring to the attached drawings, Figure 1 shows a typical environment 100 on which the system, method, and other embodiments of the present disclosure can 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 or a combination of preferred networks and may correspond to any appropriate protocol suitable for data communication 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., an organization's network), 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 above-mentioned at least one first computing device 105 and 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 smartphones, wearable computing devices, tablet computers, laptop computers, and desktop computers. The first computing device 105 may have various software and a specific operating system (first operating system) installed on it. For example, the first operating system may be macOS® or any operating system provided by Apple®. The second computing device 106 may have various software and a specific second operating system installed on it. For example, the second operating system may be a different operating system from the first operating system, and may be, for example, Windows® or any operating system provided by Microsoft®, or any open-source operating system.

[0041] Environment 100 may include one or more first and second computer devices configured to collect, process, send, and / or receive data. Generally, where Environment 100 is described as performing operations to collect, process, send, or receive data, it is understood that such operations can be performed by the computer system. Generally, the computer system may include one or more computing devices as shown in relation to Figure 7 below.

[0042] Figure 2 shows a typical flow method 200 for security event monitoring according to one aspect of the present disclosure. Method 200 may begin with step 201, in which data is collected by a Basic Security Module (BSM). The BSM may be a software module that generates a detailed audit trail for all operations on a 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 enables extensible and generalized audit trail processing. The data collected by the BSM may pertain to execution processes (e.g., software execution), authentication processes (e.g., software authentication and 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 some embodiments, 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. Audit classes may be audit events grouped into logical categories. An example of an audit class may be actions performed by the CPU, network, and processes of the first computing device 105 related to file generation.

[0043] In step 203, the security event monitoring application may parse the stream of audit class data to obtain a predetermined audit event. An audit event may be an action generated by the BSM in response to an action performed by the CPU on a computer running the first operating system. An audit event may also be an action relating to a security operation and / or application execution. Each auditable event is defined in a file by its distinguished name, event number, a set of pre-selected classes, and a short description. If an audit event is found to match a predetermined audit event, the audit event may then be removed from the stream of data collected in step 204 to generate a filtered stream of audit events. The filtered stream of audit events is then checked or parsed in step 205 for any blacklisted strings. In this step, the filtered stream of audit events may be compared with one or more blacklist filters. If any audit event matches one or more blacklist filters, the matching audit event may then be removed from the stream of audit events in step 206. In step 207, a stream of audit events that match a predetermined audit event but do not match one or more blacklist filters may be output to the local computer file system or forwarded to a log collection server over the network. The local computer file system or the log collection server may correspond to at least one storage device 120.

[0044] Figure 3 illustrates a typical method 300 for security event monitoring using a filter, according to one aspect of the present disclosure. Method 300 can be performed on a first computing device 105 and may begin from step 301. In step 301, a BSM kernel module residing in the kernel space of the first operating system of the first computing device 105 may log activities and information about activities performed by the first computing device 105 and activities and information about how the first computing device 105 performs. The activity and information log may include one or more streams of data describing operations, failures, and changes that occur on or through the first operating system 105. The collection of activities and information may be accessed in step 302 through a call to a pseudo-device such as auditpipe. A security event monitoring application may call the pseudo-device in step 303 to receive the data stream of activity and information collection. The security event monitoring application may be a daemon process, which may be a process that runs outside the kernel space, invisibly in the background of the first operating system. The daemon process may run with system (e.g., root) permissions, or it may run for a specific user. When the security event monitoring application is started, step 304 may define the configuration of specific audit classes to be monitored and collected from pseudo-devices.

[0045] In step 305, the audit event encoded in binary format may be captured by a 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 attribute-able events and non-attribute-able events. In step 307, the collected audit event may be compared with audit event types in a predefined filter. If the collected audit event does not match an audit event type 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 an audit event type in the predefined filter, then in step 309, a loop may be started for each token line in the audit event encoded in binary format. A token may be a series of audit data, which may be stored in binary format. Each token may describe / represent an attribute of the audit event, such as a process, path, or other object. Each token may have a token type identifier and associated token-specific data. In step 310, it may be determined whether there is a filter configured for the type of input token line. If a filter is configured for the input token type, then in step 311, the token row may be examined to determine whether the token row contains blacklist criteria. If it is determined that the token row contains blacklist criteria, then in step 312, the audit event to which the token belongs may be removed from memory. If the determination in step 310 or step 311 is negative (for example, there is no filter configured for the input token row type, or the token row does not contain blacklist criteria), then in step 313, the token row 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 other tokens to be processed within the audit event. If there are no other tokens to be processed within the audit event, 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 with the third predefined filter. If the audit event matches the third predefined filter, then in step 317, the audit event may be removed 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, an event in complete structured data format may be assembled, and in step 319, the event in complete structured data format may be logged and stored in storage device 120. The event in complete structured data format may include multiple structured data formats (e.g., JSON stanzas) that, when combined, may create a structured data object (e.g., a JSON object).

[0047] Figure 4 illustrates a typical method 400 for event token processing according to one aspect of the present disclosure. Method 400 may be executed on a first computing device 105 and may begin from step 401. Step 401 collects audit events in binary format, which are streamed to a security event monitoring application residing on the first computing device 105. Each audit event in binary format may contain at least one token (e.g., token 1 to token N). In step 402, each token in the audit event may be acquired and received by the structure analysis engine of the security event monitoring application for mapping processing. In step 403, the token may match 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 rows may be mapped to corresponding JSON stanzas. Of course, other types of structured data formats may also be used. Examples of header token mappings may include “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””, and “FAILED_EVENT_LABEL “is_failed_audit_event””. Other mappings may also be used, such as mapping the event naming convention of the first operating system to a naming convention recognized by the second operating system.Once the mapping process is complete, in step 405, the output may be added to the final event record in the memory or storage device 120 in the first computing device. In step 406, a determination may be made as to whether there are any more tokens in the audit event. If the determination is positive, 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 the corresponding structured data format, in step 407, the final event formatted in the structured data format (e.g., JSON) may be stored in the memory or storage device 120 in the first computing device, and in step 408, a log of the formatted event is recorded on the first computer or storage device 120, and the resulting structured data (e.g., JSON) object may contain all the relevant data from a single binary event.

[0048] Figure 5 illustrates Method 500 of a security event monitoring configuration according to one aspect of the present disclosure. Method 500 can begin with step S1. In step S1, a characteristic list configuration file formatted for a first operating system may be loaded into a security event monitoring application 502 residing on a first computing device 105. In step S2, the security event monitoring application 502 reads the characteristic list file 501 to determine a combination of characteristic list keys and characteristic list values. The characteristic list file 501 may be used to configure the level of detail for the set of collection filters. There may be three levels of detail corresponding to the relative security risk of the system under audit and collecting a recommended level of information. In one embodiment, the level of detail may correspond to the relative security risk of the system under audit, as defined, for example, by a published risk management framework (e.g., SP800-37 from the National Institute of Standards and Technology). Examples of the three levels of detail and the corresponding collected information may be as follows: "Log Level 1" (i.e., the first log level) 503: Log Level 1 may represent the lowest level of detail (lowest risk or "lowest risk level") and may collect information about i) application execution, ii) scripts and interactive terminal commands, iii) all authentication prompts and authentication results (e.g., login), and / or iv) authentication prompts and authentication results (e.g., whether user X is authorized to perform 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 or "medium risk level" than the first log level) and may collect information about i) all of the Level 1 logging events, ii) the creation of application network connections, 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 than the second log level or "highest risk level") and may include i) all logging events at Levels 1 and 2, ii) inter-process communication events, and iii) additional detail information for event types collected at lower logging levels. Although three levels of detail are described in this disclosure, slightly different levels of detail are also 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. In particular, in some embodiments, the level of detail is not directly related 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 “medium risk level” or “highest risk level.” “log level 2” (i.e., the second log level, different from the first log level) 504, which may represent a medium level of detail, may have a “lowest risk level” or “highest risk level.” “log level 3” (i.e., the third log level, different from the first and second log levels) 505, which may represent the highest level of detail, may have a “lowest risk level” or “intermediate risk level.”

[0050] After the characteristic list key-value pairs are read in step S2, the 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 level 1 classes may be defined on the pseudo-device's auditpipe, and a filter for that level class may be performed in step S4. The collected data may then be sent to the security event monitoring application filter engine in step S5 for structural analysis. If log level 2 is desired, then in step S6, the desired data to be collected for level 2 classes 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 structural analysis. If log level 3 is desired, then in step S9, the desired data to be collected for level 3 classes 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 in step S11 for structural analysis. Once the data collected from various log levels has been structurally analyzed by the security event monitoring application filter engine, the security event monitoring application then converts or normalizes the data into a format identifiable by the second operating system in step S12 and outputs the data.

[0051] Figure 6 shows a typical flowchart 600 of cross-referencing control according to one aspect of the present disclosure. As shown in Figure 6, a security event monitoring application may collect information from multiple different sources on the first computing device and may cross-reference the information for accuracy. Event data obtained from the BSM may be considered a true and reliable record of the event. In yet another embodiment, other sources of event data may also be considered true and reliable records of the event. Attributes of the BSM record may be matched with those of other sources to cross-reference relevant events. Sources used for cross-referencing may include BSM records, network interface logs (e.g., traffic, successful connections), 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 the first operating system integration log. Attributes used for cross-referencing may include process ID, auditToken, session ID, file path or process path, audit user, active 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 validation is successful, the confidence level of the lowest-confidenced event may be increased, or a higher confidence level may be assigned. Incoming untrusted events may be assigned a confidence score based on the source of the untrusted event, the number of attributes that match a trusted event, and / or the category of action reported by the event (e.g., login, configuration change, network activity). The confidence score and information from matching BSM events may be appended to the untrusted event and sent to a customer-defined destination.In addition to sending BSM events to customer-defined destinations, a temporary cache of BSM events may be retained in a local database for cross-referencing purposes. The duration for which BSM events are stored in the cached database may vary depending on the event type. For example, high-priority events may be stored for a longer period than low-priority events. Furthermore, cross-referencing data from multiple confidence levels may be combined to create an enriched record of the events and actions that occurred. This enriched record may be validated against trusted BSM data and combined with untrusted events. Trusted data from BSM may be added to the untrusted events to add additional context and consistent data fields for later analysis at customer-defined destinations.

[0052] The cross-referencing control process can be described in this disclosure with reference to Figure 6. Flowchart 600 may begin at step 601. In step 601, data relating to a trusted event (A) may be input to the security event monitoring application. Data relating to a trusted event (A) may be collected from the BSM or from other trusted sources. If there is no untrusted event data to cross-reference, the trusted event (A) data may then be sent directly to the log storage system (storage device 120, etc.) in step 602. If there is untrusted event data for cross-referencing, the security event monitoring application may then pass the trusted event (A) data to the cross-referencing engine in step 603. The security event monitoring application or the cross-referencing engine may also pass the trusted event (A) data to a temporary event cache where the trusted event (A) data can be stored in steps 604 and 605, respectively. In step 606, a determination may be made to determine whether there is a decision for an automated response action. The automated response action may include changes to security-related settings or services on the system that enhance or reduce the defensive posture of the protected system. These settings or services may modify the system's behavior to reject local or external inputs that could potentially expose computing devices and / or corporate data to risk. If the determination is positive, the actions taken and the resulting responses may then be logged in step 607 and sent to the log storage system in step 608. The log storage system may be the storage device 120.

[0053] When acquiring data about an untrusted event (B), in step 609, the data for that untrusted event (B) may be sent to a cross-referencing engine. The cross-referencing engine, which has both data for trusted events (A) and data for untrusted events (B), may in step 610 add the verified data for untrusted events (B) to the data for trusted events (A). In step 611, the aggregate of the data for untrusted events (B) and the data for trusted events (A) may be converted into data for a composite enriched event (C), and in step 612, the data for that composite enriched event (C) may be sent to a log storage system (e.g., storage device 120).

[0054] Figure 7 shows a typical flowchart 700 of a detailed cross-referencing engine process according to one aspect of the present disclosure. The flowchart 700 may begin at step 701. In step 701, data for a reliable event (A) may be collected. The data for a reliable event (A) 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, data for an unreliable event (B) may be collected. The data for an unreliable event (B) may be collected from an unreliable logging system and may include information that does not have reliable event (A) data. For example, the data for an unreliable event (B) may include representative information such as "Field 1", "Field 2", "Field 3", "Field AA", "Field BB", and "Field CC". The data for event (A) and the data for event (B) may be the result of another logging system reporting the same action that has already occurred. In step 703, the data fields of event (A) may be mapped to the naming format of event (B) based on a predefined mapping of the security event monitoring application and may be stored in a local database (e.g., storage device 120). In step 704, the data of event (B) may be used to look up the fields of 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 event (B) match the data in the database of event (A). If the determination is negative, then in step 706, the data of event (B) may be stored in a temporary cache for a short period of time. The storage period may be related to the type or category of event (B). In step 707, the lookup process of the fields of 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 event (B) may be deleted from memory or storage.If a match is found in step 705 or step 707 as a result of the lookup process, then in step 709, the data of the trusted event (A) and the data of the untrusted event (B) may be converted into data of a composite enriched event (C). The data of the composite enriched event (C) 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 the action is performed on the system and / or by which party (person or process). For example, the field data may include a process ID, auditToken, session ID, file or process path, audit user, active user, BSM socket, Unix file descriptor, signature ID, timestamp, or related data. In step 710, the data of the composite enriched event (C) may be sent to a log storage system (e.g., storage device 120).

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

[0056] In one embodiment illustrated in Figure 8, the new configuration may be for disabling all network connections on the first computing device as a result of pushing the configuration update to the first computing device. In step 803a, the security event monitoring application may determine whether any whitelisted network connections are defined. If the determination is negative, then in step 803b, it may check the common Mobile Device Management (MOM) configuration file for any allowed server URLs. If an allowed server URL is found, in step 603c, the MOM server URL may be added to the whitelist of network connections. In step 803d, a new firewall configuration may be created along with the whitelist of allowed network connections, application marker rules, and IP (Internet Protocol) spaces. In step 803e, the security event monitoring application applies the generated configuration to verify whether the firewall service is active, and if the firewall service is not active, in step 803f, it may activate the new firewall configuration to block all network connections except for the whitelisted network connections. If the firewall configuration is active, then in step 803g, the security event monitoring application may maintain that configuration until a new configuration is created.

[0057] Figure 9 shows a high-level functional block diagram of a typical computer device or system in which embodiments or parts thereof of the embodiments of the present disclosure may be executed, such as computer-readable code. Furthermore, the typical computer servers, databases, user interfaces, modules, and methods described above with reference to Figures 1-8 may each be executed in a device 900 using hardware, software, firmware, a tangible computer-readable medium on which instructions are stored, or a combination thereof, and may be executed in one or more computer systems or other processing systems. Hardware, software, or a combination thereof may execute each of the typical systems, user interfaces, and methods described above with reference to Figures 1-8.

[0058] When programmable logic is used, the logic can 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 can be implemented using a variety of computer system configurations, including multicore multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered by distributed functions, and popular or miniature computers that can be incorporated into virtually any device.

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

[0060] Various embodiments of this disclosure can be implemented using device 900, as described above in the examples in Figures 1-8. After reading this specification, it will be apparent to those skilled in the art how embodiments of this disclosure can be implemented using other computer systems and / or computer architectures. While operations can be described as sequential processes, in practice, some operations can be performed in parallel, simultaneously, and / or in a distributed environment, and can be performed using program code stored locally or remotely so as to be accessible by single or multiprocessor machines. Furthermore, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosed subject matter.

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

[0062] Furthermore, device 900 may include main memory 940, for example, random access memory (RAM), and secondary memory 930. The secondary memory 930, for example, read-only memory (ROM), may be, for example, a hard disk drive or a removable storage drive. Such a removable storage drive may include, for example, a floppy disk drive, a magnetic tape drive, an optical disk drive, flash memory, etc. The removable storage drive in this example reads from and / or writes to the removable storage unit in a well-known manner. The removable storage unit may include a floppy disk, magnetic tape, an optical disk, etc., which are read from or written to by the removable storage drive. As will be recognized by those skilled in the art, such a removable storage unit generally includes a computer-usable storage medium on which computer software and / or data is stored.

[0063] In other implementations, the secondary memory 930 may include other similar means for loading computer programs or other instructions 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 or interfaces that enable the transfer of software or data from removable storage units to device 900.

[0064] Device 900 may further include a communication interface ("COM") 960. The communication interface 960 enables the transfer of software and data between device 900 and external devices. The communication interface 960 may include a modem, a network interface (such as an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transferred via the communication interface 960 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals that can be received by the communication interface 960. These signals may be supplied to the communication interface 960 via a communication path of device 900, which may be implemented using, for example, wiring or cables, optical fibers, telephone lines, cell phone links, RF links, or other communication channels.

[0065] The hardware elements, operating system, and programming language of the device are essentially conventional, and it is presumed that those skilled in the art would be well familiar with them. Device 900 may further include input and output ports 950 for connecting to input and output devices such as keyboards, mice, touchscreens, monitors, and displays. Naturally, various server functions may be distributed and executed across several similar platforms, thereby distributing the processing load. Furthermore, the servers may be executed by appropriate programming of the computer hardware platform.

[0066] detail

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

[0068] In a given implementation, examples of the benefits provided by the system disclosed in this disclosure may include: (1) collecting activity and information about what each macOS computer is doing and how it is operating, in alignment with the native macOS (first operating system) subsystem (e.g., OpenBSM); (2) leveraging higher-level access permission codes (kexts) of the first operating system to collect forensic-healthy information and declare desirable audit_classes for collection without requiring these higher-level permissions through API access provided by the first operating system; (3) collecting and translating binary OpenBSM events whose length, token (line) type, and content within the token line are unknown; (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 the collected data to conform to Windows-based (second operating system-based) log collection or security tool naming conventions (e.g., from mac login events to windows login events). (6) Format the collected data so that it can be natively imported into security operations tools already in use by the enterprise. (7) Store these renamed or formatted events in a JSON log file on the audited system for collection by the security operations tool. (8) Stream the completed output data directly to a security monitoring server hosted and managed by the customer. and / or (9) Take action according to an Apple® configuration profile that configures a specific configuration file with specific key=value pairs (e.g., depending on the configured configuration file and via the configuration profile, turn off all networks on the fly).

[0069] JSON is a human-readable format that categorizes data into (key=value) fields. JSON is an open web standard for data transmission and is parsable by virtually all log collection and security tools. A configuration profile is a device management payload specific to a particular operating system.

[0070] The system or method relating to this disclosure may not require vendor kernel extensions. In one or more embodiments, the system or method may utilize OpenBSM kernel extensions shipped 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 audit_classes and collection parameters collected on macOS' / dev / auditpipe'.

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

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

[0075] To improve accuracy, these normalization processes may include, for example, manual input.

[0076] The methods and systems disclosed herein may include code portability within a first operating system. The systems and methods relating to this disclosure can run without modification on macOS versions from, for example, macOS 2012 to the latest beta versions. This capability and portability are achieved by utilizing the kernel code of the first operating system (macOS), and the implementations disclosed herein can only be run in a normal system context. This is in contrast to, for example, traditional security tools that run their own kext modules. Furthermore, the implementations disclosed herein can run similarly on older systems (prior to 2012). Tools that utilize kexts may be configured to run only against specific versions of security applications on specific versions of macOS (the first operating system) to maintain normal system operation.

[0077] Embodiments of this disclosure can also satisfy stringent specifications of the First Operating System regarding how modern security applications should run and how they should be configured on the First Operating System. For example, the systems and methods disclosed in this disclosure can be run on system context daemons in the following list of context levels from the lowest to the highest permissions: (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 of the first operating system. These files can be immediately applied and executed via Apple's configuration profiles. Configuration profiles can be important in the configuration management of the first operating system.

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

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

[0081] One or more embodiments may allow one or more capabilities to support configuration profile mobile device management (MOM) implementation of a configuration file by a first operating system. All of these settings and actions may be written in one or more codes relating to the system or method disclosed herein, rather than by functions provided by the operating system or MOM provider.

[0082] For example, a configuration profile with the setting “shouldKillNetword?” set to “true” may modify the system firewall settings to disable all network traffic on the computer. If the second setting “allowedNetworklocations” whitelists specific websites such as a company's MOM server or the first operating system's server, the computer can be remotely controlled to mitigate threats.

[0083] The systems or methods disclosed in this disclosure do not necessarily have to make extensive use of graphical user interfaces or visual elements.

[0084] In some implementations, the system or method disclosed in this disclosure may be a very lightweight security tool. Other security tools regularly slow down even the latest and fastest Macs.

[0085] All configurations should be set up remotely. A configuration profile for the first operating system (macOS) may be used.

[0086] The systems or methods disclosed in this disclosure do not need to be recalled to their own “cloud,” and instead, logs are stored locally until they are collected using the company’s logging tools.

[0087] In one embodiment, the system of this disclosure collects only logs that have security or operational value.

[0088] Collecting all logs from OpenBSM may not be practical. In reality, it can severely slow down laptops and desktops depending on the endpoint's resource usage (CPU and storage). Financially, storing more than 300MB per computer per day is extremely expensive in terms of licensing, hosted storage costs, and internet bandwidth.

[0089] Collecting incorrect audit classes for the first audit event filter puts a load on the CPU. For example, collecting incorrect audit classes on / dev / auditpipe consistently resulted in CPU usage exceeding 40%.

[0090] Embodiments of this disclosure help ensure that all relevant security events are captured. The collected audit_class may include audit_event types and may be categorized 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 states, which are negative outcomes, may be high. For each action, such as logging into the system, for example, 3 to 10 different audit_events may be generated. These, for example, 3 to 10 audit_events, may each contain different important information.

[0091] The systems or methods disclosed in this disclosure may define desired audit_classes from the audit kernel components on / dev / auditpipe. From these audit_classes, the data stream may be further filtered in one or more embodiments disclosed in this disclosure to retain only the audit_events from each relevant audit_class.

[0092] Embodiments of this disclosure may include Kext-free application designs. For example, one embodiment may leverage the code of a first operating system for kernel access, which may offer many stability and security advantages, but may also introduce operational challenges such as resistance to tampering.

[0093] The system or method relating to this disclosure can warn malicious applications or users with sufficient privileges to remove the tool from their computer systems.

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

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

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

[0097] Related files may be protected with the native “uchg” flag of the first operating system. “uchg” can prompt any user or application that could modify or delete the files with a second command, “nouchg”. This change to a two-step configuration provides sufficient time to deter less skilled attackers and to log more skilled attackers. All settings can be configured using configuration profiles enforced at the kernel level by the first operating system. Malicious modifications to system configuration files have no effect if configuration profiles are used. In one or more embodiments, if an application is terminated or “killed”, applications running in the background are automatically restarted. Background process files are protected with the same “uchg” flag as other supported files.

[0098] To format the application output, in some implementations, JSON stanzas may be manually entered, thereby mapping the event naming convention of a first operating system to the naming convention 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, which are ultimately combined to create a JSON object representing that event. Filtered events 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 into the parser token by token, the event lines are mapped to the corresponding JSON stanzas, and the JSON stanzas derived from a single filtered event are combined into a JSON object. The resulting JSON object may contain all the data from the single binary event.

[0099] In some cases, the systems and methods disclosed in this disclosure may occupy a small percentage of the CPU available in the background, which may result in a decrease in system speed.

[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 system or method does not block detected threats. In some cases, an application may require its own kext within the kernel to block threats, which could lead to other problems as discussed in this disclosure. However, the disclosed system and method are considered capable of blocking threats if necessary.

[0102] In the above description of representative embodiments of the present invention, it will be recognized that various features of the present invention are sometimes summarized in a single embodiment, figure, or description, for the purpose of streamlining the disclosure and helping to understand one or more of the various embodiments of the invention. However, this method disclosed should not be interpreted as reflecting an intention to require more features than those explicitly described in each claim. Rather, as the claims represent, the embodiments of the invention are fewer than all the features of a single embodiment disclosed above. Therefore, the claims following the detailed description of the invention are thus explicitly incorporated into this detailed description, and each claim stands independently as a separate embodiment of the present invention.

[0103] Furthermore, some embodiments described in this disclosure include some features included in other embodiments but not others. However, as those skilled in the art will understand, combinations of features from different embodiments are within the scope of the present invention and constitute different embodiments. For example, in the following claims, any combination of embodiments described in the claims may be used.

[0104] Therefore, even though certain embodiments are described, those skilled in the art will recognize that other, further modifications may be made without departing from the spirit of the invention, and all such changes and modifications are intended to be claimed as being within the scope of the invention. For example, functions may be added to or removed from a block diagram, or operations may be swapped between function blocks. Steps may be added to or removed from the described methods within the scope of the invention. The subject matter disclosed above should be considered illustrative and not limiting, and the appended claims are intended to cover all modifications, changes, extensions, and other forms of implementation that fall within the true spirit and scope of this disclosure. Therefore, to the maximum extent permitted by law, the scope of this disclosure is determined by the broadest possible interpretation of the claims and their equivalents and is not limited or restricted by the detailed description above. Although various forms of implementation of this disclosure have been described, it will be obvious to those skilled in the art that there are many more forms of implementation that can be carried out within the scope of this disclosure. Therefore, this disclosure is not limiting except for the appended claims and their equivalents.

Claims

1. A method for monitoring security events, performed by a computer, One or more processors receive data from the security module of the first operating system. The one or more processors define audit class data filters for collection by the security event monitoring application, The one or more processors receive the level of detail of the audit class data filter as the level of detail that defines the amount of audit class data collected. The one or more processors perform filtering of the data based on the level of detail of the audit class data filter. The one or more processors compare the data with the audit class data filter, Based on a comparison of the aforementioned data with the audit class data filter, if it is determined that the aforementioned data does not match the audit class data, one or more processors delete the aforementioned data and generate a stream of audit event data that matches the filtered aforementioned data. The one or more processors compare the audit event data that matches the filtered data with the values ​​registered in the series of blacklists. Based on a comparison between the audit event data included in the stream of audit event data that matches the filtered data and the values ​​registered in the series of blacklists, one or more processors delete audit event data that they determine to match one or more of the values ​​registered in the series of blacklists, thereby generating a stream of audit event data that matches the audit class data but does not match the values ​​registered in the blacklists. One or more processors capture audit event data included in the stream of audit event data that is part of the audit class data and relates to an action performed by the first computing device, and which matches the audit class data but does not match a value registered in the blacklist. The one or more processors determine at least one token relating to the attributes of an audit event based on a token identifier. The one or more processors syntactically parse the at least one token into a common structure format, A method by which one or more processors output data in the aforementioned common structure format.

2. The method executed by a computer according to claim 1, wherein the common structure format is at least one of JSON, CSV, or XML.

3. The one or more processors receive configuration file changes for a first computing device that runs the first operating system, The method performed by the computer according to claim 1, further comprising the one or more processors performing a response action by the security event monitoring application based on the change in the configuration file.

4. A non-temporary computer-readable medium for monitoring security events, wherein the non-temporary computer-readable medium stores instructions, and the instructions, when executed by one or more processors, The one or more processors receive data from the first operating system. The one or more processors define audit class data filters for collection by the security event monitoring application, The one or more processors compare the data with the audit class data filter, The one or more processors delete data that is determined not to match the audit class data and generate a stream of audit event data that matches the filtered data. The one or more processors compare the audit event data included in the stream of audit event data that matches the filtered data with the values ​​registered in a series of blacklists, delete any audit event data that is determined to match one or more values ​​in the series of blacklists, and generate a stream of audit event data that matches the audit class data but does not match any values ​​registered in the blacklists. The one or more processors mentioned above output data in a common structure format. A non-temporary computer-readable medium, which is an instruction that constitutes one or more processors for performing processing.

5. The non-temporary computer-readable medium according to claim 4, further comprising one or more processors capturing audit event data which is part of the audit class data and relating to an action performed by a first computing device, and which matches the audit class data but does not match a value registered in the blacklist.

6. The non-temporary computer-readable medium according to claim 5, further comprising one or more processors determining at least one token relating to the attributes of an audit event based on a token identifier.

7. The non-temporary computer-readable medium according to claim 6, further comprising one or more processors parsing the at least one token into the common structure format.

8. The non-temporary computer-readable medium according to claim 7, wherein the common structure format is at least one of JSON, CSV, or XML.

9. The non-temporary computer-readable medium according to claim 4, further comprising the one or more processors receiving the level of detail of the audit class data filter as a level of detail that defines the amount of audit class data collected.

10. The non-temporary computer-readable medium according to claim 9, further comprising one or more processors filtering the data based on the level of detail of the audit class data filter.

11. The one or more processors receive configuration file changes for a first computing device that runs the first operating system, The non-temporary computer-readable medium according to claim 9, further comprising the one or more processors performing a response action by the security event monitoring application based on the change in the configuration file.

12. A method for monitoring security events, performed by a computer, One or more processors receive data from a first operating system. The one or more processors perform the following actions: (1) compare the data with an audit class data filter; (2) if the data is determined not to match the audit class data, delete the data and generate a stream of audit event data determined to match the filtered data; (3) compare the audit event data included in the stream of audit event data determined to match the audit class data with values ​​registered in a series of blacklists; and (4) delete audit event data that is determined to match one or more values ​​registered in the series of blacklists, and generate a stream of audit event data that matches the audit class data but does not match any of the values ​​registered in the blacklists. A method for one or more processors to output data in a common structure format.

13. The method performed by a computer according to claim 12, further comprising the one or more processors capturing audit event data which is part of the audit class data and matches the audit class data relating to an action performed by a first computing device and does not match a value registered in the blacklist.

14. The method performed by a computer according to claim 13, further comprising one or more processors determining at least one token relating to the attributes of an audit event based on a token identifier.

15. The method executed by a computer according to claim 14, further comprising one or more processors parsing the at least one token into the common structure format, wherein the common structure format is at least one of JSON, CSV, or XML.

16. The one or more processors receive the level of detail of the audit class data filter as the level of detail that defines the amount of audit class data collected. The method performed by a computer according to claim 12, further comprising the one or more processors filtering the data based on the level of detail of the audit class data filter.

Images