阅读说明：本技术 安全器具扩展 (Security apparatus extension ) 是由 L·阿尔维斯 S·菲茨帕特里克 S·金 于 2020-03-10 设计创作，主要内容包括：公开了接收安全事件数据并且使安全事件数据特性化的系统和方法。基于定制的严重性特性化的安全事件数据,实行呈现和/或控制动作,诸如,按优先排列的呈现和警报生成。(Systems and methods of receiving and characterizing security event data are disclosed. Based on the customized severity-characterized security event data, rendering and/or control actions are effectuated, such as prioritized rendering and alert generation.)

1. An electronic device, comprising:

an embedded computer comprising one or more processors configured to:

receiving one or more security event messages from a security appliance, the one or more security event messages each indicating a security event associated with a protected component;

identifying a customized severity characterization of the one or more security event messages;

determining one or more presentation or control actions to be performed based on the customized severity characterization; and

the one or more presentation or control actions are performed.

2. The electronic device of claim 1, wherein the customized severity characterization is determined by executing a mapping script that maps one or more characteristics of the one or more security event messages received by the security appliance to a particular customized severity characterization expected by the embedded computer.

3. The electronic device of claim 2, wherein the one or more characteristics of the one or more security event messages received by the security appliance include a first severity level and the particular customized severity characterization expected by the embedded computer is a second severity level.

4. The electronic device of claim 2, wherein the one or more processors of the embedded computer are configured to execute the mapping script.

5. The electronic device of claim 2, wherein the customized severity characterization is received from the security apparatus.

6. The electronic device of claim 1, comprising a display, wherein the one or more presentation or control actions comprise:

presenting, via a Graphical User Interface (GUI) on the display, a banner associated with the one or more security event messages, the banner displayed based on the customized severity characterization; alternatively, the first and second electrodes may be,

presenting, via stacked lights, one or more visual alert indications associated with the one or more security event messages, the one or more visual alert indications characterized based on the customized severity; alternatively, the first and second electrodes may be,

and both.

7. The electronic device of claim 1, wherein the one or more presentation or control actions include modifying an operating condition of the protected component.

8. The electronic device of claim 7, wherein the protected component comprises an amusement attraction.

9. The electronic device of claim 1, wherein the one or more security event messages comprise messages generated according to the Syslog standard for message logging.

10. The electronic device of claim 1, comprising:

one or more input/output (I/O) devices configured to receive one or more I/O commands from an operator of the electronic device or to provide one or more output indications to the operator, or both; and

a Programmable Logic Controller (PLC) configured to:

receiving I/O data indicative of the one or more I/O commands and implementing the one or more I/O commands; alternatively, the first and second electrodes may be,

receiving the one or more output indications and presenting the one or more output indications via the one or more I/O devices; alternatively, the first and second electrodes may be,

and both.

11. The electronic device of claim 10, wherein the one or more I/O devices comprise a set of one or more lights that provide an indication of the customized severity characterization;

wherein the set of one or more lights comprises a faulty Light Emitting Diode (LED) that selectively indicates a critical severity safety event when in a first state and a medium severity safety event when in a second state; and

wherein the set of one or more lights comprise healthy Light Emitting Diodes (LEDs) that indicate whether all of the intended interfaces are communicatively coupled to the electronic device.

12. The electronic device of claim 10, wherein the embedded computer is configured to:

determining when a continuously changing state of a variable of the PLC has not been detected at the embedded computer within a threshold amount of time; and

providing a fault in response to the continuously changing variable state not being detected within the threshold amount of time, the fault indicating a malfunction of the embedded computer.

13. The electronic device of claim 10, wherein the one or more I/O devices comprise a run/bypass switch that:

while in the run mode, cause logging and presentation of one or more alert banners associated with the one or more security event messages, and when they are received, cause presentation of one or more alerts associated with the one or more security event messages; and

causing logging and presentation of the one or more alert banners associated with the one or more security event messages while in the bypass mode, and causing suppression of presentation of the one or more alerts associated with the one or more security event messages while they are received.

14. The electronic device of claim 10, wherein the one or more I/O devices comprise a reset switch that, when set to a reset mode, causes the embedded computer to shut down or restart, or both.

15. A tangible, non-transitory computer-readable medium comprising computer-readable instructions that, when executed by one or more processors of a computer, cause the computer to:

receiving one or more security event messages from a security appliance, the one or more security event messages each indicating a security event associated with a protected component;

identifying a customized severity characterization of the one or more security event messages;

determining one or more presentation or control actions to be performed based on the customized severity characterization; and

the one or more presentation or control actions are performed.

16. The computer-readable medium of claim 15, comprising computer-readable instructions that, when executed by the one or more processors, cause the computer to:

identifying the customized severity characterization by executing a mapping script that maps one or more characteristics of the one or more security event messages received from the security appliance to a particular customized severity characterization expected by the computer.

17. The computer-readable medium of claim 15, comprising computer-readable instructions that, when executed by the one or more processors, cause the computer to:

presenting, in a Graphical User Interface (GUI) of the computer, one or more alert banners corresponding to the one or more security event messages along with an indication of the customized severity characterization of the one or more security event messages.

18. The computer-readable medium of claim 15, comprising computer-readable instructions that, when executed by the one or more processors, cause the computer to:

determining when a continuously changing state of a variable of a Programmable Logic Controller (PLC) is not detected at the computer within a threshold amount of time; and

providing a fault in response to the continuously changing variable state not being detected within the threshold amount of time, the fault indicating a malfunction of the computer.

19. A computer-implemented method, comprising:

receiving, via a computer, one or more security event messages from a security appliance, the one or more security event messages each indicating a security event associated with a protected component;

identifying, via the computer, a customized severity characterization of the one or more security event messages, the customized severity characterization including a severity identified by the computer based on a mapping to a severity indicated in at least the one or more security event messages;

determining one or more presentation or control actions to be performed based on the identified customized severity characterization; and

the one or more presentation or control actions are performed.

20. The computer-implemented method of claim 19, comprising:

presenting, via a Graphical User Interface (GUI), one or more alert banners associated with the one or more security event messages, the one or more alert banners displayed based on the customized severity characterization; alternatively, the first and second electrodes may be,

presenting, via stacked lights, one or more visual alert indications associated with the one or more security event messages, the one or more visual alert indications characterized based on the customized severity; alternatively, the first and second electrodes may be,

and both.

Background

The present disclosure relates generally to security appliances (security applications). More particularly, certain embodiments of the present disclosure relate to a user interface that carries out specific actions based on the characterization of events generated in a security log.

In the digital age, the proliferation of digital data has created an increased need for network security that is delegated the task of protecting the digital data. Typically, network security threats are provided to a Security Operations Center (SOC) or a Network Operations Center (NOC), where network security teams are delegated the task of monitoring, prioritizing, and fixing these network security threats. Unfortunately, however, as the number of cyber-security threats is increasing, it is becoming increasingly inefficient to rely on human subjectivity to prioritize and fix these threats. Accordingly, there is a need to provide improved prioritization, presentation, and remediation actions for network security events that are not encumbered by the inefficiencies of human subjectivity.

This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.

Disclosure of Invention

Certain embodiments that correspond in scope to the originally claimed subject matter are summarized below. These embodiments are not intended to limit the scope of the present disclosure, but rather, they are intended only to provide a brief summary of certain disclosed embodiments. Indeed, the present disclosure may encompass a variety of forms that may be similar to or different from the embodiments set forth below.

Embodiments described herein relate to a security appliance extension that efficiently receives and prioritizes security events and implements security event actions based on the security events. More specifically, the security events are characterized based on a customized severity characterization map. Customized severity characterization for the event is used to determine a particular set of actions to implement for the action.

By way of example, in an embodiment, an electronic device includes an embedded computer having one or more processors. The processor receives one or more security event messages from the security appliance, the one or more security event messages each indicating a security event associated with the protected component. The processor identifies a customized severity characterization of the one or more security event messages and determines one or more presentation or control actions to be performed based on the customized severity characterization. One or more rendering or control actions are then performed by the processor.

In an embodiment, a tangible, non-transitory computer-readable medium includes computer-readable instructions. Execution of the instructions by the one or more processors of the computer causes the computer to receive one or more security event messages from the security appliance. The one or more security event messages each indicate a security event associated with the protected component. Execution of the instructions by one or more processors of the computer further causes the computer to: identifying customized severity characterization of one or more security event messages; determining one or more presentation or control actions to be performed based on the customized severity characterization; and performing one or more rendering or control actions.

In an embodiment, a computer-implemented method includes receiving, via a computer, one or more security event messages from a security appliance. The one or more security event messages each indicate a security event associated with the protected component. The method also includes identifying, via the computer, a customized severity characterization of the one or more security event messages. The customized severity characterization includes identifying a severity that is expected by the computer based on a mapping to a severity indicated in at least one or more security event messages. The method further comprises the following steps: determining one or more presentation or control actions to be performed based on the customized severity characterization; and performing one or more rendering or control actions.

Drawings

These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

FIG. 1 is a schematic illustration of a Detection and Response Security System (DRSS) according to an embodiment of the present disclosure;

FIG. 2 is a flow diagram illustrating a process for characterizing a security event according to an embodiment of the present disclosure;

FIG. 3 is a flow diagram illustrating a process for performing presentation and control actions based on security event classifications, according to an embodiment;

FIG. 4 is a schematic diagram of a security apparatus extension user interface, according to an embodiment;

FIG. 5 is a schematic diagram of a rear view of a security apparatus extension user interface, according to an embodiment;

fig. 6 is a schematic view of a Graphical User Interface (GUI) illustrating security event data collection by a DRSS according to an embodiment;

fig. 7 is a schematic view of a GUI presenting a DRSS according to an embodiment;

fig. 8 is a schematic view of a GUI for logging into a DRSS of a particularized feature, under an embodiment;

fig. 9 is a schematic view of a GUI of a DRSS presenting particularized features after login, according to an embodiment; and

fig. 10 is a schematic view of a GUI presenting an erroneous DRSS according to an embodiment.

Detailed Description

One or more specific embodiments of the present disclosure will be described below. These described embodiments are merely examples of the presently disclosed technology. In addition, in an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

When introducing elements of various embodiments of the present disclosure, the articles "a," "an," and "the" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements. In addition, it should be understood that references to "one embodiment" or "an embodiment" of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.

The present disclosure relates generally to a Detection and Response Security System (DRSS) that provides automatic prioritization and presentation. The DRSS may facilitate control actions from the user interface to enable a quick response to network security threats. With this in mind, fig. 1 is a schematic illustration illustrating a Detection and Response Security System (DRSS)100 according to an embodiment of the present disclosure. The DRSS100 provides an indication of a security event generated by the security appliance 102, the security appliance 102 being monitoring the protected component 104. In some embodiments, the protected component 104 may be an amusement park attraction. The security appliance 102 monitors the protected component 104 for network security events, which may be indicated by a message log record of the event. For example, "Syslog" as used herein refers to a standard for message logging. Although the term "Syslog" will be used herein, it should be understood that the current technology is also capable of working with a large number of message logging standards, and, as such, use of the term "Syslog" is not intended to limit the current technology to the Syslog standard. The Syslog message logging standard includes many message components. For example, the Syslog message can provide facility code that specifies the type of program that logs the message. A table with associated keywords and described facility codes is provided below:

additionally, the Syslog message may include a list of seriousness. A table of the severity that may be present in the Syslog messages is provided below:

the DRSS100 may include a Security Appliance Extension (SAE)108 that may receive Syslog output from the security appliance 102. The safeties extension 108 and/or the safeties 102 can translate the Syslog messages so that the safeties extension 108 can provide a graphical user interface and/or stacked light (stack light) output that provides ease of interpreting the indication of the Syslog messages. Translation of the Syslog messages results in computer-implemented customized severity characterization of the Syslog messages that must be done based on the components of the Syslog messages (e.g., severity values and/or facility codes). Customized severity characterization can be used to determine severity characterization that is different from a native severity classification (native severity classification) of security. Beneficial for generating customized severity characterization specific to a particular type of protected component, and the like. For example, amusement park attractions can have very different severity characterization for security events than an online game server environment, and so on.

To do this, the syslog mapping script 110 may be executed at the security appliance 102 and/or the embedded computer 106. The Syslog mapping script 110 causes characterization of the Syslog messages according to their characteristics. Based on this characterization, the SAE 108 can provide a graphical representation of the Syslog event and/or can actuate one or more of the stacked lights in a particular pattern to indicate the Syslog event with a particular characterization.

To perform SAE 108 functionality, DRSS100 can interface with both endogenous and exogenous sources. For example, DRSS100 may interface with a security appliance 102 (e.g., Syslog server), security appliance 102 being an external security sensor that sends Syslog messages to DRSS 100. The DRSS10 may listen continuously for incoming messages and handle (e.g., characterize) the messages according to their severity and/or other message characteristics.

In addition, the DRSS100 may interface with the domain controller 112. The domain controller may implement user authentication for the DRSS100 and the SAE 108. As will be discussed in more detail below, user authentication may enable the functionality of the SAE 108 that is not available to unauthorized users. In embodiments that interface with domain controller 112, DRSS100 may continually check for a healthy connection to domain controller 112 and generate an alert when the healthy connection is lost.

Also, the DRSS100 may log data in the database 114. For example, the database 114 may include a table that includes data associating alarm colors configured to be associated with various characterizations of Syslog messages. Also, the Syslog table of Syslog messages received from the Syslog server may be maintained in the database 114 along with an indication of when and by whom the Syslog messages were purged. The DRSS100 can periodically run a clean-up procedure that clears the Syslog table as part of the maintenance of the database 114.

DRSS100 can also include programmable logic to handle input/output (IO) interactions with DRSS 100. The PLC116 receives commands from SAE 108 applications running on the DRSS100 and carries out the commands based on the IOs of the SAE 108.

Ideally, the DRSS100 is continuously monitored to ensure that the DRSS100 is not now able to provide Syslog event indications. Accordingly, in some embodiments, one task of PLC116 is to perform a "monitor" function that continuously monitors DRSS100 to determine whether the SAE 108 application of DRSS100 and/or the operating system of embedded computer 106 has failed. To perform this action, the PLC116 continuously changes the state of variables in the PLC 116. Upon detecting that a state change has not occurred/been reported by the SAE 108 application within a threshold period of time (e.g., 10 seconds), a monitor failure is generated and a corresponding alert is presented by the DRSS 100. For example, a special stack light actuation may be present to indicate a monitor failure. In one embodiment, a special stack lamp actuation causes the green and blue stack lamps to go out, and the yellow and red stack lamps to participate. Additionally and/or alternatively, in some embodiments, an audible alarm is engaged, signaling a monitor failure.

To reset a monitor failure, a special bypass IO may be used. For example, in one embodiment, the run/bypass key switch may be switched to "bypass" to mute the alarm. The "reset" key switch may be transitioned and held for a certain period of time (e.g., at least 10 seconds), causing embedded computer 106 to shut down. Releasing the hold on the "reset" key causes embedded computer 106 to reboot. The DRSS100 can then restart the SAE 108 application and the run/bypass key switch can switch to "run" to ensure that subsequent monitor failures are not bypassed.

Turning to a discussion of the characterization of Syslog messages, fig. 2 is a flow diagram illustrating a process 200 for characterizing security events according to an embodiment of the present disclosure. The process 200 begins with monitoring (block 202) for events (e.g., Syslog messages) associated with a protected component. As mentioned above, the Syslog server may provide a Syslog message to the DRSS100 indicating that a security event has occurred. If no event is detected at decision block 204, monitoring continues until an event is detected.

Upon detecting an event, the event is (e.g.,) characterized based on the DRSS100 Syslog mapping (block 206). As mentioned above, this characterization may be achieved by executing the Syslog mapping script 110 at the security appliance 102/Syslog server and/or at the embedded computer 106 of the DRSS 100. This characterization may map one or more characteristics of the Syslog message into DRSS severity levels, which may include three different severity levels in some embodiments: severity 4: high/critical, severity 3: medium and severity 2: low. For example, Syslog messages that include a severity of 0-2 in the Syslog messages can be mapped to a characterization of severity 4 for purposes of DRSS 100. Also, Syslog messages with a severity of 3-4 can be mapped to a characterization of severity 3 for purposes of DRSS 100. Syslog messages with a severity of 5-7 can be mapped to a characterization of severity 2 for DRSS purposes. By characterizing the Syslog severity from 7 to 3 severity, improved prioritization efficiency can be observed. Also, the Syslog mapping script 110 may be customized to provide fewer or more severity levels, and may map a large number of items found in the Syslog messages. For example, a combination of Syslog severity and a particular facility may map to a higher severity in the DRSS100 than a combination of the same Syslog severity and a different facility code.

Once the characterization is determined, Syslog messages (e.g., security events) are associated with the characterization and provided for use by the SAE 108 (block 208). This characterization can be used to carry out presentation and/or control actions at the SAE 108 for Syslog messages. For example, in some embodiments, for Syslog messages characterized as severity 4 events, flashing red light may be actuated along with an audible alarm. Also, a red alert banner may be presented on a Graphical User Interface (GUI) of the SAE 108. In addition, the status variables maintained by the embedded computer 106 may be translated. For example, both the variable indicating "no alarm present" and the variable indicating "no critical alarm present" may be turned off. For Syslog messages characterized as severity 3, different actions may occur. In one embodiment, continuous red light is actuated. Also, a red alert banner may be presented on the GUI of the SAE 108. A variable indicating "no alarm present" may be turned off, while a variable indicating "no critical alarm present" may retain its condition. For Syslog messages characterized as severity 2, successive yellow lights may be actuated. The yellow alert banner may be presented at the GUI of the SAE 108. The variable indicating "no alarm present" may be turned off, while the variable indicating "no critical alarm present" may retain it.

Turning now to a more detailed discussion of presentation and control actions based on characterization, fig. 3 is a flow diagram illustrating a process 300 for performing presentation and control actions based on security event classification, according to an embodiment. As mentioned above, a security event (e.g., Syslog message) is received (block 302). A characterization for the security event is identified (block 304). For example, the characterizations performed in process 200 may be stored in database 114 and retrieved to identify the characterizations for the security event.

Presentation and/or control actions for the security event may be determined based on the characterization (block 306). For example, stacked lights/Light Emitting Diodes (LEDs) and/or audio actuation may be determined based on characterization as follows:

the diagnostic matrix below provides another indication of the actuation indicated in the above table, which time also indicates the IO key setting for the run/bypass key switch, as described in more detail below. It should also be noted that multiple security events with multiple characterizations can exist simultaneously. Thus, a plurality of these actuations can exist in combination with each other.

A. Run/bypass key switch in "run

B. Run/bypass key switch in "bypass

C. High/critical alarm

D. Moderate alarm

E. Low alarm

F. Monitor failure

G. The test lamp push button is pressed

In the above table, the left most column provides an indication of the LED and alarm output of the DRSS 100. The top row provides an indication of the status of the DRSS100 (summarized in key entries a-G below the table). An "X" indicates which of the DRSS100 states cause the prescribed LED and alarm outputs of the DRSS 100. In some embodiments, this table of LED and alarm outputs and their corresponding DRSS100 states is a representation of logic implemented in circuitry and/or machine readable instructions implemented by the DRSS 100.

Upon determining the appropriate rendering and/or control actions, these rendering and/or control actions are implemented by the DRSS100 (block 308). For example, as will be discussed in more detail below, the stacked lamps may be wired to the DRSS via a junction box located on the rear of the unit. The LEDs may be wired together to a stack of lights to display a common indication.

FIG. 4 is a schematic diagram of a Security Apparatus Extension (SAE) panel 400 having stacked lights 402, according to an embodiment. The SAE panel 400 notifies operators of system alarms received from an external source (e.g., Syslog server) and can optionally interface with external systems to provide external control to the protected components 104. Once the alert action to be implemented is identified, the DRSS100 will activate the necessary LED 404 modules and stacked light 402 modules. Also, can be presented on a display 406, the display 406 displaying the SAE 108/DRSS 100 application and providing a Graphical User Interface (GUI) with an alarm banner indicating the security event and its associated characterization. As will be discussed in more detail below, the display 406 may be a touch screen that enables an operator to clear security events and perform other control operations.

SAE panel 400 can include key switches 403. The bypass key switch 403A is a run/bypass key switch that is a two position key switch that places the SAE 108 in either run mode or bypass mode depending on which of two positions the switch is enabled. In bypass mode, the control interface output ignores the current alarm and is maintained ON. The DRSS100 application continues to display the alert and log the alert. As described herein, in a run mode, the control interface output is actuated based on the received safety event.

Also, a reset switch 403B may be provided. As discussed above, the reset switch 403B may be a key switch that may be transitioned and held for a period of time (e.g., at least 10 seconds) to cause the embedded computer 106 to shut down. Releasing the hold on the "reset" key causes embedded computer 106 to reboot.

Discussing the LED 404 in more detail, the LED 404A is a fault LED that indicates a critical safety event characterization when in a first state (e.g., flashing) and a medium safety event characterization when in a second state (e.g., persistent). LED 404B is a warning LED indicating low alarm characterization. LED 404C is a healthy LED that indicates: all interfaces are connected and the run/bypass key is in the "run" position rather than in the "bypass position". LED 404D is an IO connected LED indicating that PLC116 is connected and running IO logic.

Turning now to the external interfaces of the SAE 108, FIG. 5 is a schematic diagram of a back view of an SAE panel 400 according to an embodiment. As illustrated, SAE panel 400 includes a cooling fan 502 that provides airflow to SAE panel 400.

The SAE panel 400 includes a first communication port 504 (here, an RJ45 ethernet port), the first communication port 504 for communicatively coupling the embedded computer 106 with a Syslog server (e.g., the secure appliance 102 of fig. 1). As previously the server provides Syslog messages, which ultimately become the characterized security events that trigger the rendering and/or control actions, as discussed herein.

SAE panel 400 also includes a second communication port 506 (here, an RJ45 ethernet port), second communication port 506 being used to communicatively couple embedded computer 106 with domain controller 112 of fig. 1. As previously mentioned, domain controller 112 may facilitate user authentication, thereby implementing protected control functions, as will be discussed in more detail below.

The SAE panel 400 also includes a stacked lamp/test lamp push button interface 508. The stack lamp/test lamp push button interface 508 is a terminal to connect the alarm indicator stack lamp 402 of fig. 4 and a test lamp push button that can be pressed to carry out a diagnostic lighting test of the stack lamp 402. The diagnostic test results in a momentary excitation of all light and sound on the stacked lamps 402.

SAE panel 400 also includes a control interface 510. Control interface 510 connects SAE panel 400 to an external interface to include as many triggers as possible for presentation and/or control actions. The PLC116 can provide a specified output via the control interface 510 to establish continuity between the output and common terminals located on the control interface junction box. If specified conditions are met, the PLC116 changes the output conditions, resulting in disrupted continuity. Remote interface outputs supported by the control interface 510 include: no alarm, which is maintained ON but transitions OFF in the presence of any alarm; and the absence of a critical alarm, which is a paired output that is maintained ON but is only turned OFF when a critical alarm is present. As mentioned above, these changes in conditions are actuated when the run/bypass key switch 403A is switched to "run". However, when the run/bypass key switch 403A is switched to "bypass", the absence of an alarm output and the absence of a critical alarm output will be maintained ON regardless of the presence of any alarm.

In some embodiments, control interface 510 may cause operational changes to the protected component. For example, the control interface 510 may connect to attractions and control attraction operation based on the characterized security event/generated alert. For example, amusement attractions (e.g., rides) may be stopped and actions may be taken when a critically serious security event exists.

In some embodiments, the SAE panel 500 can include redundant power supplies 512A and 512B. By having dual power supplies, if power to one of the power sources 512A or 512B fails, the power supply can be maintained by the backup power source 512A or 512B. As will be discussed in more detail below, during such an event, a local alert may be presented indicating which of the power sources 512A or 512B has failed.

Turning now to a more detailed discussion of the DRSS 100/SAE 108 application GUI, fig. 6 is a schematic view of a Graphical User Interface (GUI) launch screen 600 illustrating security event data collection by the DRSS according to an embodiment. As previously mentioned, the DRSS100 application is responsible for listening to incoming security events (e.g., Syslog messages) and alerting the operator of such messages via stacked lights, LEDs, and alarm banners. The application can log an alert history to include the time of receipt, the time the alert was cleared, and the user that cleared the alert. As mentioned above, the application may be secured using domain authentication and may contain a native validation UI that authenticates at the application level rather than requiring the user to switch at the operating system level.

As illustrated in the launch screen 600, upon first launch of the DRSS100 application, the DRSS100 runs a launch process in which the DRSS100 connects to all system interfaces. If the interface fails to communicate, a message describing the failure of communication will be displayed on launch screen 600 and the application will automatically attempt reconnection after a certain period of time (e.g., 10 seconds). Once the initial data set is retrieved (e.g., data indicating an event message and/or communication with the system interface), progress bar 602 will indicate 100% completion of the loading process and launch screen 600 will transition to the primary display screen. During the loading process, the operator can log in using a login inspiration (login afterdance) 604. By logging in, the operator is able to carry out a protected action that is only available to authenticated users. The login process will be discussed in more detail below.

Fig. 7 is a schematic view of a DRSS100 application GUI primary screen 700 according to an embodiment. The main display screen 700 provides an active alert banner 702, the active alert banner 702 being displayed for receipt by the DRSS 100. The alert banner is prioritized, with the highest priority alert presented first. Moreover, security events are provided by differentiating the banners 702. For example, the banner 702A is a red banner and provides a textual indication indicating that the safety warning associated with the banner 702A is characterized as a severity 3 safety event. In contrast, the banners 702B-D are each associated with a security event characterized as a severity 2 security event.

A mute button 704 is provided on the main display screen 700, the mute button 704, when activated, mutes any current audible alarm for a configurable amount of time (e.g., a default time of 30 seconds). In some embodiments, mute button 704 does not require activation of user authentication. However, as illustrated by the grayed out all button 706 and clear button 708, in some embodiments these options can only be selected at login time (e.g., by performing a login process via selecting the login button 604).

Fig. 8 is a schematic view of a GUI login screen 800 according to an embodiment. The login screen 800 enables an operator to enter login credentials (e.g., a user ID 802 and a password 804). In alternative embodiments, other login credentials, such as biometric identification, physical key, etc., may be used to log into the DRSS100 application.

Once the operator logs in, clear all 706 and clear 708 buttons are enabled. Fig. 9 is a schematic view of a GUI home screen 900 with specialized features (e.g., clear all button 706 and clear button 708) enabled after login, according to an embodiment. The clear all button 706 clears all alarms represented by the alarm banner 702 when the clear all button 706 is selected, regardless of any selection of any alarm banner 702 row. The clear button 708, when selected, clears the security event associated with the selected alert banner 702. To select the alert banner 702, the operator may simply tap the alert banner 702. The selected alert banner 702 will change a characteristic (e.g., color) to indicate that the alert banner 702 is selected. Also, the second tap of the alert banner 702 can deselect the alert banner 702.

As illustrated, after the operator is logged in, a log-out button 902 is also provided. The logout button 902, when selected, will cause the operator to be logged out (and the home screen 700 with the grayed-out option is again displayed).

In addition to providing alerts generated from the security appliances 102, the DRSS100 can also generate alerts based on localized events. For example, fig. 10 is a schematic view of a GUI 1000 of a DRSS100 presenting errors, according to an embodiment. In the illustrated embodiment, the sensor communication failure message 1002 is presented indicating that a security event (e.g., Syslog message) is not being received by the DRSS 100. To ensure that false errors are not presented in the absence of a security event, the DRSS100 application can receive heartbeat messages from a security sensor (e.g., Syslog server/security appliance 102) at regular intervals. As used herein, a heartbeat message is a periodic expected message that can be used to determine when a message is not being received by the DRSS 100. If a heartbeat message is not detected, the application will present GUI 1000, indicating a heartbeat failure. Once the heartbeat message is detected, GUI 1000 will disappear and the application will resume normal operation. In some embodiments, the number of allowable missing heartbeat messages and the interval of heartbeat messages before generating an alert is configurable.

The DRSS100 may include additional local alerts. The following is a list of additional alarms, along with severity characterization and description.

As mentioned herein, the DRSS100 can be configurable in a number of ways to create personalized alert presentations and control experiences suitable for many applications. In some embodiments, the DRSS100 application may include an XML configuration file to load configurable parameters without the need to reinstall the application. The following is a list of configuration parameters, default values, and descriptions for each of the configuration parameters. As may be appreciated, this is a list of possible configuration parameters, but is not intended to limit the scope to such configuration parameters. Indeed, in alternative embodiments, fewer or more configuration parameters can be presented as options.

The technology presented and claimed herein is cited and applied to substantive objects and concrete examples of a practical nature which arguably improve the technical field and are therefore not abstract, intangible or purely theoretical. Also, if any claim appended to the end of this specification contains one or more elements designated as "means for [ performing ] … … [ function" or "step for [ performing ] … … [ function"), it is intended that such elements be construed in accordance with 35u.s.c.112 (f). However, for any claim that contains elements specified in any other way, it is intended that such elements will not be construed in accordance with 35u.s.c.112 (f).