Safety appliance extension

Abstract

The present disclosure provides for security appliance extensions. Systems and methods of receiving and characterizing security event data are disclosed. Presentation and / or control actions, such as prioritized presentation and alarm generation, are performed based on the customized severity characterized security event data.

Description

[0001] This application is a divisional application of a patent application with application number 202080020484.X, application date March 10, 2020, and name “Safety Equipment Extension”. CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 817,304, entitled “SAFETY APPLIANCE EXTENSION” and filed on March 12, 2019, the disclosure of which is incorporated herein by reference for all purposes. Background Art

[0003] The present disclosure generally relates to a security appliance. More specifically, certain embodiments of the present disclosure relate to a user interface that implements specific actions based on characterization of events generated in a security log.

[0004] In the digital age, the proliferation of digital data has given rise to an increased need for cybersecurity that is tasked with protecting that digital data. Typically, cybersecurity threats are presented to a security operations center (SOC) or a network operations center (NOC), where cybersecurity teams are tasked with monitoring, prioritizing, and remediating these cybersecurity threats. Unfortunately, however, as the number of cybersecurity threats is rising, reliance on human subjectivity to prioritize and remediate these threats is becoming increasingly inefficient. Therefore, there is a need to provide improved prioritization, presentation, and remediation actions for cybersecurity incidents that are not encumbered by the inefficiencies of human subjectivity.

[0005] This section is intended to introduce the reader to various technical aspects that may be related to various aspects of the present disclosure, which are described and / or claimed below. This discussion is considered to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Therefore, it should be understood that these statements will be read from this perspective, rather than as an admission of the prior art. Summary of the invention

[0006] Certain embodiments corresponding 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, these embodiments are intended only to provide a brief summary of certain disclosed embodiments. In fact, the present disclosure may include a variety of forms that may be similar or different from the embodiments set forth below.

[0007] 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, security events are characterized based on a customized severity characterization mapping. The customized severity characterization for the event is used to determine a specific set of actions to implement for the action.

[0008] By way of example, in an embodiment, the electronic device includes an embedded computer having one or more processors. The processor receives 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. 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. Then, the one or more presentation or control actions are performed by the processor.

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

[0010] 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 a 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 a severity expected by the computer identified based on a mapping to a severity indicated in at least one or more security event messages. The method further includes: determining one or more presentation or control actions to be performed based on the customized severity characterization; and performing the one or more presentation or control actions. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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 refer to like parts throughout the drawings, and in which: Figure 1 is a schematic diagram illustrating a detection and response safety system (DRSS) according to an embodiment of the present disclosure; Figure 2is a flow chart illustrating a process for characterizing a security event according to an embodiment of the present disclosure; Figure 3 is a flow chart illustrating a process for implementing presentation and control actions based on security event classification according to an embodiment; Figure 4 is a schematic diagram of a safety appliance extended user interface according to an embodiment; Figure 5 is a schematic diagram of a rear view of a safety appliance extended user interface according to an embodiment; Figure 6 is a schematic view of a graphical user interface (GUI) illustrating security event data collection by a DRSS according to an embodiment; Figure 7 is a schematic diagram of a GUI presenting a DRSS according to an embodiment; Figure 8 is a schematic view of a GUI of a DRSS for logging into a specialized feature according to an embodiment; Fig. 9 is a schematic view of a GUI of a DRSS presenting specialized features after login according to an embodiment; and Fig.10 is a schematic diagram of a GUI of a DRSS presenting an error, according to an embodiment. DETAILED DESCRIPTION

[0012] 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 order to provide a concise description of these embodiments, all features of the 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, many implementation-specific decisions must be made to achieve the developer's specific goals that may vary from implementation to implementation, such as compliance with system-related constraints and business-related constraints. In addition, it should be appreciated that such development efforts may be complex and time-consuming, but for ordinary technicians who benefit from the present disclosure, such development efforts may be nothing more than routine tasks of design, production, and manufacturing.

[0013] 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 in addition to 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 to exclude the existence of additional embodiments that also incorporate the recited features.

[0014] The present disclosure generally relates to a detection and response security system (DRSS) that provides automatic prioritization and presentation. The DRSS can facilitate control actions from a user interface to achieve rapid response to network security threats. In view of this, Figure 1 is a schematic diagram illustrating a detection and response security system (DRSS) 100 according to an embodiment of the present disclosure. The DRSS 100 provides an indication of a security event generated by a security appliance 102, which is monitoring a 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 a network security event, which may be indicated by a message logging of the event. For example, as used herein, "Syslog" 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, thus, the 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, a Syslog message can provide a facility code that is used to specify the type of program to log the message. A table of facility codes with associated keywords and descriptions is provided below:

[0015] In addition, a Syslog message may include a list of severities. A table of severities that may be present in a Syslog message is provided below:

[0016] The DRSS 100 may include a security appliance extension (SAE) 108 that may receive a Syslog output from the security appliance 102. The security appliance extension 108 and / or the security appliance 102 may translate the Syslog message so that the security appliance extension 108 may provide a graphical user interface and / or a stack light output that provides an ease of interpretation of the instructions for the Syslog message. The translation of the Syslog message results in a computer-implemented customized severity characterization of the Syslog message that must be performed based on the components of the Syslog message (e.g., severity values ​​and / or facility codes). The customized severity characterization can be used to determine a severity characterization that is different from a secure native severity classification. It is useful to generate customized severity characterizations that are specific to a particular type of protected component, etc. For example, an amusement park attraction can have a severity characterization for security events that is very different from an online gaming server environment, etc.

[0017] To perform this action, a syslog mapping script 110 may be executed at the security appliance 102 and / or the embedded computer 106. The syslog mapping script 110 results in characterization of the Syslog message according to the characteristics of the Syslog message. Based on the characterization, the SAE 108 may provide a graphical presentation of the Syslog event and / or may actuate one or more lights in the stack of lights in a particular pattern to indicate the Syslog event using the particular characterization.

[0018] To implement SAE 108 functionality, DRSS 100 may interface with internal and external sources. For example, DRSS 100 may interface with security appliance 102 (e.g., Syslog server), which is an external security sensor that sends Syslog messages to DRSS 100. DRSS 100 may continuously listen for incoming messages and handle (e.g., characterize) the messages according to their severity and / or other message characteristics.

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

[0020] Furthermore, the DRSS 100 may log data in the database 114. For example, the database 114 may include a table including data that configures alarm colors to be associated with various characterizations of Syslog messages. Furthermore, a Syslog table of Syslog messages received from a Syslog server may be maintained in the database 114 along with an indication of when and by whom the Syslog messages were cleared. The DRSS 100 may periodically run a cleanup routine as part of the maintenance of the database 114 that clears the Syslog table.

[0021] The DRSS 100 may also include programmable logic to handle input / output (IO) interactions with the DRSS 100. The PLC 116 receives commands from the SAE 108 application running on the DRSS 100 and executes the commands based on the SAE 108 IO.

[0022] Ideally, the DRSS 100 is continuously monitored to ensure that the DRSS 100 is not currently unable to provide a Syslog event indication. Thus, in some embodiments, one task of the PLC 116 is to perform a "monitor" function that continuously monitors the DRSS 100 to determine if the SAE 108 application of the DRSS 100 and / or the operating system of the embedded computer 106 has failed. To perform this action, the PLC 116 continuously changes the state of variables in the PLC 116. Upon detecting that a state change has not occurred / has not been reported by the SAE 108 application within a threshold period (e.g., 10 seconds), a monitor fault is generated and a corresponding alarm is presented by the DRSS 100. For example, a special stack light actuation may be presented to indicate a monitor fault. In one embodiment, the special stack light actuation turns off the green stack light and the blue stack light and engages the yellow stack light and the red stack light. Additionally and / or alternatively, in some embodiments, an audible alarm is engaged to signal a monitor fault.

[0023] To reset a monitor fault, a special bypass IO may be used. For example, in one embodiment, the Run / Bypass key switch may be switched to "Bypass" to silence the alarm. The "Reset" key switch may be turned and held for a certain period of time (e.g., at least 10 seconds), causing the embedded computer 106 to shut down. Releasing the hold on the "Reset" key causes the embedded computer 106 to restart. The DRSS 100 may then restart the SAE 108 application, and the Run / Bypass key switch may be switched to "Run" to ensure that subsequent monitor faults are not bypassed.

[0024] Turning to the discussion of the characteristics of Syslog messages, Figure 22 is a flow chart illustrating a process 200 for characterizing a security event according to an embodiment of the present disclosure. The process 200 begins by monitoring (block 202) for events (e.g., Syslog messages) associated with a protected component. As mentioned above, a Syslog server can provide a Syslog message to the DRSS 100, indicating that a security event has occurred. If an event is not detected at decision block 204, monitoring continues until an event is detected.

[0025] When an event is detected, the event is characterized (e.g.,) based on a DRSS 100 Syslog mapping (block 206). As mentioned above, the characterization can be implemented by executing a Syslog mapping script 110 at the security appliance 102 / Syslog server and / or at the embedded computer 106 of the DRSS 100. The characterization can map one or more characteristics of the Syslog message into DRSS severity levels, which in some embodiments can include three different severity levels: Severity 4: High / Critical, Severity 3: Medium, and Severity 2: Low. For example, a Syslog message including a severity of 0-2 in a Syslog message can be mapped to a characterization of severity 4 for DRSS 100 purposes. Moreover, a Syslog message having a severity of 3-4 can be mapped to a characterization of severity 3 for DRSS 100 purposes. A Syslog message having a severity of 5-7 can be mapped to a characterization of severity 2 for DRSS purposes. By characterizing the reduction of Syslog severity from 7 to 3 severity, improved prioritization efficiency may be observed. Furthermore, the Syslog mapping script 110 may be customized to provide fewer or more severity levels, and may map a greater number of items found in Syslog messages. For example, a combination of a Syslog severity and a specific facility may be mapped to a higher severity in DRSS 100 than a combination of the same Syslog severity and a different facility code.

[0026] Once the characterization is determined, a Syslog message (e.g., a security event) is associated with the characterization and provided for use by the SAE 108 (block 208). The characterization may be used to effectuate presentation and / or control actions at the SAE 108 for the Syslog message. For example, in some embodiments, for a Syslog message characterized as a severity 4 event, a flashing red light may be actuated along with an audible alarm. Also, a red alarm banner may be presented on a graphical user interface (GUI) of the SAE 108. Additionally, status variables maintained by the embedded computer 106 may be converted. For example, both a variable indicating "no alarm present" and a variable indicating "no critical alarm present" may be turned off. For a Syslog message characterized as severity 3, different actions may occur. In one embodiment, a continuous red light is actuated. Also, a red alarm 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 status. For Syslog messages characterized as Severity 2, a continuous yellow light may be activated. A yellow alarm banner may be presented at 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 remain the same.

[0027] Turning now to a more detailed discussion of characterization-based presentation and control actions, Figure 3 2 is a flow chart illustrating a process 300 for implementing presentation and control actions based on security event classification according to an embodiment. As mentioned above, a security event (e.g., a Syslog message) is received (block 302). Characterizations for the security event are identified (block 304). For example, the characterizations performed in process 200 can be stored in database 114 and retrieved to identify characterizations for the security event.

[0028] The presentation and / or control action for the security event may be determined based on the characterization (block 306). For example, stack lights / light emitting diodes (LEDs) and / or audio actuation may be determined based on the characterization as follows:

[0029] The diagnostic matrix below provides another indication of the actuation indicated in the table above, which also indicates the IO key setting for the Run / Bypass key switch, which is described in more detail below. It should also be noted that multiple safety events with multiple characterizations can exist simultaneously. Therefore, multiple of these actuations can exist in combination with each other. A B C D E F G Red light - continuous X X X Red light-flash X Yellow light-continuous X X X Blu-ray - Continuous X X Green light - continuous X X X Sound-Flash X X Sound - Continuous X X A. The Run / Bypass key switch is in "Run" B. Run / Bypass key switch in "Bypass" C. High / Critical Alarm D. Medium Alert E. Low Alarm F. Monitor failure G. Test light push button is pressed

[0030] In the above table, the leftmost column provides an indication of the LED and alarm outputs of the DRSS 100. The top row provides an indication of the DRSS 100 states (summarized in key items AG below the table). An "X" indicates which of the DRSS 100 states cause a specified LED and alarm output of the DRSS 100. In some embodiments, this table of LED and alarm outputs and their corresponding DRSS 100 states is a representation of logic implemented in circuitry and / or machine-readable instructions implemented by the DRSS 100.

[0031] When appropriate presentation and / or control actions are determined, these presentation and / or control actions are implemented by the DRSS 100 (block 308). For example, as will be discussed in more detail below, the stack lights may be wired to the DRSS via a junction box located on the rear of the unit. LEDs may be wired together to the stack lights to display a common indication.

[0032] Figure 4 4 is a schematic diagram of a safety appliance expansion (SAE) panel 400 with stack lights 402 according to an embodiment. The SAE panel 400 notifies an operator of system alarms received from an external source (e.g., a Syslog server) and can optionally interface with an external system to provide external control to the protected component 104. Once the alarm action to be implemented is identified, the DRSS 100 will activate the necessary LED 404 modules and stack light 402 modules. Furthermore, it can be presented on a display 406 that displays the SAE 108 / DRSS 100 application and provides 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 can be a touch screen that enables the operator to clear the security event and implement other control operations.

[0033] The SAE panel 400 may include a key switch 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 a run mode or a bypass mode depending on which of the two positions the switch is enabled to. In bypass mode, the control interface output ignores the present alarm and is maintained ON. The DRSS 100 application continues to display and log the alarm. As described herein, in run mode, the control interface output is actuated based on the received safety event.

[0034] Furthermore, a reset switch 403B may also be provided. As discussed above, the reset switch 403B may be a key switch that can be turned and held for a certain 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 the embedded computer 106 to restart.

[0035] Discussing LED 404 in more detail, 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., continuous). LED 404B is a warning LED that indicates a low alarm characterization. LED 404C is a health LED that indicates that all interfaces are connected and the run / bypass key is in the "run" position, not in the "bypass position." LED 404D is an IO connected LED that indicates that the PLC 116 is connected and the IO logic is running.

[0036] Now turning to the external interface of SAE 108, Figure 5 is a schematic diagram of a rear view of the SAE panel 400 according to an embodiment. As illustrated, the SAE panel 400 includes a cooling fan 502 that provides airflow to the SAE panel 400 .

[0037] The SAE panel 400 includes a first communication port 504 (here, an RJ45 Ethernet port) for enabling the embedded computer 106 to communicate with a Syslog server (e.g., Figure 1 The server provides Syslog messages as previously described, which ultimately become characteristic security events that trigger presentation and / or control actions, as discussed herein.

[0038] The SAE panel 400 also includes a second communication port 506 (here, an RJ45 Ethernet port) for connecting the embedded computer 106 to the Figure 1The domain controller 112 is communicatively coupled to the UE. As previously mentioned, the domain controller 112 can facilitate user authentication to implement protected control functions, as will be discussed in more detail below.

[0039] The SAE panel 400 also includes a stack light / test light push button interface 508. The stack light / test light push button interface 508 is used to enable Figure 4 The terminals of the alarm indicator stack light 402 and the test light push button are connected, and the test light push button can be pressed to perform a diagnostic lighting test of the stack light 402. The diagnostic test causes a momentary activation of all lights and sounds on the stack light 402.

[0040] The SAE panel 400 also includes a control interface 510. The control interface 510 connects the SAE panel 400 to an external interface to include possible triggers for presentation and / or control actions. The PLC 116 can provide a specified output via the control interface 510 to establish continuity between the output and a common terminal located on the control interface junction box. If the specified condition is met, the PLC 116 changes the output status, resulting in a broken continuity. The remote interface outputs supported by the control interface 510 include: no alarms, which are maintained as ON but turn OFF in the presence of any alarm; and no critical alarms, which are paired outputs that are maintained as ON but turn OFF only when there are critical alarms. As mentioned above, these changes in status are activated when the run / bypass key switch 403A is switched to "run". However, when the run / bypass key switch 403A is switched to "bypass", no matter what alarms are present, the no alarm output and the no critical alarm output will be maintained as ON.

[0041] In some embodiments, the control interface 510 may cause operational changes to the protected component. For example, the control interface 510 may be connected to an amusement attraction and control the operation of the amusement attraction based on the characterized safety event / generated alarm. For example, in the presence of a critical severity safety event, the amusement attraction (e.g., a ride) may be stopped and actions may be taken.

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

[0043] Now turning to a more detailed discussion of the DRSS100 / SAE 108 application GUI, Figure 6 is a schematic view of a graphical user interface (GUI) start screen 600 illustrating security event data collection by DRSS according to an embodiment. As previously mentioned, the DRSS100 application is responsible for listening for incoming security events (e.g., Syslog messages) and alerting the operator of such messages via stack lights, LEDs, and alarm banners. The application is capable of logging an alarm history to include the time received, the time the alarm was cleared, and the user who cleared the alarm. As mentioned above, the application can be secured using domain authentication and can include a native validation UI that authenticates at the application level rather than requiring the user to switch at the operating system level.

[0044] As illustrated in the startup screen 600, when the DRSS100 application is first started, the DRSS100 runs a startup process during which the DRSS100 connects to all system interfaces. If an interface fails to communicate, a message describing the communication failure will be displayed on the startup screen 600, and the application will automatically attempt to reconnect after a certain period of time (e.g., 10 seconds). Once the initial data set is retrieved (e.g., data indicating event messages and / or communications with system interfaces), the progress bar 602 will indicate 100% completion of the loading process and the startup screen 600 will transition to the main display screen. During the loading process, the operator is able to log in using a login affordance 604. By logging in, the operator is able to perform protected actions that are only available to authenticated users. The login process will be discussed in more detail below.

[0045] Figure 7 7 is a schematic view of a DRSS 100 application GUI main display screen 700 according to an embodiment. The main display screen 700 provides an alert banner 702 of active alerts, which the alert banner 702 of active alerts is received by the DRSS 100. The alert banners are prioritized, wherein the highest priority alerts are presented first. Moreover, security events are provided by differentiating the banners 702. For example, banner 702A is a red banner and provides a textual indication indicating that the security alert associated with banner 702A is characterized as a severity 3 security event. In contrast, banners 702B-D are each associated with a security event characterized as a severity 2 security event.

[0046] A mute button 704 is provided on the main display screen 700, which, when activated, silences any currently audible alarm for a configurable amount of time (e.g., a default time of 30 seconds). In some embodiments, the mute button 704 does not require user verification to activate. However, as illustrated by the grayed-out clear all button 706 and clear button 708, in some embodiments, these options can only be selected at login (e.g., by performing a login process via selection of the login button 604).

[0047] Figure 8 800 is a schematic diagram of a GUI login screen 800 according to an embodiment. The login screen 800 enables an operator to enter login credentials (e.g., user ID 802 and password 804). In alternative embodiments, other login credentials such as biometrics, physical keys, etc. may be used to log into the DRSS100 application.

[0048] Once the operator is logged in, the clear all button 706 and the clear button 708 are enabled. Fig. 9 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. When the clear all button 706 is selected, regardless of any selection of any alert banner 702 row, the clear all button 706 clears all alerts represented by the alert banner 702. The clear button 708 clears the security events associated with the selected alert banner 702 when selected. To select the alert banner 702, the operator can simply tap the alert banner 702. The selected alert banner 702 will change characteristics (e.g., color) to indicate that the alert banner 702 is selected. Moreover, the alert banner 702 can be deselected by tapping the alert banner 702 a second time.

[0049] As illustrated, after the operator is logged in, a logout 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 to be displayed again).

[0050] In addition to providing alarms generated from safety appliances 102, DRSS 100 can also generate alarms based on localized events. For example, Fig.101 is a schematic view of a GUI 1000 of a DRSS 100 presenting an error according to an embodiment. In the illustrated embodiment, a sensor communication failure message 1002 is presented, indicating that a security event (e.g., a Syslog message) is not being received by the DRSS 100. In order to ensure that false errors are not presented when there is no security event, the DRSS 100 application can receive heartbeat messages from security sensors (e.g., Syslog servers / security appliances 102) at fixed 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 a GUI 1000, indicating that the heartbeat is ineffective. Once the heartbeat message is detected, the GUI 1000 will disappear, and the application will restart normal operation. In some embodiments, the number of allowable missing heartbeat messages and the interval of the heartbeat messages before generating an alarm are configurable.

[0051] The DRSS 100 may include additional local alarms. Below is a list of additional alarms, along with severity characterizations and descriptions.

[0052] As mentioned herein, DRSS100 can be configurable in many ways, thereby creating a personalized alarm presentation and control experience suitable for many applications. In some embodiments, the DRSS100 application may include an XML configuration file for loading configurable parameters without reinstalling the application. The following is a list of configuration parameters, default values, and descriptions for each of the configuration parameters. As can be appreciated, this is a list of possible configuration parameters, but it is not intended to limit the scope to such configuration parameters. In fact, in alternative embodiments, fewer or more configuration parameters can be presented as options.

[0053] The technology presented and claimed herein is cited and applied to substantial objects and specific examples of a practical nature that arguably improve the art and are therefore not abstract, intangible, or purely theoretical. Moreover, if any claim appended at the end of this specification contains one or more elements designated as "a means for [performing] ... [function]" or "a step for [performing] ... [function]," it is intended that such elements will be interpreted in accordance with 35 U.S.C. 112(f). However, for any claim containing elements designated in any other manner, it is intended that such elements will not be interpreted in accordance with 35 U.S.C. 112(f).

Claims

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 based on one or more characteristics of the one or more security events, wherein the customized severity characterization is not defined by the security appliance; determining one or more presentation or control actions to be implemented based on the customized severity characterization; as well as The one or more rendering or control actions are performed.

2. The electronic device according to 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 safety appliance to a specific customized severity characterization expected by the embedded computer.

3. The electronic device according to 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 according to claim 2, wherein: The one or more processors of the embedded computer are configured to execute the mapping script.

5. The electronic device according to claim 2, wherein: The customized severity characterization is received from the safety appliance.

6. The electronic device according to claim 1, comprising a display, wherein: The one or more presentation or control actions include: presenting, via a graphical user interface (GUI) on the display, one or more alert banners associated with the one or more security event messages, the one or more alert banners being displayed based on the customized severity characterization; or, presenting, via a stack light, one or more visual alert indications associated with the one or more security event messages, the one or more visual alert indications being based on the customized severity characterization; or, Both.

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

8. The electronic device according to claim 7, wherein: The protected component includes an amusement attraction.

9. The electronic device according to claim 1, wherein: The one or more security event messages include messages generated according to a Syslog standard for message logging.

10. The electronic device according to 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; or, receiving the one or more output indications and presenting the one or more output indications via the one or more I / O devices; or, Both.

11. The electronic device according to claim 10, wherein: the one or more I / O devices comprising a set of one or more lights, the set of one or more lights providing an indication of the customized severity characterization; wherein the set of one or more lights includes a fault light emitting diode (LED) that selectively indicates a critical severity security event when in a first state and a medium severity security event when in a second state; and Wherein the set of one or more lights includes a healthy light emitting diode (LED) that indicates whether all expected interfaces are communicatively coupled to the electronic device.

12. The electronic device according to claim 10, wherein: The embedded computer is configured as follows: 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 A fault is provided in response to not detecting the continuously changing variable state within the threshold amount of time, the fault indicating a malfunction of the embedded computer.

13. The electronic device according to claim 10, wherein: The one or more I / O devices include a run / bypass switch, the run / bypass switch: while in the run mode, causing logging and presentation of one or more alert banners associated with the one or more security event messages, and when they are received, causing presentation of one or more alerts associated with the one or more security event messages; as well as When in bypass mode, cause logging and presentation of the one or more alert banners associated with the one or more security event messages, and cause suppression of presentation of the one or more alerts associated with the one or more security event messages when they are received.

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

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 based on one or more characteristics of the one or more security events, wherein the customized severity characterization is not defined by the security appliance; determining one or more presentation or control actions to be implemented based on the customized severity characterization; as well as The one or more rendering 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: The customized severity characterization is identified by executing a mapping script that maps one or more characteristics of the one or more security event messages received from the safety appliance to a specific 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: In a graphical user interface (GUI) of the computer, one or more alert banners corresponding to the one or more security event messages are presented 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) has not been detected at the computer within a threshold amount of time; and A fault is provided in response to not detecting the continuously changing variable state within the threshold amount of time, the fault indicating a malfunction of the computer.

19. A computer-implemented method comprising: receiving, via the 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 based on one or more characteristics of the one or more security events, wherein the customized severity characterization is not defined by the security appliance; determining one or more presentation or control actions to be implemented based on the identified customized severity characterization; as well as The one or more rendering 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; or, presenting, via a stack light, one or more visual alert indications associated with the one or more security event messages, the one or more visual alert indications being based on the customized severity characterization; or, Both.

Images