Security appliance extension

Abstract

A system and method for receiving and characterizing security event data are disclosed. Based on customized severity-characterized severity event data, presentation and / or control actions, such as prioritized presentation and alarm generation, are performed.

Description

Technology Field

[0001] Cross-reference regarding related applications

[0002] This application claims priority to U.S. Provisional Application No. 62 / 817,304, filed on March 12, 2019, under the title “Security Appliance Extension,” the disclosures of which are incorporated herein by reference for all purposes. Background Technology

[0003] The present disclosure generally relates to security appliances. More specifically, a particular embodiment of the present disclosure relates to a user interface that performs a specific action based on the characterization of events generated in a security log.

[0004] In the digital age, the rapid increase in digital data has led to a growing demand for cybersecurity to protect this data. Typically, cybersecurity threats are reported to the Security Operation Center (SOC) or Network Operations Center (NOC), where cybersecurity teams monitor, prioritize, and remediate them. Unfortunately, however, as the number of cybersecurity threats has increased, prioritizing and remediating them based on human subjectivity has become increasingly inefficient. Therefore, there is a need to provide improved prioritization, presentation, and remediation actions for cybersecurity events without the burden of the inefficiency inherent in human subjectivity.

[0005] This paragraph is intended to introduce to the reader various aspects of the technology that may be related to the various aspects of the technology described and / or claimed below. It is assumed that such description will help provide the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, this description should be read in this context and should be understood as not constituting an acknowledgment of prior art. The problem to be solved

[0006] Specific embodiments corresponding to the scope of the originally claimed subject matter are briefly disclosed below. These embodiments are not intended to limit the scope of the disclosure and are merely to provide a brief overview of specific disclosed embodiments. In practice, the disclosure may include various forms similar or different from the embodiments described below.

[0007] The embodiments described herein relate to a security appliance extension that efficiently receives and prioritizes security events and implements security event actions based on these security events. More specifically, security events are characterized based on a customized severity characterization mapping. The customized severity characterization for an event is used to determine a specific set of actions to implement for that action.

[0008] For example, in one 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, wherein each of the one or more security event messages represents a security event associated with a protected component. The processor identifies a customized severity characterization of one or more security event messages and, based on the customized severity characterization, determines one or more presentation or control actions to be performed. Subsequently, one or more presentation or control actions are performed by the processor.

[0009] In one embodiment, a type of non-transient computer-readable medium comprises computer-readable instructions. When instructions are executed by one or more processors of a computer, the computer receives one or more security event messages from a security appliance. Each of the one or more security event messages represents a security event associated with a protected component. When instructions are executed by one or more processors of a computer, the computer also identifies customized severity characterizations of one or more security event messages, determines one or more presentation or control actions to be performed based on the customized severity characterizations, and performs one or more presentation or control actions.

[0010] In one embodiment, a computer-implemented method includes the step of receiving one or more security event messages from a security appliance through a computer. Each of the one or more security event messages represents a security event associated with a protected component. The method also includes the step of identifying a customized severity characterization of one or more security event messages through a computer. The customized severity characterization includes a severity expected by the computer, identified based on a mapping to at least one severity appearing in one or more security event messages. The method further includes the step of determining one or more presentation or control actions to be performed based on the customized severity characterization, and the step of performing one or more presentation or control actions. Brief explanation of the drawing

[0011] These features, aspects, advantages, and other features, aspects, and advantages of the present disclosure will be better understood by reading the following description in conjunction with the accompanying drawings, and throughout the drawings, the same reference numerals indicate the same components. FIG. 1 is a schematic diagram showing a DRSS (Detection and Response Security System) according to an embodiment of the present disclosure. FIG. 2 is a flowchart illustrating a process for characterizing security events according to an embodiment of the present disclosure. FIG. 3 is a flowchart illustrating a process for performing presentation and control actions based on security event classification according to one embodiment. FIG. 4 is a schematic diagram of a security appliance extension user interface according to one embodiment. FIG. 5 is a schematic diagram of the back side of a security appliance extension user interface according to one embodiment. FIG. 6 is a schematic diagram of a graphical user interface (GUI) illustrating security event data capture by DRSS according to one embodiment. FIG. 7 is a schematic diagram of a GUI of a DRSS presenting security events according to one embodiment. FIG. 8 is a schematic diagram of a GUI of DRSS for logging into a special function according to one embodiment. FIG. 9 is a schematic diagram of a GUI of DRSS that presents special functions after login, according to one embodiment. FIG. 10 is a schematic diagram of a GUI of a DRSS that presents errors according to one embodiment. Specific details for implementing the invention

[0012] One or more specific embodiments of the present disclosure are described below. These described embodiments are merely examples of the technology currently disclosed. Furthermore, in order to provide a concise description of these embodiments, not all features of actual embodiments may be described in this specification. It should be recognized that when deploying any of these actual embodiments, as in any engineering or design project, a number of implementation-specific decisions must be made to achieve the developer's specific objectives, such as complying with system-related and business-related constraints that may vary from embodiment to embodiment. Furthermore, it should be understood that while such development efforts are complex and time-consuming, they may nevertheless be routine tasks of design, manufacturing, and production for those skilled in the art who benefit from the present disclosure.

[0013] When introducing elements of various embodiments of the present disclosure, singular expressions may imply that one or more of the elements are present. The terms “comprising,” “comprising,” and “having” are inclusive and imply that additional elements may exist in addition to those listed. Furthermore, any reference to “one embodiment” or “an embodiment” in the present disclosure should not be interpreted as excluding the possibility of additional embodiments that also include the specified features.

[0014] The present disclosure generally relates to a Detection and Response Security System (DRSS) that provides automatic prioritization and presentation of cyber security events. The DRSS facilitates control actions from a user interface, thereby enabling a rapid response to cyber security threats. In this regard, FIG. 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 a display of security events generated by a security appliance (102) that monitors a protected component (104). In some embodiments, the protected component (104) may be an amusement park attraction. The security appliance (102) monitors cyber security events from the protected component (104), which may be displayed by message logging of the events. For example, "Syslog" as used herein refers to a standard for message logging. Although the term "Syslog" is used in this specification, it will be understood that the use of the term "Syslog" does not limit the current technology to the Syslog standard, as the current technology may cover various message logging standards. The Syslog message logging standard includes many message components. For example, a Syslog message may provide function code used to specify the type of program logging the message. A table of function codes, including related keywords and descriptions, is as follows.

[0015]

[0016] Furthermore, Syslog messages can include a list of severity levels. The severity tables that can be presented in Syslog messages are as follows.

[0017]

[0018] DRSS (100) may include a Security Appliance Extension (SAE) (108) capable of receiving Syslog output from a security appliance (102). The SAE (108) and / or the security appliance (102) can translate Syslog messages, so that the SAE (108) can provide a graphical user interface and / or stacked optical output that makes it easier to interpret the representation of the Syslog message. Translation of the Syslog message involves computer-implemented customized severity characterization of the Syslog message based on the components of the Syslog message (e.g., severity value and / or function code). Customized severity characterization can be used to determine severity characteristics different from the basic severity classification of the security message. This may be useful for creating customized severity characterization tailored to a specific type of protected component, etc. For example, amusement park attractions can have severity characteristics for security events that are completely different from online game server environments.

[0019] To this end, a Syslog mapping script (110) may be executed on a security appliance (102) and / or an embedded computer (106). The Syslog mapping script (110) results in the characterization of Syslog messages based on the characteristics of the Syslog messages. Based on this characterization, the SAE (108) may provide a graphical presentation of the Syslog events and / or may activate one or more lights of a stack light in a specific pattern to represent the Syslog events with a specific characterization.

[0020] To perform the SAE (108) function, the DRSS (100) can interface with internal and external sources. For example, the DRSS (100) can interface with a security appliance (102) (e.g., a Syslog server), which is an external security sensor that sends Syslog messages to the DRSS (100). The DRSS (100) continuously listens for incoming messages and handles (e.g., characterizes) these messages according to their severity and / or other message characteristics.

[0021] Furthermore, the DRSS (100) can interface with the domain controller (112). The domain controller can enable user authentication for the DRSS (100) and the SAE (108). As described in more detail below, user authentication can enable the functions of the SAE (108), and unauthorized users cannot use the functions of the SAE (108). In an embodiment that interfaces with the domain controller (112), the DRSS (100) can continuously check for a healthy connection to the domain controller (112) and generate an alarm if the healthy connection is lost.

[0022] Additionally, the DRSS (100) may write data to the database (114). For example, the database (114) may include a table containing data for configuring alarm colors to be associated with various characteristics of Syslog messages. Additionally, 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 execute a cleanup procedure to remove the Syslog table as part of the maintenance of the database (114).

[0023] The DRSS (100) may also include a programmable logic controller (PLC) (116) that handles input / output (IO) interactions with the DRSS (100). The PLC (116) receives commands from an SAE (108) application running on the DRSS (100) and executes the commands based on the IO of the SAE (108).

[0024] It is desirable to continuously monitor the DRSS (100) to ensure that the DRSS (100) does not fail to provide Syslog event indications. Accordingly, in some embodiments, one task of the PLC (116) is to execute a "watchdog" function that continuously monitors the DRSS (100) to determine whether the SAE (108) application of the DRSS (100) and / or the operating system of the embedded computer (106) has failed. To this end, the PLC (116) continuously changes the state of a variable in the PLC (116). If it is detected that a state change has not occurred / reported by the SAE (108) application within a threshold period (e.g., 10 seconds), a watchdog error is generated and a corresponding alarm is presented by the DRSS (100). For example, a special stack light activation may be presented to indicate a watchdog error. In one embodiment, the special stack light activation turns off the green and blue stack lights and uses the yellow and red stack lights. In addition to this and / or as another method, in some embodiments, an audible alarm is used to signal a watchdog error.

[0025] To reset the watchdog error, 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 kept on for a certain period (e.g., at least 10 seconds) to turn off the power of the embedded computer (106). When the hold of the "reset" key is released, the embedded computer (106) restarts. Afterward, the DRSS (100) may restart the SAE (108) application and the run / bypass key switch may be switched to "run" to ensure that subsequent watchdog errors are not bypassed.

[0026] Moving on to the description of characterizing Syslog messages, FIG. 2 is a flowchart illustrating a process (200) for characterizing security events according to an embodiment of the present disclosure. The process (200) is initiated by monitoring an event (e.g., a Syslog message) related to a protected component (block 202). As mentioned above, a Syslog server may provide a Syslog message to the DRSS (100) indicating that a security event has occurred. If no event is detected in the determination block (204), monitoring continues until an event is detected.

[0027] When an event is detected, the event (e.g., a Syslog message) is characterized based on a DRSS (100) Syslog mapping (block 206). As mentioned above, the characterization can be implemented by executing a Syslog mapping script (110) on the security appliance (102) / Syslog server and / or the embedded computer (106) of the DRSS (100). This characterization can map one or more characteristics of a Syslog message to a DRSS severity level, and in some embodiments, this severity level may include three different severity levels such as Severity 4: High / Critical, Severity 3: Medium, and Severity 2: Low. For example, a Syslog message containing severity 0 through 2 may be mapped to a severity 4 characterization for the purposes of the DRSS (100). Additionally, Syslog messages with severity levels 3 to 4 can be mapped to severity level 3 characterizations for the purposes of DRSS (100). Syslog messages with severity levels 5 to 7 can be mapped to severity level 2 characterizations for the purposes of DRSS. By reducing the Syslog severity from 7 to severity level 3 characterizations, priority efficiency can be increased. Additionally, the Syslog mapping script (110) can be customized to provide fewer or more severity levels and can be mapped to multiple items found in Syslog messages. For example, a combination of Syslog severity and a specific function can be mapped to a higher severity in DRSS (100) than combining the same Syslog severity with different function codes.

[0028] When a 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 can be used by the SAE (108) to perform presentation and / or control actions on the Syslog message. For example, in some embodiments, for a Syslog message characterized as a severity 4 event, a flashing red light may be activated along with an audible alarm. Additionally, a red alarm banner may be presented on the GUI (Graphical User Interface) of the SAE (108). Furthermore, a status variable maintained by the embedded computer (106) may be toggled. For example, a variable indicating "no alarm" and a variable indicating "no critical alarm" may both be toggled off. For a Syslog message characterized as severity 3, other actions may occur. In one embodiment, a fixed red light is activated. Additionally, a red alarm banner may be presented on the GUI of the SAE (108). The variable indicating "no alarm" can be toggled off, while the variable indicating "no critical alarm" can remain in that state. For Syslog messages characterized by severity 2, a fixed yellow light can be activated. A yellow alarm banner may also be presented in the GUI of the SAE (108). The variable indicating "no alarm" can be toggled off, while the variable indicating "no critical alarm" can remain in that state.

[0029] Moving on to a more detailed description of the characterization-based presentation and control action below, FIG. 3 is a flowchart illustrating a process (300) for performing presentation and control actions based on security event classification according to one embodiment. As mentioned above, a security event (e.g., a Syslog message) is received (block 302). A characterization of the security event is identified (block 304). For example, the characterization performed in the process (200) can be stored in a database (114) and acquired to identify the characterization of the security event.

[0030] Display and / or control actions for security events may be determined based on characterization (Block 306). For example, stack lighting / light-emitting diode (LED) and / or audio operation may be determined based on characterization as follows.

[0031]

[0032] The diagnostic matrix below provides another indication of the operations shown in the table above, and also represents the IO key settings for the execute / bypass key switch, which will be described in more detail below. It should also be noted that multiple security events with multiple characteristics may exist simultaneously. Therefore, multiple of these operations may be presented in combination with one another.

[0033]

[0034] A. "Executioner / Bypass Key Switch

[0035] B. Execute / Bypass key switch that is "Bypass"

[0036] C. High / Critical Alarm

[0037] D. Intermediate Alarm

[0038] E. Low alarm

[0039] F. Watchdog Error

[0040] G. Press the test lamp push button

[0041] In the table above, 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) status (summarized as key items A through G below the table). "X" indicates which of the DRSS (100) statuses triggers the specified LED and alarm outputs of the DRSS (100). In some embodiments, this table of LED and alarm outputs and the corresponding DRSS (100) statuses is an indication of the logic implemented in the circuit and / or the machine-readable instructions implemented by the DRSS (100).

[0042] When determining appropriate display and / or control actions, such display and / or control actions are implemented by the DRSS (100) (block 308). For example, as described in more detail below, stack lights can be wired to the DRSS through terminal blocks on the rear of the unit. LEDs can be wired together to the stack lights to display a common display.

[0043] FIG. 4 is a schematic diagram of a Security Appliance Extension (SAE) panel (400) equipped with a stack light (402) according to one embodiment. The SAE panel (400) notifies the operator of system alarms received from an external source (e.g., a Syslog server) and, optionally, interfaces with an external system to provide external control to the protected component (104). When an implemented alarm action is identified, the DRSS (100) will activate the necessary LED (404) and stack light (402) modules. Additionally, the alarm indication may be presented on a display (406), which displays the SAE (108) / DRSS (100) application and provides an alarm banner indicating security events and related characteristics to a graphical user interface (GUI). The display (406) may be a touch screen that allows the operator to clear security events and perform other control actions, as described in more detail below.

[0044] The SAE panel (400) may include a key switch (403). The bypass key switch (403A) is an execute / bypass key switch, which sets the SAE (108) to either execute mode or bypass mode depending on which of the two positions the switch is enabled to. In bypass mode, the control interface output ignores the current alarm and remains ON. The DRSS (100) application continues to display and log the alarm. In execute mode, the control interface output is activated based on received security events as described herein.

[0045] Additionally, a reset switch (403B) may be provided. As discussed above, the reset switch (403B) may be a key switch that is kept on for a certain period (e.g., at least 10 seconds) to turn off the power of the embedded computer (106). When the hold on to the "reset" key is released, the embedded computer (106) restarts.

[0046] To describe the LED (404) in more detail, LED (404A) is an error LED that indicates a critical security event characterization when in the first state (e.g., blinking) and a moderate security event characterization when in the second state (e.g., fixed). 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 execute / bypass key is in the "execute" position rather than the "bypass position." LED (404D) is an IO connection LED that indicates that the PLC (116) is connected and executing IO logic.

[0047] Now, moving on to the external interface of the SAE (108), FIG. 5 is a schematic diagram of the back of the SAE panel (400) according to one embodiment. As illustrated, the SAE panel (400) includes a cooling fan (502) that provides airflow to the SAE panel (400).

[0048] The SAE panel (400) includes a first communication port (504), wherein an RJ45 Ethernet port, used to enable the embedded computer (106) to communicate with a Syslog server (e.g., the security appliance (102) of FIG. 1). As previously mentioned, the Syslog server provides Syslog messages, which ultimately become characterized security events that trigger presentation and / or control actions as described herein.

[0049] The SAE panel (400) also includes a second communication port (506), wherein an RJ45 Ethernet port, is used to enable communication between the embedded computer (106) and the domain controller (112) of FIG. 1. As previously mentioned, the domain controller (112) facilitates user authentication and can enable protected control functions as described in more detail below.

[0050] The SAE panel (400) also includes a stack light / test lamp push button interface (508). The stack light / test lamp push button interface (508) is a terminal for connecting the alarm indicator stack light (402) of FIG. 4 and a test lamp push button that can be pressed when performing a diagnostic light-up test of the stack light (402). The diagnostic test momentarily activates all lights and sounds of the stack light (402).

[0051] The SAE panel (400) also includes a control interface (510). The control interface (510) connects the SAE panel (400) to an external interface and includes triggers for possible presentation and / or control actions. The PLC (116) may provide a specified output through the control interface (510) to establish continuity between the common terminal on the control interface terminal block and the output. When a specified condition is satisfied, the PLC (116) changes the output state to break the continuity. The remote interface outputs supported by the control interface (510) include: No Alarm (maintained ON but turned OFF if an alarm is present); and No Critical Alarm (an output pair that remains ON but turns OFF only when a critical alarm is present). As mentioned above, these state changes are activated when the execute / bypass key switch (403A) is switched to "execute". However, when the execute / bypass key switch (403A) is switched to "bypass", the No Alarm and No Critical Alarm outputs remain ON regardless of whether an alarm is present.

[0052] In some embodiments, the control interface (510) may cause a change in the operation of the protected component. For example, the control interface (510) may access the amusement park attraction and control the operation of the amusement park attraction based on a characterized security event / generated alert. For example, if there is a critical severity security event, the amusement park attraction (e.g., a ride) may be shut down and / or other mitigation measures may be taken.

[0053] In some embodiments, the SAE panel (500) may include redundant power supplies (512A, 512B). By having dual power supplies, if power to one of the power supplies (512A or 512B) is interrupted, power can be maintained by the alternate power supply (512A or 512B). As described in more detail below, during such an event, a local alarm may be provided indicating which of the power supplies (512A or 512B) has failed.

[0054] Moving on to a more detailed description of the DRSS (100) / SAE (108) application GUI below, FIG. 6 is a schematic diagram of a graphical user interface (GUI) start screen (600) representing security event data capture by DRSS according to one embodiment. As previously described, the DRSS (100) application listens for incoming security events (e.g., Syslog messages) and serves to notify the operator of these messages through stack lights, LEDs, and alarm banners. The application can record an alarm history including the time received, the time the alarm was cleared, and the user who cleared the alarm. As previously described, the application may be secured using domain authentication and may include a basic validation UI that authenticates at the application level without requiring a user transition at the operating system level.

[0055] As illustrated in the start screen (600), when the DRSS (100) application is first started, it executes a start process when it connects to all system interfaces. If an interface fails to communicate, a message explaining the communication failure is displayed on the start screen (600), and the application will automatically attempt to reconnect after a certain period of time (e.g., 10 seconds). When an initial data set (e.g., data indicating communication with system interfaces and / or event messages) is acquired, a progress bar (602) will indicate that the loading process is 100% complete and the start screen (600) will switch to the main display screen. During the loading process, the operator can log in using a login affordance (604). By logging in, the operator can perform protected actions available only to authenticated users. The login process is described in more detail below.

[0056] FIG. 7 is a schematic diagram of a main display screen (700) of a DRSS (100) application GUI according to one embodiment. The main display screen (700) provides an alarm banner (702) that displays active alarms received by the DRSS (100). The alarm banners are prioritized, and the highest priority alarm is presented first. Additionally, the characterization of security events is provided by distinguishing the banners (702). For example, banner (702A) is a red banner and provides a text indication 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.

[0057] A mute button (704) is provided on the main display screen (700) and, when activated, mutes the current audible alarm for a configurable period (e.g., a default time of 30 seconds). In some embodiments, the mute button (704) does not require user verification when activated. However, as exemplified by the grayed-out full clear button (706) and clear button (708), in some embodiments, these options may be selected only when logging in (e.g., by executing the login process by selecting the login button (604)).

[0058] FIG. 8 is a schematic diagram of a GUI login screen (800) according to one embodiment. Through the login screen (800), the operator can enter login credentials (e.g., user ID (802) and password (804)). In an alternative embodiment, other login credentials, such as biometric recognition, physical keys, etc., may be used to log in to the DRSS (100) application.

[0059] When the operator logs in, the All Clear button (706) and the Clear button (708) are activated. FIG. 9 is a schematic diagram of a GUI main screen (900) that enables special functions after login (e.g., All Clear button (706) and Clear button (708)) according to one embodiment. When the All Clear button (706) is selected, all alarms displayed by the alarm banner (702) are cleared regardless of which row of the alarm banner (702) is selected. When the Clear button (708) is selected, security events associated with the selected alarm banner (702) are cleared. To select the alarm banner (702), the operator may simply tap the alarm banner (702). The selected alarm banner (702) will change its properties (e.g., color) to indicate that the alarm banner (702) has been selected. Additionally, the alarm banner (702) may be deselected by tapping the alarm banner (702) a second time.

[0060] As described, the logout button (902) is also provided after the operator is logged in. When the logout button (902) is selected, the operator will be logged out (and the main screen (700) with the grayed-out option is displayed again).

[0061] In addition to providing alarms generated from the security appliance (102), the DRSS (100) may also generate alarms based on local events. For example, FIG. 10 is a schematic diagram of a GUI (1000) of the DRSS (100) presenting an error according to one 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). To prevent false errors from being presented when a security event is not presented, the DRSS (100) application may receive heartbeat messages from the security sensor (e.g., a Syslog server / security appliance (102)) at fixed intervals. As used herein, a heartbeat message is a periodic anticipatory message that can be used to determine when a message is not being received by the DRSS (100). If no heartbeat message is detected, the application will present a GUI (1000) indicating a heartbeat error. When a heartbeat message is detected, the GUI (1000) disappears, and the application resumes normal operation. In some embodiments, the interval of heartbeat messages and the number of acceptable missed heartbeat messages can be configured before generating an alarm.

[0062] DRSS (100) may include additional local alarms. The following is a list of additional alarms with severity characteristics and descriptions.

[0063]

[0064] As mentioned in this specification, DRSS (100) can be configured in various ways to create a personalized alarm presentation and control experience suitable for a number of applications. In some embodiments, the DRSS (100) 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 a description of each configuration parameter. As can be understood, this is one list of possible configuration parameters and does not limit the scope to these configuration parameters. In fact, in alternative embodiments, fewer or more configuration parameters may be presented as options.

[0065]

[0066] The technology presented and claimed in this specification is referenced to material objects and specific examples of actual characteristics that clearly improve the art, and thus is not abstract, not intangible, and not entirely theoretical. Additionally, if any claim appended to the end of this specification includes one or more elements specified as “… means of [performing] [function]” or “… steps of [performing] [function]”, these elements shall be interpreted in accordance with 35 USC 112(f). However, for any claim including elements specified in any other manner, these elements shall not be interpreted in accordance with 35 USC 112(f).

[0067] [Example Implementation]

[0068] (Implementation Example 1)

[0069] As an electronic device, the embedded computer comprises one or more processors, wherein the one or more processors receive one or more security event messages from a security appliance—each of which represents a security event related to a protected component—identify a customized severity characterization of the one or more security event messages based on one or more characteristics of the one or more security event messages—wherein the customized severity characterization is not defined by the security appliance—determine one or more presentation or control actions to be performed based on the customized severity characterization, and are configured to perform the one or more presentation or control actions.

[0070] (Example 2 of implementation)

[0071] In Example 1 of the embodiment, the customized severity characterization is determined by executing a mapping script that maps one or more characteristics of one or more security event messages received by the security appliance to a specific customized severity characterization expected by the embedded computer.

[0072] (Example 3 of implementation)

[0073] In Embodiment 2, one or more characteristics of the one or more security event messages received by the security appliance include a first severity level, and the specific customized severity characterization expected by the embedded computer is a second severity level.

[0074] (Example 4 of implementation)

[0075] In Example 2, the one or more processors of the embedded computer are configured to execute the mapping script.

[0076] (Example 5 of implementation)

[0077] In Embodiment 2, the customized severity characterization is received from the security appliance.

[0078] (Example 6 of implementation)

[0079] In Embodiment 1, the display further comprises, wherein the one or more presentation or control actions include at least one of: presenting one or more alarm banners associated with the one or more security event messages through a graphical user interface (GUI) on the display—the one or more alarm banners are displayed based on the customized severity characterization—and presenting one or more visual alarm indicators associated with the one or more security event messages through stack lighting—the one or more visual alarm indicators are based on the customized severity characterization.

[0080] (Example 7 of implementation)

[0081] In Embodiment 1, the one or more presentation or control actions include modifying the operating state of the protected component.

[0082] (Example 8)

[0083] In Embodiment 7, the protected component includes an amusement park attraction.

[0084] (Example 9)

[0085] In Implementation Example 1, the one or more security event messages include messages generated according to the Syslog standard for message logging.

[0086] (Example 10 of implementation)

[0087] In Embodiment 1, the electronic device further comprises one or more input / output (I / O) devices configured to perform at least one of receiving one or more I / O commands from an operator of the electronic device and providing one or more output displays to the operator, and a programmable logic controller (PLC), wherein the PLC is configured to perform at least one of receiving I / O data representing the one or more I / O commands and implementing the one or more I / O commands, and receiving the one or more output displays and presenting the one or more output displays through the one or more I / O devices.

[0088] (Example 11 of implementation)

[0089] In embodiment 10, 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 fault light-emitting diode (LED) that indicates a critical severity security event when in a first state and an intermediate severity security event when in a second state, and the set of one or more lights comprises a health light-emitting diode (LED) that indicates whether all expected interfaces are communicably connected to the electronic device.

[0090] (Example 12)

[0091] In Embodiment 10, the embedded computer is configured to determine a point in time at which a continuously changing state of a variable of the PLC is not detected within a critical time at the embedded computer, and to provide an error in response to the failure to detect the continuously changing state of the variable within the critical time - the error indicates a failure of the embedded computer -.

[0092] (Example 13)

[0093] In Embodiment 10, the one or more I / O devices include a run / bypass switch, and the run / bypass switch, when in run mode, causes logging and presentation of one or more alarm banners associated with one or more security event messages and when the one or more security event messages are received, causes presentation of one or more alarms associated with one or more security event messages, and when in bypass mode, causes logging and presentation of one or more alarm banners associated with one or more security event messages and when the one or more security event messages are received, suppresses presentation of one or more alarms associated with one or more security event messages.

[0094] (Example 14)

[0095] In embodiment 10, the one or more I / O devices include a reset switch that causes the embedded computer to turn off power and reboot when set to a reset mode.

[0096] (Example 15)

[0097] A non-transient computer-readable medium of a type comprising computer-readable instructions, wherein, when executed by one or more processors of a computer, the computer causes the computer to receive one or more security event messages from a security appliance—each of which represents a security event related to a protected component—identify a customized severity characterization of the one or more security event messages based on one or more characteristics of the one or more security event messages—wherein the customized severity characterization is not defined by the security appliance—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.

[0098] (Example 16)

[0099] In embodiment 15, when the computer-readable instruction is executed by the one or more processors, the computer also identifies 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 specific customized severity characterization expected by the computer.

[0100] (Example 17)

[0101] In embodiment 15, when the computer-readable instruction is executed by the one or more processors, the computer also causes the computer to present, in the computer’s graphical user interface (GUI), one or more alarm 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.

[0102] (Example 18)

[0103] In Embodiment 15, when the computer-readable instruction is executed by one or more processors, the computer also determines a point in time when a continuously changing state of a variable of a programmable logic controller (PLC) is not detected within a critical time in the computer, and provides an error in response to the failure to detect the continuously changing state of the variable within the critical time—the error indicates a failure of the computer.

[0104] (Example 19)

[0105] A computer-implemented method comprises the steps of: receiving one or more security event messages from a security appliance through a computer, wherein each of the one or more security event messages represents a security event associated with a protected component; identifying a customized severity characterization of the one or more security event messages through the computer based on one or more characteristics of the one or more security event messages, wherein the customized severity characterization is not defined by the security appliance; determining one or more presentation or control actions to be performed based on the identified customized severity characterization; and performing the one or more presentation or control actions.

[0106] (Example 20 of the implementation)

[0107] In Embodiment 19, at least one of the steps of presenting one or more alarm banners associated with one or more security event messages through a graphical user interface (GUI) — said one or more alarm banners are displayed based on the customized severity characterization — and presenting one or more visual alarm indicators associated with one or more security event messages through stack lighting — said one or more visual alarm indicators are based on the customized severity characterization — is further included.

Claims

Claim 1 An electronic device comprising an embedded computer including one or more processors, wherein the one or more processors receive one or more security event messages from a security appliance—each of which represents a security event associated with a protected component—identify a customized severity characterization of the one or more security event messages based on one or more characteristics of the one or more security event messages—wherein the customized severity characterization is not defined by the security appliance—determine one or more presentation or control actions to be performed based on the customized severity characterization, and are configured to perform the one or more presentation or control actions. Claim 2 An 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 one or more security event messages received by the security appliance to a specific customized severity characterization expected by the embedded computer. Claim 3 An electronic device according to claim 2, wherein one or more characteristics of the one or more security event messages received by the security appliance include a first severity level, and the specific customized severity characterization expected by the embedded computer is a second severity level. Claim 4 In claim 2, the one or more processors of the embedded computer are an electronic device configured to execute the mapping script. Claim 5 In claim 2, the customized severity characterization is an electronic device received from the security appliance. Claim 6 An electronic device according to claim 1, further comprising a display, wherein the one or more presentation or control actions include at least one of: presenting one or more alarm banners associated with the one or more security event messages via a graphical user interface (GUI) on the display—the one or more alarm banners being displayed based on the customized severity characterization—and presenting one or more visual alarm indications associated with the one or more security event messages via stack lighting—the one or more visual alarm indications being based on the customized severity characterization. Claim 7 An electronic device according to claim 1, wherein one or more presentation or control actions include modifying the operating state of the protected component. Claim 8 In claim 7, the protected component is an electronic device including an amusement park attraction. Claim 9 An electronic device according to claim 1, wherein the one or more security event messages include messages generated according to the Syslog standard for message logging. Claim 10 The electronic device according to claim 1 further comprises one or more input / output (I / O) devices configured to perform at least one of receiving one or more I / O commands from an operator of the electronic device and providing one or more output displays to the operator, and a programmable logic controller (PLC), wherein the PLC is configured to perform at least one of receiving I / O data representing the one or more I / O commands and implementing the one or more I / O commands, and receiving the one or more output displays and presenting the one or more output displays through the one or more I / O devices. Claim 11 An electronic device according to 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 fault light-emitting diode (LED) that indicates a critical severity security event when in a first state and an intermediate severity security event when in a second state, and wherein the set of one or more lights comprises a health light-emitting diode (LED) that indicates whether all expected interfaces are communicably connected to the electronic device. Claim 12 In claim 10, the embedded computer is configured to determine a point in time at which a continuously changing state of a variable of the PLC is not detected within a critical time at the embedded computer, and to provide an error in response to failure to detect the continuously changing state of the variable within the critical time—the error indicates a failure of the embedded computer—an electronic device. Claim 13 An electronic device according to claim 10, wherein the one or more I / O devices include a run / bypass switch, and the run / bypass switch, when in run mode, causes the logging and presentation of one or more alarm banners associated with the one or more security event messages and when the one or more security event messages are received, causes the presentation of one or more alarms associated with the one or more security event messages and when in bypass mode, causes the logging and presentation of one or more alarm banners associated with the one or more security event messages and when the one or more security event messages are received, suppresses the presentation of one or more alarms associated with the one or more security event messages. Claim 14 In claim 10, the electronic device comprising one or more I / O devices including a reset switch that causes the embedded computer to turn off power and reboot when set to a reset mode. Claim 15 A computer-readable medium of a type comprising computer-readable instructions, wherein the computer-readable instructions, when executed by one or more processors of a computer, cause the computer to receive one or more security event messages from a security appliance—each of which the one or more security event messages represents a security event associated with a protected component—identify a customized severity characterization of the one or more security event messages based on one or more characteristics of the one or more security event messages—wherein the customized severity characterization is not defined by the security appliance—determine one or more presentation or control actions to be performed based on the customized severity characterization, and cause the computer to perform the one or more presentation or control actions. Claim 16 A computer-readable medium according to claim 15, wherein the computer-readable instruction, when executed by the one or more processors, enables the computer to also identify 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 specific customized severity characterization expected by the computer. Claim 17 In claim 15, the computer-readable medium, when the computer-readable instruction is executed by the one or more processors, causes the computer to also present, in the computer’s graphical user interface (GUI), one or more alarm 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. Claim 18 In claim 15, the computer-readable instruction, when executed by one or more processors, causes the computer to also determine a point in time when a continuously changing state of a variable of a programmable logic controller (PLC) is not detected within a critical time in the computer, and to provide an error in response to the failure to detect the continuously changing state of the variable within the critical time—the error indicates a failure of the computer—computer-readable medium. Claim 19 A computer-implemented method comprising: receiving one or more security event messages from a security appliance through a computer, wherein each of the one or more security event messages represents a security event associated with a protected component; identifying a customized severity characterization of the one or more security event messages through the computer based on one or more characteristics of the one or more security event messages, wherein the customized severity characterization is not defined by the security appliance; determining one or more presentation or control actions to be performed based on the identified customized severity characterization; and performing the one or more presentation or control actions. Claim 20 A computer-implemented method according to claim 19, further comprising at least one of the steps of: presenting one or more alarm banners associated with one or more security event messages through a graphical user interface (GUI) — said one or more alarm banners are displayed based on said customized severity characterization — and presenting one or more visual alarm indicators associated with one or more security event messages through stack lighting — said one or more visual alarm indicators are based on said customized severity characterization.

Images