WO2017030550A1

WO2017030550A1 - Confidence indicator of unreceived security message

Info

Publication number: WO2017030550A1
Application number: PCT/US2015/045492
Authority: WO
Inventors: Rhod DAVIES
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2015-08-17
Filing date: 2015-08-17
Publication date: 2017-02-23
Anticipated expiration: 2018-02-17

Abstract

A set of received security messages may be obtained. Each of the messages may have a message type and a timestamp. A confidence indicator may be determined using the timestamps.

Description

CONFIDENCE INDICATOR OF UfciRECEfVED SECURITY MESSAGE

BACKGROUND

[00Θ1] A Security information and Event Management (S!EM) system may be used to identify the occurrence of one or more use cases. A S!E use case is a detectabie set of conditions that indicate that an event of interest has occurred triggering the SiEM system to perform an action, providing an alert, a report, or a remedial action. The conditions are detected though the receipt of specified sets of log messages from monitored devices. For example, some SIEM use cases might comprise a compromised or infected system tracking use case or maiware detection use case based on outbound firewall logs, network intrusion and prevention system (NIPS) alerts, Web proxy logs, internal connectivity logs, network flows, and so on. Another SIEM use case might be tracking Web application attacks using Web server logs, Web application firewall (WAF) and application server logs, combining logs from different components to provide a more complete picture. Another SIEM use case might be authentication tracking and compromised account detection using authentication logs, and login messages.

BRIEF DESCRIPTION OF THE DRAW!NGS

[0002] Certain examples are described in the following detailed description and in reference to the drawings, in which:

[0003] Figure 1 illustrates an example method of determining a confidence indicator;

[0004] Figure 2 illustrates an example method of determining a confidence indicator;

[0005] Figure 3 illustrates an example non-transitory computer readable medium storing instructions to determine a confidence indicator associated with a SiEM use case;

[0006] Figure 4 illustrates an example non-transitory computer readable medium storing instructions to determine a confidence indicator associated with a SiEM use case; [0007] Figure 5 illustrates an example system including a processor and non-transitory medium 504 storing instructions executable by the processor to determine a confidence indicator of correct messaging configuration of a machine; and

[0008] Figure 6 illustrates an example system including a processor and non-transitory medium storing instructions executable by the processor to determine a confidence indicator of correct messaging configuration of a machine.

DETA!LED DESCRIPTION OF SPEC!F!C EXAMPLES

[0009] SIEM systems depend on receiving correct log messages from the devices and systems that they monitor. For example, a SIEM use case may be the detection of multiple failed logins. This might be implemented by setting the SIEM system to detect more than 3 failed logins by a single user within a certain time period, such as 10 minutes. The SIEM system would be configured to look for failed login messages in the logs sent to it. if such messages were not generated or did not reach the SiEM system, then no alert would be generated and the system would be ineffective.

[0010] SIEM use cases are typically tested on a few example systems through a manual process when the system is first commissioned. However, ineffective testing or later changes to the system (including the log sources, SIEM and intervening network configuration) may result in the SIEM system failing to receive the proper log messages to detect the use case of interest. For example, things that could prevent delivery of the messages may include: misconfiguration or filtering in the intervening networks; misconfiguration of the logging system, resulting in misdirection or non-generation; changes to log message formats; misconfiguration of the source system, preventing generation of the messages of interest; or subsequent changes to the source configuration. Additionally, many of the messages of typical SIEM use cases are relatively rare. For instance, in the above login example, failed login messages may be less frequent than successful login messages. Accordingly, a system administrator may not realize that a SIEM use case is not will not perform correctly because the events the use case is configured to detect and on which it depends are rare so failure to produce them is not detected.

[0011] Implementations of the disclosed technology provide confidence indicators of whether an enterprise architecture is correctly configured to implement a SIEM use case effectively. For example, implementations may provide confidence indicators of whether rare events would be detected if they occurred.

[0012] In some implementations, the confidence indicator could be affected by factors such as: (1 ) whether the specific security message has been received recently, which provides an initially high confidence that decays over time; (2) whether messages controlled by the same settings have been recently received, which provides an initially high confidence that decays over time; (3) whether messages indirectly related to the specific message have been recently received, which provide a medium confidence that decays over time; and (4) whether any messages have been received recently, which provides proof that there is a network path to receive the messages, but low confidence that configuration is correct.

[0013] Figure 1 illustrates an example method of determining a confidence indicator. For example, the illustrated method may be implemented by a SIEM system. As another example, the illustrated method could be implemented as a stand-alone application that has access to the log messages received b the SIEM system being analyzed. As a further example, the illustrated method could be implemented as an application or service that analyzes a plurality of SIEM systems. For example, a service provider may provide a SIEM service to a set of clients. The service provider may implement the illustrated method to analyze the configuration of the SIEM service on a client-by-client or global basis.

[0014] The example method may include block 101. Block 101 may include obtaining a set of received security messages. For example, block 101 may be performed by obtaining a set of log records corresponding to security related events. For example, the SIEM may have connectors for retrieving device logs of different device types and converting them into a canonical format based on recognizable structures in the logs. As another example, an add-on system may periodically sweep a SIEM system's log database to obtain the set of received security messages. As another example, block 101 may comprise snooping or receiving copies of alert messages sent to a SIEM system.

[0015] Each respective security message may have an associated receive timestamp and message type. The receive timestamp may be a timestamp indicating when the message was received by the SIEM or when the message was generated. In some implementations, the message type may specifically identify the process generating the message. For example, the message type might be message contents such as, in a Linux system, the message "PAM unix: (sshd) session opened for user root by root (uid=0)." In other implementations, the message type may indicate the type of event which spurred the creation of the log entry. For example, the message types might include login success, login failure, page downloads, virus detection or other antivirus system messages, passcode accepted or passcode incorrect messages, authentication messages, or other messages that the SIEM system receives, in further implementations, the security messages may be associated with multiple levels of message types. For example, the messages may have a specific associated type reflecting the specific message content or process that created the message and may have a group indicator indicating the general message type.

[0016] The example method may further include block 102. Block 102 may include using the timestamps of the set of received security messages to determine a confidence indicator of reception of an unreceived security message having a different message type than an element of the set of received security messages. For example, the last-seen timestamps of messages of different message types may be used to determine the confidence indicator. The unreceived security message ma be a securit message that has not been received by the SIEM since the last time the method was performed, or since a selected time. Additionally, the unreceived security message may be a message that has not been received from a particular machine in the relevant time period, or it may be a message that has not been received from any machine of the set of machines monitored by the SiEM system,

[0017] The confidence indicator of reception is an indicator of the likelihood that an unreceived security message would be received if the event causing the unreceived security message were to occur. For example, the confidence indicator may be a confidence indicator of correct operation of a SIEM use case. For example, the confidence indicator of correct operation of a SIEM use case might be an indicator of result of correct configuration of machines monitored by the SiEM or by the network between the SIEM and the machines. As another example, the confidence indicator may indicate a correct configuration of a security messaging policy of a machine being monitored by a SIEM system, in some implementations, the confidence indicator may be a discrete value, such as a probability indicating likelihood of reception if the causal event occurred, in other implementations, the confidence indicator may be a categorical indication of risk, such as "high," "medium," or "low."

[0018] As discussed above, SiEM systems implement use cases based on received messages such as log messages and alerts. In some cases, the log messages or alerts relevant to the use case occur infrequently. However, the use-case relevant log messages or alerts may be related to more frequently received messages. For example, the SIEM system may be configured to implement a use case that generates an alert when the SIEM system receives 3 failed logins to the same user within 10 minutes. In some cases, the SIEM system may not frequently receive failed login messages, but may frequently receive successful login messages. Additionally, the same configuration setting may result in a monitored system sending successful and failed login messages to the SIEM system. The successful login messages are therefore related to failed login messages. Accordingly, in this example the timestamps of received successful logins may be used to determine a confidence indicator that the unsuccessful login messages wouid be received if unsuccessful login events were to occur. This could indicate that the machine generating the login messages had a correct configuration for its security messaging policy and that the intervening network fabric was configured to deliver the message, so that the SI EM would actually detect the use case correctly.

[0019] As described above, block 102 may include using timestamps to determine the confidence indicator. In some cases, the receive timestamps may be used to determine the last time a particular message or message type was seen. In these cases, the last time in which each particular message type was seen may be used to determine the confidence indicator.

[0020] For example, a strong confidence indicator may be determined by observing a specific message of interest within a certain time frame, such as a week, within which it would be unlikely that changes to system configurations had occurred, in some implementations, the system may have a mapping of specific received messages and last seen timestamp to confidence indicators. For example, each received message type may have a confidence weighting decay rate based upon the received message's expected frequency.

Frequently expected messages may have a greater decay rate than infrequently expected messages. For example, if the SI EM use case were to monitor a Linux system for the message Mmonitor="sshd-x[12404]: PAM__unix: 2 more authentication failures; root(uid=0) -> admin for sshd service" and the received messages are MR1 - 's8hd-x[21851 ]: PAM unix: (sshd) session opened for user root by root(uid=0)" and MR2="sshd-x[25134]: authentication failure: root(uid=0) -: login for sshd service", then MR2 would have a smaller decay rather than MR1 because MR1 is expected to occur more frequently. In an implementation employing categorical confidence indicators, the system may employ mapping of last seen timestamps and message types to the confidence categories. For example, the system could map each received message individually to a confidence level, and then combine the confidence levels to generate the confidence indicator. For example, the system could combine the confidence indicators by taking the minimum individual confidence level, by averaging the confidence levels, or through another method of combination.

[0021] In further implementations, the system may monitor a usual period between messages of the same or different types, in these implementations, block 102 may include determining if an unusually extended gap between messages occurred. This may indicate a change to a configuration, resulting in a decreased confidence indicator. For example, if the gap between two messages of the same type were a threshold amount longer, such as 10-25% longer than the normal time, block 102 may include reducing the confidence indicator.

[0022] Figure 2 illustrates an example method of determining a confidence indicator. For example, the illustrated method may be implemented by a system as described with respect to Figure 1.

[0023] The example method may include block 201. Block 201 may include obtaining a set of received security messages, each respective security message of the set having a message type and a receive timestamp. Block 201 may be performed as described with respect to block 101 of Figure 1 .

[0024] The example method may further include block 202. Block 202 may include categorizing received messages by SI EM use case. For example, the set of messages received in block 201 may include messages associated with different SI EM use cases. A mapping of message types to Si EM use cases may be used to generate a set of received messages for each SI EM use cases being evaluated.

[0025] The example method may further include block 203. The messages received in block 201 may be instances of message types. The time in which a particular message type was last seen may be used to generate the confidence indicator. In block 203, the obtained messages may be inspected to determine a set of message types that are included in the set of obtained messages. Block 203 may include generating a table of the received message types, in some cases, a particular SIEM use case may have an associated message type table, and block 203 may include populating the table with indications that certain message types were received. In these cases, the absence of any messages of a particular type may be used to determine the confidence indicator.

[0026] Block 203 may further include using the receive timestamps of the set of received messages to determine a last seen timestamp of each message type. For example, the last seen timestamp may be the latest receive timestamp of ail received messages of the corresponding message type.

[0027] Different implementations may use different methods of determining the last seen timestamps. For example, if the method were performed by a SIE system itself, the SIEM system may be extended to add tables capable of recording the last seen timestamps for messages against devices. This could be done by updating the table as messages are received or by a periodic batch job periodically sweeping over the logs received. As another example, if the method were performed by a separate system analyzing a SIEM, the system could conduct a periodic sweep of the log database to generate the last seen timestamps.

[0028] The example method may further include block 204. Block 204 may include using the last seen timestamps of the message types to determine confidence indicators that those message types will continue to be received. For example, each message type may have an associated confidence level thresholds of when a message of that type is received. The confidence level of continued receipt of the message type may be reduced each time the last seen timestamp exceeds a threshold. For example, in a deployment, a successful login message may be expected every 5 minutes. Example confidence thresholds for three levels of confidence may be set at 5 minutes and 15 minutes, in this example, if the last seen timestamp of a successful login message is 20 minutes ago, then the confidence level of future receipt of a successful login message may be low.

[0029] The example method may further include block 205. Block 205 may include using the message type of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message. Each received message type may have a degree of association to the unreceived security message. Block 205 may include using the degree of association of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message. For example, a mapping of message type to unseen message types may be used to weight the contribution of each seen message type to the confidence indicator of the unreceived message. The mapping may include an indication of the degree of likelihood that the unreceived message would be received if an relevant triggering event occurred given the receipt of the received message. Such a mapping ma be implemented using a catalogue of messages that the SIEM may receive and a description of the audit/configuration settings that control their generation. For example, on Linux systems, the settings for the sshd service make no distinction between successful and unsuccessful sshd logins. Accordingly, a successful login message is strongly associated to an unreceived failed login message. In contrast, in Windows, local audit policies setting "audit account logon events" provide separate options for turning on records of success and failures, with the default to produce neither record. Accordingly, the association value for a successful login to a failed login would be less in a Windows deployment than a Linux deployment.

[0030] In some implementations, block 205 may be performed on a peruse case basis. For example, if messages are sorted by use case in block 202, certain messages may be included in the analysis for multiple different use cases. Accordingly, they may be associated with different unreceived security messages and their association to the different unreceived security messages may vary.

[0031] The example method may further include block 206. Block 208 may include determining confidence indicators of correct configuration of an unreceived message. For example, block 206 may include combining the confidence indicators of the seen message types determined in block 204 according to the weights determined in block 205. As another example, this may be performed as described with respect to block 102 of Figure 1 . This may be performed for each of the use cases under evaluation.

[0032] The example method may further include block 207. Block 207 may include using the confidence indicator of reception and the last seen timestamps to determine a confidence indicator of correct operation of a security information and event management system (SIEM) use case. For example, the confidence indicator of correct operation of a SIEM use case might be an indicator of result of correct configuration of machines monitored by the S!E or by the network between the SIEM and the machines, in some implementations, biock 207 may be implemented using a mapping or table of the message types that are needed by the use case. The table may include indications whether each message type has been received or has not been received, as well as the confidence indicator for each message type. For example, this data may be determined during blocks 204 and 208. In some cases, less then ail of the message types used in block 204 may be used in biock 207. For example, certain message types may not be used in a SIEM use case, but may still be used to determine confidence indicators for un received SIEM use case relevant messages.

[0033] Block 207 may further include weighting different message types' contributions to the confidence indicator of SIEM use operations. The mapping or table may include this weighting information. For example, messages of a given type may be generated as a result of multiple similar events or as a result of multiple different messaging configurations. As another example, received messages of different types may be generated with different frequencies, and less frequently received messages may be given a greater weight than more frequently received messages. For example, a SIEM monitoring an

authentication server may have a configured use case based on receipt of a "good tokencode/bad PIN detected" message. In this example, the set of received messages may include "passcode accepted" and "passcode incorrect" error messages. The "passcode accepted" message may be a frequent occurrence, and indicative that audit trails are properly configured. The

"passcode accepted" message type could be given a first weight in the determination of the confidence indicator. The "passcode incorrect" error messages could confirm the correct audit trail is properly configured and could be more indicative that "good tokencode/bad PIN detected" would be received if the circumstances arose. Thus, the "passcode incorrect" error messages could be given a greater weight than the "passcode accepted" messages.

[0034] Additionally, in some cases, the weights given the messages may be based on whether or not the message types were received. For instance, in the above example, if any "passcode incorrect" error messages were received, block 207 would result in a stronger confidence indicator than if no "passcode incorrect" error messages were received.

[0035] Figure 3 illustrates an example non-transitory computer readable medium 301 storing instructions 302-303 to determine a confidence indicator associated with a SIEM use case. In various implementations, the medium 301 may be random access memory (RAM), storage such as a hard disk or flash memory, or portable memory such as a USB flash drive or DVD disc. For example, the instructions 302-303 may be executed by a SiEM system as an aspect of the SIEM program, or as an add-on program executed in conjunction with a SIEM system. As another example, the medium 302-303 may be located at a remote data center or cloud and may be executed by a service provider to evaluate a customer's SiEM system.

[0036] The example medium 301 may store a first instruction set 302.

The first instruction set 302 may be executable by a processor to obtain a set of received security messages associated with a SIEM use case. Each respective security message of the set may have a message type and a receive timestamp. For example, executing the first instruction set may cause the processor to perform block 101 of Figure 1 .

[0037] For example, a SIEM system may execute instructions 302 by using a connector to a device to retrieve the device's logs, converting them into a canonical format, and associating message types with them. Additionally, the system may execute the instructions 302 to associate last seen timestamps with the message types. In some implementations, the SIEM system could use a mapping of ail possible messages to message types to perform the association. As another example, a separate program analyzing the SIEM system may obtain the messages by performing a periodic sweep of the SIEM log database, in some implementations, the instructions 302 may be executable to associate a last seen timestamp with each received message type. For example, the instructions 302 may be executable to generate a table of message types and last seen timestamps.

[0038] The example medium 301 may store a second instruction set 303. The instructions 303 may be executed by the processor to determine a confidence indicator of reception of an unreceived security message associated with the Si EM use case using the received timestamps and message types of the set of received security messages. For exampie, the processor may execute the instructions 303 to perform blocks 102 and 204-206 of Figures 1 and 2, respectively, in some implementations, the unreceived security message may have a different message type than the message types of the set of received security messages. For example, the received security messages may be successful login messages while the unreceived security message may be an unsuccessful login message.

[0039] Figure 4 illustrates an exampie non-transitory computer readable medium 401 storing instructions 402-404 to determine a confidence indicator associated with a SI EM use case. For example, the medium 401 may be an implementation of a medium 301 as described with respect to Figure 3. In various implementations, the medium 401 may be random access memory (RAM), storage such as a hard disk or flash memory, or portable memory such as a USB flash drive or DVD disc. For example, the instructions 402-404 may be executed by Si EM system as an aspect of the SI EM program, or as an addon program executed in conjunction with a Si EM system. As another example, the medium 402-404 may be located at a remote data center or cloud and may be executed by a service provider to evaluate a customer's SI EM system.

[0040] The example medium 401 may store a first instruction set 402. The first instruction set 402 may be executable by a processor to obtain a set of received security messages associated with a SIEM use case, each respective security message of the set having a message type and a receive timestamp. For example, a processor executing a SIEM system or separate program may execute the instruction set 402 as described with respect to instructions 302 of Figure 3. Additionally, each of the obtained messages may have a degree of association to an unreceived security message. For example, the degrees of association may be as described with respect to block 204 of Figure 2.

[0041] The example medium 401 may further store a second instruction set 403. The second instruction set 403 may be executable by the processor to use the degree of association of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message. For example, the instruction set 403 may be executable to weight the contributions of each security message as described with respect to block 205 of Figure 2.

[0042] The example medium 401 may store a third instruction set 404. The third instruction set may be executable to determine a confidence indicator of reception of an unreceived security message associated with the SI EM use case. The confidence indicator may be determined using the received timestamps, the message types, and the association weights. For example, the instructions 404 may be executable to perform block 206 of Figure 2.

[0043] Figure 5 illustrates an example system 501 including a processor 503 and non-transitory medium 504 storing instructions 505-508 executable by the processor 503 to determine a confidence indicator of correct messaging configuration of a machine. For example, the illustrated system 501 may be a computer to execute a SI EM program with the instructions 505-506 integrated into or separate from the SI EM program, or a server or other computer to execute a SIEM system monitoring program. The non-transitory medium 504 may be RAM, storage, or a combination thereof.

[0044] The medium 504 may store a first instruction set 505. The instruction set 505 may be executable by the processor 503 to obtain a set of received security messages sent by a machine. Each respective security message of the set may have a message type and an associated timestamp. For example, the instruction set 505 may be executable by the processor 503 to use an interface 502, such as a network interface, to receive the messages from the machine. For example, the instructions 505 may cause a SIEM system to overlay semantic meaning, such as the message types, and receive timestamps on a connector to the machine that is capable of retrieving the machine's logs. As another example, the instruction set 505 may be executable by the processor 503 to use the interface 502 to obtain a SIEM system's logs, and to associate the message types and timestamps with the SIEM system log entries, in further implementations, the instructions 505 may be executable to determine a set of last seen timestamps for each received message type and a set of confidence indicators for future receipt of the received message types. For example, the instructions 505 may be executable to perform blocks 101 or 201 - 204 of Figure 2.

[0045] The medium 504 may store a second instruction set 506. The second instructions 508 may be executable by the processor 503 to determine a confidence indicator of correct configuration of the machine to send an unreceived security message. For example, the instructions 506 may be executable by the processor 503 to determine the confidence indicator using the timestamps and message types of the set of received security messages. As described above, the unreceived security message and the set of received security messages may be associated with a SiE use case, in these implementations, the confidence indicator may indicate a likelihood that the machine is properly configured to support the operabiiity of the SiEM use case. For example, as described with respect to block 102 of Figure 1 , the confidence indicator may be a categorical assessment of the confidence that the machine is properly configured.

[0046] Figure 6 illustrates an example system 801 including a processor 602 and non-transitory medium 604 storing instructions 605-607 executable by the processor 603 to determine a confidence indicator of correct messaging configuration of a machine. For example, the illustrated system 601 may be a computer to execute a SiEM program with the instructions 805-607 integrated into or separate from the SiEM program, or a server or other computer to execute a SIEM system monitoring program. The non-transitory medium 604 may be RAM, storage, or a combination thereof.

[0047] The medium 604 may store a first instruction set 805. The instruction set 805 may be executable by the processor 603 to obtain a set of received security messages sent by a machine using the interface 602. For example, the instruction set 605 may be as described with respect to instructions 505 of Figure 5.

[0048] The medium 604 may store a second instruction set 606. In some implementations, each security message may have a degree of association to the unreceived security message. For example, the degree of association may be value indicating the likelihood that the received security message and the unreceived security message result from the same machine configuration, such as a messaging policy. The second instruction set 606 may be executable by the processor 603 to use the degree of association of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message. For example, the system 601 may store a table mapping each security message type to an association value to the unreceived security message. In some implementations, this mapping may be specific to the type of machine being monitored or to the SiEM use case being evaluated.

[0049] In other implementations, the second instruction set 606 may be executable by the processor 603 to weight a contribution of a given received security message to the confidence indicator by the message type of that given received security message, in further implementations, the instruction set 606 may be executable by the processor 603 to weight a contribution of a given received security message to the confidence indicator by the receive timestamp of that given received security message. For example, the instruction set 606 may be executable to perform blocks 204-206 of Figure 2.

[0050] The medium 604 may store a third instruction set 607. The third instruction set 607 may be executable by the processor 603 to determine the confidence indicator of correct configuration of the machine, taking into account the weight applied during execution of instructions 606. For example, the confidence indicator ma be determined as described with respect to block 207 of Figure 2.

[0051] Examples of the technology are described herein in terms of receipt and analysis of security messages, such as log messages resulting from security related events. In further implementations, the technology described herein may be applied to operations monitoring generally. For example, the technology described herein may be applied to an operation support system (OSS) assurance solution that monitors various conditions of a system architecture. For example, instead of security messages, the technology could be applied to operational messages such as disk failure messages, disk spin up messages, virtual machine provisioning error messages, virtual machine provisioning success messages, or other operational messages. As an example, a confidence indicator of whether a monitoring system would receive a disk failure message may be determined based on the last time a disk spin up message was received. As another example, a confidence indicator for a monitoring system monitoring an automated cloud deployment system may indicate a confidence of whether an error message would be received based on received virtual machine provisioning success messages.

[0052] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

CLAi S

1 . A method, comprising:

obtaining a set of received security messages, each respective security message of the set having a message type and a receive timestamp; using the received timestamps of the set of received security messages to determine a confidence indicator of reception of an unreceived security message having a different message type than an element of the set of received security messages.

2. The method of claim 1 , further comprising:

generating a table of received message types;

using the receive timestamps to determine a last seen timestamp for each received message type; and

using the last seen timestamps to determine the confidence indicator.

3. The method of claim 2, further comprising:

using the confidence indicator of reception and the last seen timestamps to determine a confidence indicator of correct operation of a security information and event management system (SI EM) use case.

4. The method of claim 1 , wherein the confidence indicator is a confidence indicator of a correct configuration of a security messaging policy of a machine.

5. The method of claim 1 , wherein the received security messages are alerts or log entries.

8. The method of claim 1 , further comprising:

using the message type of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message.

7. The method of claim 1 , each respective security message of the set having a degree of association to the unreceived security message, and further comprising:

using the degree of association of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message.

8. A non-transitory computer readable medium storing instructions to: obtain a set of received security messages associated with a security information and event management (Si EM) use case, each respective security message of the set having a message type and a timestamp; determine a confidence indicator of reception of an unreceived security message associated with the Si EM use case using the timestamps and message types of the set of received security messages.

9. The non-transitory computer readable medium of claim 8, wherein the unreceived security message has a different message type than the message types of the set of received security messages.

10. The non-transitory computer readabie medium 8, each respective security message of the set of received security messages having a degree of association to the unreceived security message; and storing further instructions to:

use the degree of association of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message.

1 1. A system, comprising:

a processor; and

a non-transitory medium storing instructions executable by the processor to:

obtain a set of received security messages sent by a machine, each respective security message of the set having a message type and an associated timestamp;

determine, using the associated timestamps and message types of the set of received security messages, a confidence indicator of correct configuration of the machine to send an unreceived security message.

12. The system of claim 1 1 , wherein:

the unreceived security message and the set of received security messages are associated with a SI EM use case; and

the confidence indicator indicates a likelihood of operability of the SiEM use case.

13. The system of claim 1 1 , each respective security message of the set of received security messages having a degree of association to the unreceived security message, and the non-transitory medium storing further instructions executable by the processor to:

use the degree of association of each respective security message of the set to weight a contribution to the confidence indicator of that respective security message,

14. The system of claim 1 1 , the non-transitory medium storing further instructions to determine the confidence indicator by weighting a contribution of a given received security message to the confidence indicator by the message type of that given received security message.

15. The system of claim 1 1 , the non-transitory medium storing further instructions to determine the confidence indicator by weighting a contribution of a given received security message to the confidence indicator by the associated timestamp of that given received security message.