U.S. patent application number 15/611840 was filed with the patent office on 2017-09-21 for cyber security for physical systems.
This patent application is currently assigned to MISSION SECURE, INC.. The applicant listed for this patent is MISSION SECURE, INC.. Invention is credited to Frantisek Brabec, David R.M. Drescher, Rick A. Jones, DANIEL D. PARK, Edward P. Pernotto, Edward C. Suhler.
Application Number | 20170270295 15/611840 |
Document ID | / |
Family ID | 59152410 |
Filed Date | 2017-09-21 |
United States Patent
Application |
20170270295 |
Kind Code |
A1 |
PARK; DANIEL D. ; et
al. |
September 21, 2017 |
CYBER SECURITY FOR PHYSICAL SYSTEMS
Abstract
A cyber security system and method that includes one or more
devices configured to determine a cyber security threat or breach
event based on analysis of operational information of a protected
system.
Inventors: |
PARK; DANIEL D.;
(CHARLOTTESVILLE, VA) ; Brabec; Frantisek;
(Annapolis, MD) ; Jones; Rick A.;
(Charlottesville, VA) ; Suhler; Edward C.;
(Earlysville, VA) ; Drescher; David R.M.;
(Charlottesville, VA) ; Pernotto; Edward P.;
(Arlington, VA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MISSION SECURE, INC. |
Charlottesville |
VA |
US |
|
|
Assignee: |
MISSION SECURE, INC.
Charlottesville
VA
|
Family ID: |
59152410 |
Appl. No.: |
15/611840 |
Filed: |
June 2, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14742581 |
Jun 17, 2015 |
9697355 |
|
|
15611840 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 21/554 20130101;
G06F 21/552 20130101; G06F 2221/034 20130101 |
International
Class: |
G06F 21/55 20060101
G06F021/55 |
Claims
1. A cyber security system comprising: at least one local security
device configured to monitor operational information of an
associated protected system, wherein said at least one local
security device is configured to determine an occurrence of a
security condition present at one or more of said protected systems
based on analysis of said at monitored operational information,
wherein said at least one local security device is configured to
output an indication of said security condition via a user
interface, and to calculate and indicate one or more response
options via said user interface, and wherein said at least one
local security device is configured to issue device commands to
said associated protected system to restore a desired operating
state of said protected system.
2. The cyber security system of claim 1, further comprising: at
least one control device operatively coupled with one of more of
said plurality of local security devices via a network, and
configured to receive said monitored operational information from
each of said at least one local security device,
3. The cyber security system of claim 2, further comprising at
least one global device operatively coupled with a plurality of
said control devices.
4. The cyber security system of claim 2, wherein each said at least
one local security device and each said at least one control device
are configured to communicate securely using encryption, wherein
each said at least one local security device is configured to auto
register with at least one of said control devices, and wherein
said at least one control device is configured to authenticate said
local security device.
5. The cyber security system of claim 2, wherein said at least one
control device is further configured to output one or more commands
associated with one of more said response options to one or more
said local security devices.
6. The cyber security system of claim 5, wherein at least one said
local security device is co-located with its associated protected
system.
7. The cyber security system of claim 2, wherein said user
interface includes a console configuration tool.
8. The cyber security system of claim 2, wherein said at least one
control device is configured to determine said security condition
using said monitored operational information and external data.
9. The cyber security system of claim 8, wherein said operational
information is received from two or more of said local security
devices.
10. A cyber security system comprising: at least one control device
configured to monitor operational information of an associated
protected system, wherein said at least one control device is
configured to determine an occurrence of a security condition
present at one or more of said protected systems based on analysis
of said at monitored operational information, wherein said at least
one control device is configured to issue device commands to said
associated protected system to restore a desired operating state of
said protected system, and wherein said at least one control device
is configured to output an indication of said security condition
via a user interface, and to calculate and indicate one or more
response options via said user interface.
11. The cyber security system of claim 10, further comprising: at
least one local security device operatively coupled with one of
more of said at least one control device via a network, wherein
said at least one control device is configured to transmit said
monitored operational information to said at least one local
security device.
12. The cyber security system of claim 11, further comprising at
least one global device operatively coupled with a plurality of
said control devices.
13. The cyber security system of claim 11, wherein each said at
least one local security device and each said at least one control
device are configured to communicate securely using encryption,
wherein each said at least one local security device is configured
to auto register with at least one of said control devices via, and
wherein said at least one control device is configured to
authenticate said local security device.
14. The cyber security system of claim 11, wherein said at least
one control device is further configured to output one or more
commands associated with one of more said response options to one
or more said local security devices, and wherein, upon receiving
said one or more commands, said local security device is configured
to issue device commands to said associated protected system to
restore a desired operating state of said protected system.
15. The cyber security system of claim 14, wherein at least one
said local security device is co-located with its associated
protected system.
16. The cyber security system of claim 11, wherein said user
interface includes a console configuration tool.
17. The cyber security system of claim 10, wherein said at least
one control device is configured to determine said security
condition using said monitored operational information and external
data.
18. The cyber security system of claim 17, wherein said operational
information is received from two or more of said local security
devices.
19. A cyber security method comprising: monitoring a protected
system by identifying data to be collected and assessing relevant
operational information or measurements of said protected system;
detecting a potential cyber attack by performing security analysis
to determine a cyber security threat or breach event comprising an
unwanted condition or state of said protected system based on said
monitored operational information or measurements; informing by
outputting electronic information associated with said cyber
security threat or breach event; and correcting said cyber security
threat or breach event by outputting one or more commands to said
protected system suitable to cause said protected system to cease
operating in said unwanted condition or state.
20. The cyber security method of claim 19, further comprising:
storing information related to said cyber security threat or breach
event for forensic analysis.
21. The cyber security method of claim 19, wherein the detecting
comprises determining said a cyber security threat or breach event
by comparing said monitored operational information or measurements
to known system behaviors.
22. The cyber security method of claim 19, wherein the detecting
comprises determining said a cyber security threat or breach event
using verifiable voting among a plurality of results of said
security analysis.
23. The cyber security method of claim 19, wherein the detecting
comprises determining said a cyber security threat or breach event
by performing security analysis of security design patterns
detected among multiple said local security devices.
24. The cyber security method of claim 19, wherein said method is
performed by at least one local security device.
25. The cyber security method of claim 19, wherein said method is
performed by at least one control device.
26. The cyber security method of claim 19, wherein the informing
comprises outputting human and system actions to be taken in
response to the cyber security threat or breach event.
27. The cyber security method of claim 19, wherein one or more of
the monitoring, detecting, informing, and correcting is performed
in real-time.
28. A non-transitory computer readable medium having stored thereon
software instructions that, when executed by a processor, cause the
processor to perform cyber security operations comprising:
monitoring a protected system, using at least one local security
device, by identifying data to be collected and assessing relevant
operational information or measurements of said protected system;
detecting a potential cyber attack by performing security analysis
to determine a cyber security threat or breach event comprising an
unwanted condition or state of said protected system based on said
monitored operational information or measurements; informing, by a
control device operably coupled to said at least one local security
device, by outputting electronic information associated with said
cyber security threat or breach event; and correcting said cyber
security threat or breach event by transmitting, by said control
device, an electronic message to said at least one local security
device to cause said at least one local security device to output
one or more commands to said protected system suitable to cause
said protected system to cease operating in said unwanted condition
or state.
29. The non-transitory computer readable medium of claim 28,
further comprising: storing information related to said cyber
security threat or breach event for forensic analysis.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a Continuation application of U.S.
application Ser. No. 14/742,581, filed Jun. 17, 2015, the contents
all of which are incorporated herein by reference in their
entireties.
FIELD OF THE INVENTION
[0002] Embodiments relate generally to cyber security systems and
methods and, in particular, to systems and methods for detecting
and correcting unwanted operating conditions or modes.
BACKGROUND OF THE INVENTION
[0003] The increasingly ubiquitous use of computers and processors
for controlling equipment and systems has led to new
vulnerabilities and susceptibilities of the controlling and
controlled equipment to be operated in an unwanted manner due to,
for example, hacking and other malicious or unauthorized access for
command and control of the affected systems. There is also an
increasing likelihood of such systems being provided in networked
communications, and the advent of control being provided at ever
more minute levels. Especially important is the ability of the
affected system to continue to operate with minimized disruptions
or effectiveness in the presence of a cyber security threat or
breach of the system.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Embodiments will hereinafter be described in detail below
with reference to the accompanying drawings, wherein like reference
numerals represent like elements.
[0005] FIG. 1 illustrates a cyber security system in accordance
with various embodiments;
[0006] FIG. 2 is a flowchart of a cyber security method in
accordance with various embodiments:
[0007] FIG. 3 is a functional block diagram of a local security
device according to various embodiments;
[0008] FIG. 4 is a flowchart of a configuration method according to
various embodiments;
[0009] FIG. 5 is a functional block diagram of a control device
according to various embodiments;
[0010] FIG. 6 is a functional block diagram illustrating multiple
protected systems according to at least one embodiment; and
[0011] FIG. 7 is illustration of a Graphical User Interface (GUI)
according to various embodiments.
DETAILED DESCRIPTION
[0012] Embodiments relate generally to a cyber security system
comprising at least one component, either a first or a second
component, adapted to be coupled to a secured system, and may
further include additional first or second components with the
second component or components operatively coupled to one or more
of the first components configured to monitor, control, and
interact with the one or more first components based on sensed
information received from the one or more first components, and a
third component configured to receive information from and to
monitor at least one of the second components or one or more first
components as well as one or more of the third components to
analyze the sensed information and the security information to
determine global operational awareness. The second component is
further configured to output security information to a user and to
the third component. However, in some embodiments, the first
component can also output security information to a user, and the
third component may also receive information from the first
component.
[0013] In particular, embodiments can comprise a cyber security
system having one or more local security devices each configured to
monitor at least one operational aspect, which may be one or more
items of relevant operational information such as an operating
parameter, of an associated protected system or device, or one or
more control devices each configured to monitor at least one
operational aspect, which may be one or more items of relevant
operational information such as an operating parameter, of an
associated protected system or device, or both, in which case the
at least one control device can be operatively coupled with one or
more of said plurality of local security devices via a network, and
configured to receive operational information (e.g., at least one
monitored parameter) from each of the one or more local security
devices, in which the at least one control device or the at least
one local security device is or are configured to determine
occurrence of a security condition present at one or more of the
protected systems or devices based on analysis of the operational
information, and in which the at least one control device, the at
least one local security device, or both, are configured to output
an indication of the security condition via a user interface, and
to calculate and indicate one or more response options via a user
interface.
[0014] Embodiments can further include at least one global device
operatively coupled with one or more control devices via the
network (which may be a communications service). The local security
device and the control device can be configured to communicate
securely using encryption, and the local security device can be
configured to auto register with at least one control device via
said network, and wherein said at least one control device is
configured to authenticate said local security device.
[0015] The control device can be configured to output one or more
commands associated with one or more response options to one or
more of the local security devices, and upon receiving the one or
more commands, the local security device can be configured to issue
device commands to the associated protected system or device to
restore a desired or normal operating state of the protected system
or device. The control device user interface may include a console
configuration input capability.
[0016] The local security device can be co-located with its
associated protected system or device, and may be embedded therein
or physically attached thereto. The control device can be
configured to determine a security condition using a plurality of
different monitored operational aspects, information, or
parameters, which may be received from one or more of the local
security devices as well as from external sources.
[0017] Various embodiments can comprise a cyber security method
that includes monitoring a protected system, using at least one
local security device, by identifying data to be collected and
assessing relevant operational aspects, operating parameters, or
measurements of the protected system; detecting a potential cyber
attack by performing security analysis to determine a cyber
security threat or breach event comprising an unwanted condition or
state of the protected system based on the monitored operational
aspects or operating parameters or measurements; informing, by at
least one local security device or by a control device operably
coupled to the at least one local security device, by outputting
electronic information associated with the cyber security threat or
breach event; and correcting the cyber security threat or breach
event by transmitting, by the control device, an electronic message
to the at least one local security device to cause the at least one
local security device to output one or more commands to the
protected system suitable to cause the protected system to cease
operating in the unwanted condition or state.
[0018] For example, in at least one embodiment, the detecting can
comprise determining a cyber security threat or breach event by
comparing the monitored parameters or measurements to known good or
expected patterns. Verifiable voting among multiple results of the
security analysis can also be included. The detecting can comprise
determining a cyber security threat or breach event by performing
security analysis of patterns detected among multiple local
security devices.
[0019] In various embodiments, the detecting and/or correcting can
be performed by the local security device, one or more of the local
security devices, independently from the control device, by the
control device, or by a combination thereof.
[0020] Furthermore, the informing can comprise outputting a
checklist of actions to be taken in response to the cyber security
threat or breach event, and/or outputting notification messages to
at least one device other than the at least one local security
device and the control device.
[0021] In at least one embodiment, the detecting, correcting, or
simultaneous detecting and correcting can be performed in
real-time.
[0022] FIG. 1 illustrates a cyber security system 100 according to
various embodiments. Referring now to FIG. 1, the cyber security
system 100 can include one or more local security devices 101 which
may be operably coupled to (or provided in communication with) one
or more protected systems or devices 103 via a network 113. The
local security devices 101 can be operably coupled with one or more
control devices 105 via a network 111. In at least some
embodiments, multiple control devices 105 can be operably coupled
with a global device 107 via a network 109. The networks 109, 111,
and 113 can each be a different network, the same network, or a
combination thereof. Each individual network 109, 111, and 113 can
also be comprised of a different network, the same network, or a
combination thereof.
[0023] Thus, it is evident that embodiments can provide a
hierarchical approach to system security. In at least one
embodiment, there may be multiple levels of infrastructure or
devices arranged to provide progressive levels of system awareness
for the protected system or devices. For example, in at least one
embodiment, three hierarchical levels may be used. However, other
numbers of levels are also possible. For example, at the most
granular level, the local security device 101 can be provided in
association with a particular protected system 103 or multiple such
protected systems 103. The local security device 101 may be
physically attached to the protected system 103 being secured. The
local security device 101 can comprise hardware components
including one or more processors that, when operating under the
control of a sequence of programmed or hardcoded instructions,
cause the local security device 101 to monitor and control
operating parameters of the protected system 103.
[0024] Embodiments can also include a second level device such as a
control device 105 operatively coupled via the network 111 with one
of more of said plurality of local security devices 101. The
control device 105 can be configured to receive at least one
monitored operational aspect, information, or parameter from each
of the one or more local security devices 101, and can also be
configured to determine the occurrence of a security condition
present at one or more of the protected devices 103 based on
analysis of the at least one monitored operational aspect,
information, or parameter. The at least one control device 105, if
present, is configured to output an indication of the security
condition via a user interface to provide operational awareness
about the state of the control device 105 to an operator, as well
as to calculate and indicate one or more response options via the
user interface. The control device 105 can be configured to output
one or more commands associated with one or more response options
to one or more of the local security devices 101, and upon
receiving the one or more commands, the local security device 101
can be configured to issue device commands to its associated
protected system(s) 103 to restore a desired or normal operating
state of the protected system or device. The control device user
interface may include a console configuration input capability. The
local security device 101 and the control device 105 can be
configured to communicate securely via the network 109 using
encryption, and the local security device 101 can be configured to
auto register with at least one control device 105 via said network
111. The control device 105 can be configured to authenticate the
local security device 101 to the cyber security system 100.
[0025] Embodiments can further include a third level device such as
at least one global device 107 operatively coupled with one or more
control devices 105 via the network 109. The global device 107 can
be configured to monitor conditions and/or parameters output by one
more of the control devices 105. The global device 107 can be
configured to monitor and analyze multiple combinations of these
conditions and parameters to provide global operational awareness
of the protected system (or many protected systems) by detecting
and analyzing multiple disparate occurrences of particular
conditions and particular states of various operating parameters to
determine an occurrence of undesired or unwanted operating
conditions of the protected system 103 that would otherwise go
undetected.
[0026] FIG. 2 is a flowchart ofa cyber security method 200 in
accordance with various embodiments. Referring now to FIG. 2, a
cyber security method 200 can provide a decision support
methodology comprising monitoring 210, storing 220, detecting 230,
informing 240, and correcting 250.
[0027] The cyber security method 200 can commence at 210 with
monitoring of a protected system by identifying data to be
collected and assessing the relevant operating parameters or
measurements that can provide useful information to allow the cyber
security system 100 to determine a condition in which the protected
system 103 is being operated in an unwanted or undesired mode or
state, which may be a result, for example, of a security threat or
breach in the security protocols or safeguards in-place to prevent
unauthorized access to and operation of the protected system. This
step can include collecting data from monitored or protected
systems 103 via the local security devices 101 as well as
monitoring the status of one or more local security devices
101.
[0028] The method 200 then continues to a storing step 220 to store
information related to cyber security and related system data in a
form suitable for forensic review or analysis. For example, data
from the affected components of the protected system 103 can be
collected to allow for forensic recoding and analysis of cyber
security and related system data. The particular data or
information that is stored by the system 100 can vary as needed to
meet various needs, which includes accomplishing the monitoring,
detecting, informing, and correction goals, providing a source for
in-depth forensic analysis, and to recreate system events related
to cyber security for the protected system or device 103. In
various embodiments, the user can configure and change the type of
information collected.
[0029] The cyber security method 200 can continue to a detecting
step at 230, which can comprise detecting potential cyber attacks
using algorithms that implement security design patterns needed to
perform security analysis and to assess the function for potential
cyber attacks based on those measurements. The detecting can
include, for example, but is not limited to, comparison to expected
patterns, expected system behaviors, and/or application of security
design patterns, secured or verifiable voting among algorithm
results, and analysis of patterns detected across multiple local
security devices 101. In various embodiments, the detecting 230 can
be performed at the local security device or devices 101, by the
control device 105, or distributed between or among them. Detecting
can also include, without limitation. System Parameter Assurance
(verifying the source and validity of changes to system operating
parameters), Configuration Hopping (i.e., shifting control and/or
data flow among multiple redundant components), Data Consistency
Checking, and Data Consistency Checking using State Estimation (for
example, using mathematical representations of the interactions
among system states over time).
[0030] The cyber security method 200 can continue to an informing
step at 240 and a correcting step at 250. Informing can include
methods to inform both the system 100 and the necessary human
system operators of a potential cyber security threat to a critical
system function or functions of the protected system(s) 103. The
informing can include outputting a visual display and/or alert to a
user or an operator, archiving data for forensic analysis,
providing a checklist to the user of required or possible actions
to be taken in response to a security condition, and sending
notification messages to other devices or nodes. The alerts may be
chosen from a set of predefined messages. In various embodiments,
the informing 240, the correcting 250, or both, can be performed by
the control device 105 or by the local security device 101.
[0031] The correcting step at 250 can include identifying the
response to be taken to correct an operational state or status of
the protected system(s) 103 in response to the security detections.
In various embodiments, the cyber security system 100 executes
system security control actions in either an automated or
interactive way as required by the particular implementation of the
security system.
[0032] With regard to the local security device 101, as discussed
herein the local security device 101 can be deployed at a protected
system 103. The local security device 101 can be physically
attached to or otherwise co-located with the protected system 103.
It can provide the interface between the cyber security system 100
and the protected system 103, and it also provides a secured
technical staging area for protecting critical physical or
information system components that enable security analyses for
System-Aware Cyber Security processes provided by the cyber
security system 100 and the monitor, store, detect, inform, and
correct (MSDIC) cyber security method 200. System-Aware Cyber
Security is a novel approach to securing systems that leverages
in-depth knowledge of the functionality of the protected system.
System-Aware Cyber Security builds upon prior work in the areas of
fault-tolerance, cyber security, and automatic control systems to
provide an additional layer of protection to critical system
functions. System-Aware security uses rapidly deployable, simple,
and low cost security services integrated with the system to
significantly increase the cost and effort required by an adversary
to compromise the system being protected; thereby providing an
asymmetric advantage to the defender. An important part of the
defender's System-Aware costs are the security features utilized to
protect the System-Aware based solution.
[0033] In various embodiments, the local security device 101 can be
configured to work in an independent configuration and in a
dependent configuration. In the independent configuration, the
local security device 101 does not rely on any interaction with
other components of the system 100 such as the control device 105
or the network 111 to protect and output corrective actions to the
protected system 103. In the dependent configuration, the local
security device 101 can be configured as part of a larger network
of one or more additional local security devices 101 which
communicate over the network 111 in order to provide protections to
a larger array of physical and information systems which may
require multiple monitoring points in order for the complete cyber
security process 200 to be accomplished.
[0034] FIG. 3 is a functional block diagram of a local security
device 101 in accordance with various embodiments. Referring now to
FIG. 3, the local security device 101 can comprise an embedded
hardware platform such as a single-board computer 301 that hosts
System-Aware Cyber Security capabilities of the local security
device 101 and the monitor, store, detect, inform, and correct
functions of the cyber security method 200 used to protect critical
system functions. The local security device 101 can further include
sensors 150 suitable to aid in the detection of abnormal system
behavior indicative of a probable cyber security attack, which may
be directly coupled to the SBC 301 via a bus or interrupt line. The
SBC 301 can also be operatively coupled to sensors 150 located
external to the local security device 101 via input/output (I/O)
interfaces 315, each of which can further comprise a driver
configured to communicate with the particular sensor 150 to which
it is connected. The local security device 101 can also be
configured to communicate within and among its individual
components as well as to communicate with other local security
devices 101 and to and from the control device 105. In at least one
embodiment, the local security device 101 can include enhanced
security hardware and software features to protect the local
security device 101 itself from cyber threats. The local security
device 101 can also include communications interfaces 320 for
interfacing the SBC 301 with communications networks such as
network 111 for communicating with one or more control devices 105
or one or more other local security devices 101, as well as the
network 113 for communicating with the protected system 103. The
local security device 101 can also include a secured memory 305 and
a storage device 310 for storing security data patterns, each
coupled to the SBC 301 via a bus interface.
[0035] The local security device 101 can be deployed on a diverse
set of embedded hardware platforms in various embodiments,
including but not limited to, or more commercial-off-the-shelf
(COTS) embedded hardware platforms. In addition, multiple local
security devices 101, each implemented using the same or multiple
different embedded hardware platforms, can be installed on or
associated with a single protected system 103. In such embodiments,
using multiple local security devices 101 can provide enhanced
security for the protected system 103, the local security devices
101 themselves, and the cyber security system 100 can thereby be
made more fault-tolerant and more resilient to cyber security
threats or breach events. For example, in some embodiments the
local security device 101 can comprise a single board computer
(SBC) hardware component such as, but not limited to, a Reduced
Instruction Set Computer (RISC) or an Advanced RISC Machines (ARM)
processor available from Advanced RISC Machines, Ltd. The local
security device can use an SBC such as, for example, a Raspberry
Pi.TM. SBC available from the Raspberry Pi Foundation at
http://www.raspberrypi.org/, a BeagleBone Black ARM-based SBC
available from the BeagleBoard.org Foundation at
http://www.beagleboard.org, a MinnowBoard or MinnowBoard MAX
Intel.RTM. Atom.TM. based processor available from Minnowboard.org
(http://www.minnowboard.org/), the Edison Development Platform
available from Intel Corporation of Santa Clara. Calif.
(http://www.intel.com/content/www/us/en/do-it-yourself/edison.html),
a Hummingboard.TM. SBC available from SolidRun Ltd. Of Migdal
Tefen, Israel, Liva BAT-Mini PC's made by ECS-Elite Group of
Taipei, Taiwan, or another embedded hardware platform.
[0036] Each of the above-described embedded hardware platforms
support various operating systems and development environments such
as, but not limited to, operating systems such as Linux, including
Debian-based. Arch-LINUX-based, Raspbian, or Open Berkeley Software
Distribution (BSD) versions, or Microsoft@Windows.RTM. 8.1 (or
Microsoft.RTM. 10.0 for Raspberry Pi) (for example, for Minnowboard
Max implementations). In various embodiments, software or
programmed instructions executed by the SBC or embedded hardware
platform of the local security device 101 to configure the local
security device 101 to perform functions as described herein can be
written in the C or Python programming languages, for example, or
the like, without limitation. Security data patterns (for use in
comparison to received or monitored data) can also be provided
using these development environments. For example, the operation of
a turbine involves the transfer and display of data to allow an
operator to monitor the output. A main control room may exist where
an operator views the current state of a turbine, information is
sent from sensors so that the operator can track the turbine's
movement and other variables (speed, temperature, etc.). Operators
observe the output to determine if any variables exceed a given
threshold, at which time they are expected to take action to stop
the turbine or sound an alarm. However, if a cyber attack corrupts
the outputs of the sensors or the displayed data, an operator could
be made to think that the operation is "as normal"; when in reality
an attack is underway. Thus, various embodiments can utilize
security design patterns to ensure that data displayed to operators
is correct and not a misrepresentation resulting from a cyber
attack. Such a design pattern utilizes diversely derived state
estimations to verify the integrity of the data shown to the
operator. The state of a system can be estimated through use of
different state-related measurements; for example, speed can be
derived from position, temperature is related to speed, and other
general relationships exist between different states of a system.
These relationships between states can be represented in discrete
time mathematical equations that represent the interaction among
states of a system as a function of time. By calculating the system
state using measurements that do not directly provide the outputs
shown to the operator for control purposes, the data integrity can
be checked before being displayed. This potentially can alert an
operator to a hidden attack, or a feigned attack that does not
actually require system shutdown. This solution prevents cyber
attacks from compromising data by using state estimation.
[0037] According to various embodiments, the local security device
101 can be implemented across a diverse set of different SBCs,
operating systems, and programming languages, such as those
described above, without limitation, to prevent circumvention of
the protections provided by the cyber security system 100 to the
protected system(s) 103 and to the cyber security system 100
itself.
[0038] The cyber security system 100 can also employ sensors 150 to
monitor operating conditions and parameters of the protected system
103. In various embodiments, the sensors can be components of the
system 100, or the cyber security system 100 can interface with one
or more existing sensors which may be parts of the protected system
103, or a combination thereof, as shown in FIG. 1. The type,
number, and configuration of sensors 150 may be determined by the
particular operating characteristics and functions of the protected
system 103, the current mission the protected system 103 is
supporting, the operational environment in which the protected
system 103 is operating, the level of security desired by the
protected system 103 owners and operators, and other factors. A
sensor 150 can be a physical device attached to the local security
device 103, or can be implemented in software as a sequence of
programmed instructions which, when executed by the SBC or
processor of the local security device 103, causes the local
security device 103 to perform sensor functions including, but not
limited to, extracting operating condition and parameter
information from the protected system 103. In various embodiments,
the local security device 101 can also include drivers to integrate
third-party hardware or software sensors 150 into the cyber
security system 100.
[0039] The local security device 101 compares data received from
the sensors 150 with expected system states to determine an
independent evaluation of the system state derived from the
independent sensor data and other system-specific data being
monitored by the local security device 101. Differences determined
in system state comparison can indicate detection of a cyber
security event which can trigger the MSDIC cyber security process
(ref. FIG. 2) for taking the detection and informing the
appropriate system components and users and providing fallback
capability to maintain and/or correct system functions, even if in
a slightly degraded state, to ensure mission success of the
protected system 103.
[0040] In some embodiments, as discussed herein, the local security
device 101 can be deployed across a diverse set of embedded
hardware platforms to enhance security and fault tolerance. In
similar fashion, the local security device can include diverse
sensors 150 from diverse supply chains and manufacturers for these
purposes. For example, in some embodiments the local security
device 101 may integrate GPS information from multiple vendors such
as, for example, an Adafruit Ultimate GPS.TM. available from
AdaFruit Industries LLC of New York, N.Y.
(http://www.adafruit.com/product/746), or a Ublox Neo 6-series GPS
module available from u-blox AG of Thalwil, Switzerland
(http://u-blox.com/en/gps-modules/pvt-modules/previous
generations/neo-6-family.html) in order to reduce the risk of a
supply-chain attack by diversifying the manufacturing suppliers.
This greatly increases the complexity for an adversary to attack
the sensor systems, as it would require that multiple component
sources be attacked simultaneously. In addition, some types of
sensors, such as, for example, Inertial Measurement Unit (IMU) and
Inertial Navigation System (INS) sensors which also can be used as
location sensing devices, can be used to validate GPS information
and to provide a fallback source of location in the event all GPS
systems are compromised under an attack such as a GPS spoofing or
jamming attack originating from GPS sources other than the normal
Satellite system.
[0041] In various embodiments, the cyber security system 100 can
include one or more of several types of sensors including, but not
limited to: GPS receiver, temperature and humidity, contact/force
sensors, camera with an image analyzer, microphone, INS/IMU,
tripwire, altimeter, LIDAR or radar based object detection sensors,
vibration, accelerometers, and motion and location sensors. Other
sensor types are also possible. For example, Smart phone
technologies can be used as a source for the local security device
101 for providing the protections described herein, including
sensing applications available on Smart phone devices to use in the
execution of the protections. As an example of a System-Aware
technique using such technologies is the use of speed sensors in an
iPhone.TM. (available from Apple, Inc. of Cupertino, Calif.), or,
alternatively, and Android.TM. phone, to provide expected security
design patterns to address the attacks related to braking and
acceleration against the speed control and automated assistive
technologies in a vehicle. More and more sensors are being added to
relatively inexpensive phones such as GPS, gyroscopes,
accelerometers, cameras, compass, etc., all which represent
information that is independent from the protected system or device
103, but is available for use by the local security device 101. In
addition to using the sensors on the iPhone.TM. to provide
independent data for the local security device 101 logic, in some
embodiment the local security device 101 logic can be implemented
on the Smart phone platform itself, of the Smart phone is an
interface to a series of local security devices 101 that are
monitoring activity in a vehicle and reporting problems to an
application on the phone using, for example, texting or email
alerting.
[0042] The local security device 101 can be configured to
communicate with various system 100 components including the
control device 105, other local security devices 101, and the
protected system(s) 103 via the networks 111 and 113, as shown in
FIG. 1. In various embodiments, one or both of networks 111 and 113
can be secure networks. The networks 111 and 113 may be, in some
embodiments, existing communication networks of the protected
system 103. A variety of wired or wireless communications networks
may be provided, as discussed in further detail below.
[0043] The communication network 111 can be utilized for
distributing initial configuration information from the control
device 105 to one or more of the local security device(s) 101. In
at least one embodiment, the local security device 101 can be
configured to send a configuration information request to the
control device 105 via the network 111. The local security device
101 may be configured to send the configuration request to the
control device 105 upon startup of the local security device 101 as
part of an auto registration procedure, for example. Upon receiving
the configuration request, the control device 105 can retrieve the
initial configuration information particular to the requesting
local security device 101, and transmit or push the requested
initial configuration information to the requesting local security
device 101. In this way, the control device 105 can be configured
to manage the distribution of configuration information to the
local security device(s) 101 in a predetermined or ad hoc
determined manner to best protect the protected system 103. The
local security device 101 may store the initial configuration
information received from the control device 105 using a library
storage capability 310. In at least one embodiment, the control
device 105 can be configured to store and forward the local
security device 101 configurations. However, in other embodiments,
the control device 105 can be configured for active management and
editing, by a human user or otherwise, of the local security device
101 configuration libraries that are stored and distributed by the
control device 105.
[0044] In order to extract information about the state(s) of the
protected system 103, the local security device 101 supports a
library of communication standards used to interface with the
systems 103 and the subsystems monitored and protected using
System-Aware techniques. In particular, the cyber security system
100 can include a secured communication mechanism to enable local
security devices 101 to share information about the systems they
are monitoring and the MSDIC processes and security analyses they
are performing between and among the local security devices 101 and
the control device 105. In various embodiments, the data generated
by the local security devices 101 and the control devices can be
formatted in accordance with data structures that define a unique
layer of security data used to track the cyber health of the
critical functions of protected systems 103 in which System-Aware
technology is in place, and that form the information basis for the
MSDIC process of the cyber security method 200. This security data
may also be used as part of a forensic analysis of any detections
that occur. For example, the following communication protocols may
be provided: serial protocols including RS-232 and RS422, Ethernet,
Wi-Fi/802.11 A, B, G, N; Radio Frequency (RF), Bluetooth.TM., IEEE
Standard 1394 Firewire.TM., Universal Serial Bus (USB), and
cellular data connection (e.g., Long-Term Evolution (LTE)). Other
communications protocols are possible.
[0045] In various embodiments, the local security device 101 and
the control device 105 can be configured to communicate with each
other according to one or more of a variety of communication
strategies such as, without limitation: Push, in which the local
security device 101 periodically, or whenever an event occurs,
initiates communication and pushes data to control device 105;
Pull, in which the control device 105 polls the local security
device 101 for new information (e.g., periodically or when prompted
by the operator); and, Continuous flow/streaming for streaming
video or audio and similar applications. To accommodate these
communication strategies, the local security device 101 can support
multiple protocols including, but not limited to: JavaScript.TM.
Object Notation (JSON), HyperText Transfer Protocol (HTTP) POST
method, Extensible Messaging and Presence Protocol (XMPP), and
Real-Time Transport Protocol (RTP). In various embodiments, the
particular protocols supported can depend on the type of data being
transmitted. In addition, communications between the local security
device 101 and the control device 105 can be encrypted and
authenticated using security certificates.
[0046] In at least one embodiment, the local security device 101 is
the only part of the cyber security system 100 that contains
customer or deployment specific customized applications of the
standardized libraries of System-Aware security design patterns.
Other elements of the cyber security system 100, such as the
control device 105 and the global device 107, can be configured
using Graphical User Interface (GUI)-based configuration modules.
In such embodiments, the control device 105 and global device 107
can include reusable libraries of interface modules, which support
the communication protocols inherent to the protected system 103.
These interface modules perform normalization of the data streams
into a standardized data format that the local security device 101
uses for comparison with various corresponding security design
patterns utilized by the local security device 101 to protect
various protected system 103 functions, as well as analysis and
storing of data in the monitoring and detection processes of the
cyber security method 200 and also the restorative commands that
can be used to correct system states after potential attacks are
detected. Such restorative actions can be either automated or human
driven depending on the needs of the protected system 103 and the
demands of its operators for accomplishing the mission.
[0047] For communicating with the control device 105 and with other
local security devices 101, the local security device 101 can
create and use its own metadata structure to both define the
configurations of the local security device 101 and communicate the
local security device 101 configuration to the control device 105.
Users can either directly configure the local security device 101
using commands and planned GUI interfaces to configure (a) the
interfaces used for monitoring, (b) the detection algorithms used
for security design patterns, (c) the methods that are used to
inform the system and the system operators of potential threats,
and (d) the possible corrective actions which define the response
which should be taken by the local security device 101 in response
to a detected event. Thus, the local security device 101 can be
configured to use metadata structures to define a particular
hardware and software configuration of the local security device
101. This configuration can be generated by the local security
device 101 based on the security design patterns, the sensors, the
interfaces into the protected system 103, and hardware design
defined by the local security device 101. These configurations can
define the local security device's 101 MDIC functions for the cyber
security method 200 and can be published to the control devices 105
on the network 111. A configuration for a local security device 101
may consist of the following data: [0048] IP address or hostname
associated with the device [0049] ID: internal identifier [0050]
Textual (human oriented) description of the device [0051] List of
data streams the device produces [0052] List of corrective actions
the device can trigger on the protected system [0053] List of
parameters available on the device for the purposes of configuring
the behavior of the protection mechanism
[0054] The cyber security system 100 can include a communications
method for interfacing with the data in the system 100 and
protected subsystems, via the network 113, and the sensor data
needed from the MSDIC process of the cyber security method 200.
These interfaces can be unidirectional in the case where data being
collected for monitoring, detection, and alerting are used to
evaluate the system 100 cyber security state and to allow a user to
take corrective actions that are independent of inserting commands
back into the system 100 itself to initiate corrective actions. For
example, the user might shut down the automated controls for an
autonomous system that is deemed to be under attack, and place the
protected system 103 into a manual control mode where the user
gains full access to control the system 103. However, in cases in
which automated and user-controlled actions can be inserted into
the data streams to effect the system operations themselves, a
bi-directional interface is provided for the communications link or
network 113 between the local security device 101 and the protected
system 103 in order to allow for control commands to flow back into
the system 103 to reset or adjust the system state based on
automated or user-initiated corrective actions when an attack is
indicated.
[0055] In various embodiments, the system 100 can be configured to
perform the functions described herein by configuring the local
security device 101 and the control device 105 for performing
functions for different phases of the use-lifecycle of the local
security device 101 and supporting control devices 105. Generally,
the configuration method can include at least a
pre-configuration/installation mode, a discovery mode, and a
runtime mode.
[0056] For example, FIG. 4 is a flowchart of a configuration method
400 according to at least one embodiment. Referring now to FIG. 4,
the configuration method 400 can commence with a
pre-configuration/installation mode which can comprise a process of
determining the Monitor, Store, Detect, Inform, and Correct (MSDIC)
design parameters of the system 100 and method 200 for the
protected system 103, at 405. For example, at 405 the number of
local security devices 101 to be deployed can be determined,
including each local security device's 101 touch point or access
point into the protected system 103, and the location of each local
security device 101 (e.g., local or remote). Furthermore, the
number and type of sensors 150 can be determined, and permission
controls for informing regarding detected events can be specified.
In addition, the robustness of any corrective actions can be
defined, along with a determination for each corrective action as
to whether it is automated or initiated via human interface. Other
characteristics for the initial integration of the cyber security
system 100 with the protected system 103 can be established during
this step, including establishing data interfaces and sensor
interfaces to support the security design patterns chosen for the
protection of the system 103. Algorithms for normalizing sensor
data streams are loaded and the interfaces for corrective actions
can also be defined.
[0057] The configuration method 400 can proceed to 410, at which
the configuration of each local security device 101 can be defined.
For example, the security features of a local security device 101
can be specified including modular redundancy/TMR, diversity in
components and/or processes, and component/process hopping
parameters. The logic implementation of the local security device
101 can be defined, and gold standard security patterns, forensics,
and corrective action information can be stored using the database
310. The method 400 can then proceed to 415, at which the local
security devices 101 are installed.
[0058] The configuration method 400 can proceed to the discovery
mode 420, in which the local security device(s) 101 are
incorporated into the system 100. For example, in at least one
embodiment, the local security device 101 communicates its
configuration to the control device 105 to register (via
auto-registration) with the control device 105 on the network 111.
The discovery mode 420 can further include a publishing mechanism
to share the configuration data from the local security device 101
to the control device 105 or to other local security devices 101.
At the control device, discovery mode 420 can be accomplished using
a bulletin board configuration interface via the Internet or World
Wide Web. Furthermore, access control to each local security device
101 can be defined, and the communications between local security
devices 101 and the control device 105 via the network 111 can be
secured, if necessary.
[0059] The configuration method 400 can proceed to 425, at which
security features of the control device 105 can be configured. For
example, data streams to and from the control device 105 can be
assigned to resources. Such data streams can include a data stream
from the protected system 103, to and from local security devices
101, and to third-party (i.e., not a component of a local security
device 101) sensors 150. Security patterns can be configured for
the various parameters to be monitored, as well as filtering
provisions for the parameters, and defining security patterns that
require multiple local security devices 101. The communications
between control devices 105 (which may be via the network 111) as
well as between control devices 105 and one or more global devices
107 via the network 109 can be secured, if necessary.
[0060] The configuration method 400 can proceed to 430, at which
security alerts are configured. In at least one embodiment, this
can include building/establishing detection rules specifying when,
where, and to whom alerts should be provided.
[0061] The configuration method 400 can proceed to 435, at which
corrective actions are configured including, for example,
specification of which corrective actions are automatic or
operator-initiated, a checklist of suggested next steps to be
accomplished, data to be output to aid in decision-making, and a
list of corrected states available for restoration.
[0062] The configuration method 400 can proceed to 440, at which
local security devices 101 can be deployed at the protected system
103. This can include, for example, provisioning a repository of
security patterns at each of the local security devices 101
associated with the particular conditions which the local security
device 101 is configured to detect. A format for metadata
determined and output by the local security device 101 to the
control device 105 can also be specified.
[0063] The configuration method 400 can then proceed to the runtime
mode in which the cyber security system 100 can execute monitoring
for cyber security events using the secure design patterns by the
local security device(s) 101, the control device(s) 105, and (if
provided) the global device 107. In various embodiments, once the
protections are in place and operational, there are components of
the design patterns which are tunable. The control device 105 can
send JSON messages to the local security device 101 with
configuration information for the algorithms running the
detections. For example, the time or size parameters of a sliding
window and sensitivity settings for an algorithm which takes three
diverse GPS or other location readings over a period of time and
detects anomalous behavior between those readings.
[0064] The local security device 101 can include a database 310
storage device for securely storing sensor data and/or data
received from peer local security devices 101. The stored data can,
in various embodiments, be maintained in an embedded database and
stored on the local security device 101 and security analysis
performed on the stored data can be done on the local security
device 101, or such storage and analysis shared among the network
of local security devices 101 and control devices 105 that provide
mission protections. This will allow the local security device 101
to provide mission and equipment protections for the protected
system 103 that require analyses of historical and current data
and, in the event of an attack, facilitate post-incident forensic
analysis, to enables a single local security device 101 to execute
security actions automatically if needed (i.e., without input from
other system 100 components or the operator).
[0065] The database/library 310 stores both system data that
reflects the state of the protected system 103 and any particular
protected subsystem that is being monitored and protected, as well
as data generated by the local security device 101 that comprises
the security data which flows over the network 111. The control
device 105 also has the ability to collect and to analyze the data
provided by and through the local security device 101. Furthermore,
in various embodiments, the local security device 101 can convert
information about the current state of the protected system 103
and/or sub-system into a format suitable for providing System-Aware
Cyber Security using multiple components of the cyber security
system 100. In addition, limitations on the available
communications bandwidth and speed can arise which requires the
local security device 101 to perform evaluation and analytics to
minimize traffic loads. For example, the local security device 101
may need to aggregate the results from multiple sensors 150 into a
single reading in order to minimize the bandwidth used. To meet
these requirements, the local security device 101 is designed to
support the creation of a library of small (in terms of the overall
size of the code) plugins to convert the information extracted from
the sensors 150 monitoring the protected system 103, perform
required aggregation of data, and convert the potentially
aggregated data into a format consumable by other cyber security
system 100 components and also from new sensors that are directly
connected to the local security device 101. Furthermore,
architecture of the local security device 101 can support the
ability to chain these plugins together to support reusability
across a diverse set of systems and domains.
[0066] In various embodiments, the local security device 101 can
serve as a bridge between the protected system 103 and the control
device 105. For example, the local security device 101 can include
a corrective action manager 350 that supports the ability of other
components of the cyber security system 100 to make changes to the
state of the protected system 103. For example, in the event that a
trojan horse embedded in the protected system 103 is activated and
detected, and the operator wishes to roll back the compromised
system 103 to an earlier non-compromised version, the control
device 105 can be configured to issue such a rollback request to
the local security device 101. Upon receiving the rollback request,
the local security device 101 converts the request into a sequence
of commands suitable for processing by the protected system 103
that will accomplish the rollback to the non-compromised state. As
it is possible that attacks can be embedded into the source code or
the hardware of the protected system 103, the corrective action
manager 350 will, as needed, on a customer and deployment specific
basis include the necessary software and hardware needed to restore
the system 103 to a desired operating state (for example, a state
that allows the system to operate possibly with a reduced set of
functionality, but is still able support the current needs of the
mission given the presence of a cyber-attack). For example, the
local security device 101 can insert commands back into the system
103 to override the effects of injected malware, thus mitigating
the effect until the malware can be removed.
[0067] It is possible that the local security device 101 might
temporarily or permanently lose communication with other cyber
security system 100 components under certain conditions. To address
this situation, the local security device's 101 corrective action
manager 350 can be configured to both detect when communications
with other cyber security system 100 components have been lost and
to take appropriate security actions as needed. Depending on the
characteristics of the protected system 103, the mission objectives
being supported by the system 103, and the system 103 operator's
requirements, the set of security actions may be either a subset of
those used in the control device 105 or a set specifically designed
for the particular case of a cyber-attack that occurs during a loss
of communications.
[0068] In various embodiments, the cyber security system 100 can
support several types of security design patterns for evaluation
and analysis to determine occurrence of a cyber security event. For
example, for generic classes of data such as, but not limited to,
GPS data, waypoint positions, temperature, and speed, the cyber
security system 100 can employ standardized data structures that
are defined within the local security device 101 and control device
105 data architectures which allow the local security device 101,
using the security design patterns, to evaluate and analyze the
components needed for monitoring and detection of particular
functions. To that end, the local security device 101 is configured
to interface with the end-system that is being monitored to
interpret the data stream format from the host protocol (e.g., a
serial protocol used by the protected system 103 for serial data
communication), and the ability to insert commands and command
structures back into the host system in order to enable corrective
actions that are either initiated automatically based on detections
that come from either the local security device 101 or the control
device 105, or that originate from control device 105 corrective
actions taken by an operator in response to being informed of a
security design pattern event detection.
[0069] With regard to data interfacing between the local security
device 101 and the protected system 103, according to various
embodiments the local security device 101 is configured for each of
the systems 103 that the local security device 101 is being used to
monitor and to protect. In order to provide these customizations,
the database/library 310 can include libraries of protocol
processors which convert and normalize the system-specific data
flows used by the local security device 101 for monitoring into a
standardized format suitable for processing by the local security
device 101. In at least one embodiment, the cyber security system
100 can include a tool set which aids in creating bi-directional
interfaces with the protected system 103 for monitoring and
detection, as well as defining the secured communications methods
between the end-node local security device 101 and the control
devices 105. In addition, a base communications protocol for the
normalized/standardized data structures, depending on the need for
receipt validation. Particular communications protocols supported
for monitoring by the cyber security system 100 include: serial
interfaces such as RS-232, RS-422, RS-423, RS-485, Universal Serial
Bus (USB). Universal Asynchronous Receiver/Transmitters (UARTs),
IEEE 1394 FireWire.TM., Ethernet (both TCP/IP and UDP/IP). Wireless
802.11 A, B. G, and N; Fibre Channel. Serial Attached Small
Computer System Interface (SCSI). Serial ATA, SONET and SDH for
high speed telecommunication over optical fibers, T-1, E-1 and
variants thereof for high speed telecommunication over copper
pairs), and MIL-STD-1553A/B, MIL-STD 1760 bus, and Modbus,
PROFIBUS, and CAN Bus.
[0070] In order for the local security device 101 to interface with
the data and controls in the protected system 103, the local
security device 101 can include one or more Application Program
Interfaces (APIs) for communicating with the protected system 103,
including structures needed for monitoring streams of data within
the protected system 103 and extracting the data components needed
to support security design patterns, providing a method for
inserting commands for correction or reconfiguration after
detections, and/or providing a possible method for tapping into
communications methods that tie end-node systems to their central
control systems. If it is necessary to interface with the protected
system 103 in a manner for which no readily-available API is
available, the local security device 101 can include customized,
bi-directional data taps to locate the necessary data and to alter
the incoming data in order to insert the corrective actions into
the data streams and to communicate throughout the protected system
103.
[0071] According to various embodiments, the local security device
101 includes security features to protect the local security device
101 itself from cyber attacks. As an overlay cyber security system
which has access to critical functional system points and system
data for monitoring and for corrective actions, the local security
device 101 may be subject to cyber attacks. To mitigate these
risks, various approaches are used to protect the local security
device's 101 hardware, software, algorithms, and data storage to
make the local security device 101 super-secure in relation to the
protected system(s) 103. For example, the local security device 101
can include security protections such as, but not limited to,
diversity in operating environments, diversity in algorithms,
verifiable voting, digitally-signed certificate authentication, and
secured storage for secure local security device 101 data and
critical system data.
[0072] In particular, diversity in operating environments can be
provided through diversity in the hardware components and operating
systems used to execute local security device 101 functions, in
order to reduce the risk that any one hardware operating platform
could be compromised through a supply-chain attack. In at least one
embodiment, the local security device 101 can be implemented using
at least three different hardware platforms, from three different
manufacturers, and composed from as diverse a set of hardware
components (e.g., processors, memory, and storage) as possible.
Different operating systems can also be used to host local security
device 101 applications to minimize the risks associated with
having only one operating system that, if compromised, could affect
the ability of the local security device 101 to monitor, store,
detect, inform, and provide corrective actions in accordance with
method 200. Furthermore, the cyber security system 100 can include
multiple redundant local security devices 101 each having a
different processing environment, and which are hopped (switched
between or among) so that an adversary would not know which local
security device 101 (or component of a local security device 101)
is in use at a particular point in time. For example, triple
modular redundancy (TMR) techniques can be utilized throughout the
local security device 101 hardware and software environment not
only for hopping, but also to enable verifiable voting techniques
as described herein below.
[0073] Diversity in software and/or algorithms can be provided to
detect cyber threats from the data collected from external sensors
150 and the data stream interfaces provided into the protected
system 103. In various embodiments, the code implementing the
detection algorithms can be designed specifically to be small (for
example, less than 1000 lines of code) to enable the detection
methods to be easily re-written in multiple development
environments and languages/instructions, and to make it possible to
run multiple instances of algorithms that can be hopped in random
fashion by the cyber security system 100 to greatly increase the
difficulty to an adversary of knowing which algorithms are being
used and at what time, thus protecting the monitoring
functions.
[0074] Verifiable voting can be provided at the local security
device 101 to validate and potentially vote out compromised
versions of data and information generated by the local security
device 101 about the protected system 103 state or its cyber
security status from among redundant sources of data. A voting
scheme is typically used to detect and isolate systems that are
producing faulty outputs. Voting can also be utilized to detect
misleading outputs. However, if the misleading information is being
produced as a result of a cyber attack, it is possible that the
attack may have been embedded into the component through the supply
chain or from an insider. As a result, it is possible that the
mechanism used to carry out the voting may be compromised.
Verifiable Voting is utilized to provide voting in a secure manner.
It is based on providing a hierarchy of voters tailored to the
specific needs of the system to ensure that components acting
maliciously are identified, while not significantly impacting
system performance. Each of the voters in the hierarchy is designed
based upon a trade-off analysis regarding ease of verifiability,
i.e. confidence that it has not be compromised, and ability to
perform timely and complex comparisons.
[0075] In various embodiments, the verifiable voting can be
provided at two levels, as a minimum. First, the detection
algorithms themselves are run in at least three different physical
locations, in three different processing environments, and
potentially three different implementations of the algorithm. The
results from each of the three or more processes are then compared
for accuracy against each other (within the noise characteristics
of those algorithms) and any anomalous results are voted out of the
available pool of results. From the remaining known good results,
the local security device 101 randomly selects one and forwards or
passes it to the next process in the system 100. The verifiable
voting methodology can also be applied to all of the output
processes of each hardware and operating system platform to detect
potential compromises that could be happening in a particular
operating environment. Again, each output is compared against the
output from other local security devices 101 (or their components)
and any anomalous behavior indicated by different results is
excluded. As in normal operations, the actual results are chosen
from the remaining uncompromised operating environments--either the
two remaining or all three if all are in agreement. While the
foregoing example uses three processes or components in a TMR
scheme, other numbers of redundant components are also possible for
the verifiable voting feature(s) of the local security device 101.
For example, in various embodiments, TMR can be used throughout the
cyber security system 100 to provide a System-Aware approach to
enhance the resiliency of the protection solution. It can be used
within the local security device 101 in terms of multiple single
board computers/operating systems/languages, but also can be used
in the interface to validate communication of data between
components. TMR can also be applied to the control device and
global device by having the functionality present at multiple sites
on different platforms, and in virtual environments including cloud
architectures (e.g., utilizing multiple operating systems, multiple
versions of the code, and diversity in cloud hypervisors and cloud
infrastructures) so that the control device benefits from TMR.
[0076] In various embodiments, the cyber security system 100 can
also include digitally signed certificates to authenticate the
identity of devices that communicate to and from the local security
device 101. The local security device 101 can use digitally signed
certificates to manage the authentications from one device to
another within the cyber security system 100 including the local
security device 101 and the control device 105. Data that is passed
between devices can also be encrypted as a further measure to
reduce the vulnerability to cyber attacks during the transmission
of data from component to component.
[0077] Furthermore, secured storage for secure local security
device 101 data and critical system data can be provided. In
particular, the local security device 101 can provide the
capability to securely store data collected from the protected
system 103 for monitoring, data generated by the local security
device 101, and mission critical data used by the local security
device 101. Data can be stored either onboard the local security
device 101 hardware platform itself using, for example, the memory
305 or library/database 310, or can be shared with the control
device 105, or a combination of both depending on the needs of the
protections and the system being protected. In various embodiments,
data from the protected system 103 can be passively or actively
monitored by the local security device 101 for different types of
security design patterns used by the local security device 101 to
detect potential cyber threats and provide for the MSDIC process
for a protected system 103 or subsystem as described herein. Data
needed in the monitoring process can be stored for either live use
by the detection algorithms or for possible future forensic
analysis purposes. The amount of detail and length of history that
the system stores can be configurable.
[0078] In addition, data generated by the local security device 101
can include messages about the cyber health of the protected system
103. For example, results of detection algorithms running across
the diverse local security device 101 operating platform can be
used collectively to assess the operation of the protected system
or device 103. In at least one embodiment, the detection algorithms
can be continuously running. In the event of a positive detection
of a cyber security event or breach, the local security device 101
can be configured to generate messages that feed the MSDIC process
of the cyber security method 200. In particular, the local security
device 101 can generate detection indicators which inform either
other system processes within the local security device 101, or
pushes the indication to other locations such as the control device
105 for further processing or analysis and/or further methods for
informing operators may be provided. In certain embodiments, the
local security device 101 can be configured to generate automated
system corrective actions or to receive corrective actions from the
control device 105, which generates a series of steps that attempts
to restore the protected system 103 to an operative state. In
various embodiments, all data involved in this process is
maintained in secured storage across the cyber security system
100.
[0079] The cyber security system 100 can further include mission
critical data among or as part of the security design patterns to
define the mission context to the local security device 101. For
example, such mission critical data may include, for example, known
correct/good (i.e., gold standard) versions of parameters that
guide the operation of the protected system 103. These gold
standard versions of the system parameters can be used for
detections and/or to restore the system state after cyber attacks
are detected. In addition, the algorithms that guide the detections
in the local security device 101 can rely on parameters operative
to adjust the sensitivity of the detections and other controls that
allow for configuration of the operation of the algorithms that may
vary under different applications of the protected system 103. Such
tuning parameters can also be stored in secured areas within the
local security device 101.
[0080] With regard to the control device 105, in various
embodiments, the control device 105 can serve as a control unit
over one or more local security devices 101. To that end, the local
security devices 101 are configured to report their measurements to
the control device 105 which stores the received data, visualizes
it to the operator, and facilitates automated or manual response to
threats and discrepancies detected based on data received from the
local security device 101. The control device 105 may be customized
as applicable to a particular protected system 103. While the
methodology of the cyber security method 200 may be common for all
deployments, the actual measurements, analysis, and actions differ.
Accordingly, the control device 105 includes a library of a wide
variety of predefined components from which the appropriate user
interface and response logic can be easily assembled.
[0081] In various embodiments, the control device 105 can be
implemented as a server system, which can be physically located in
the field, near the protected system 103, at another location
(e.g., a datacenter), or in a cloud architecture and accessed over
the Internet. As shown in FIG. 3, in at least one embodiment, the
control device 105 can include a hardware configuration which is
the same as that of the local security device 101 as shown in FIG.
3 with the addition of certain capabilities such as a Graphical
User Interface (GUI) and additional evaluation and analytics
processing for performing security analysis using data received
from multiple local security devices 101 via the network 111 (ref.
FIG. 1). Thus, the control device 105 can include a database 410,
the Graphical User Interface (GUI) 460, communication methods 420,
evaluation and analytics module 470, and a corrective action
manager 450.
[0082] The database 410 can capture data coming from local security
device 101 in the native JSON format, for example. In at least one
embodiment, the database 410 can include a database engine such as,
for example, the engine provided by MongoDB, which is a NoSQL
product which, natively supports JSON storage, or a similar engine.
The high-performance NoSQL database system can be utilized to allow
the control device 105 to store and analyze large amounts of data
quickly and efficiently. The control device 105 can accept and
store in its database 410 readings received from system sensors
150.
[0083] FIG. 7 illustrates a layout of a GUI 460 in accordance with
various embodiments. Referring now to FIG. 7, the GUI 460 can
include a logo graphic 705 which may be associated with the user or
the protected system or device 103, as well as a number of options
such as, but not limited to, local device menu options 710, audit
log menu options 715, detection log menu options 720, detection
rules menu options 725, situational views menu options 730,
administrative menu options 735, and a status indicator 740. The
various menu options include additional system functionality and
configuration options related to the different system areas. The
GUI 460 can also include various command buttons such as, but not
limited to, a replay history button 750, an edit button 755, and a
delete button 760. The GUI 460 can include a library of visualizers
that facilitate visualization of incoming data for human operators
of the control device 105. The following are examples of data
visualizers which may be provided in various embodiments: a
location visualizer 765 which may provide a graphical plot of a
received data point as a location and plot on a map (e.g., location
of a plane), an operational information parameter visualizer 770
which may provide a graphical display of a chart showing changes
calculated over time for a number of most recent data points (e.g.,
fluctuations of temperature), and a visualizer 775 which outputs a
second item of operational information. In at least one embodiment,
one or more of the visualizers 765 to 775 can also include text
output (e.g., text representation of the data points is displayed
in log-like style).
[0084] As data is being received from the monitored protected
system 103 via the local security device 101, the evaluation and
analytics module 470 evaluates the validity of the received data
and can be configured to trigger various actions in response to the
received data. Various embodiments can include a rule builder used
during the system configuration to define how the data should be
analyzed and also to define which conditions should result in
triggering of particular events. A rule can consist of, for
example: a condition comprising a formula that considers available
data and determines whether a scenario that needs to be acted upon
occurred, and a list of actions (any number of available actions
can be triggered by a rule when its condition is met). When new
data is received by the control device 105, the evaluation and
analytics module 470 can evaluate for all registered conditions. In
at least one embodiment, conditions can be pluggable snippets of
arbitrary Javascript.TM. code instructions embodying calculations
necessary to establish whether a particular condition is met at the
time of its execution. In evaluating a condition, in at least one
embodiment the evaluation and analytics module 470 retrieves
information from a sensor data repository within the database 410
as well as user-provided configuration parameters in order to
produce results. However, other arrangements are possible such as,
for example, retrieving data via drivers or API calls. The control
device 105 database 410 can include a library of predefined
conditions that facilitate basic operations such as comparing the
latest sensor value against a preconfigured threshold. Additional
conditions can be implemented and plugged into the control device
105 libraries of conditions for particular protected systems
103.
[0085] When a rule match occurs, the control device 105 can store
an indication of the detection and relevant data the detection was
based on, in a detection log in the database 410, and corresponding
actions (if any are defined) are output to one or more local
security devices 101 to effect corrective action at the protected
system 103. The corresponding actions may also be indicated to a
human operator at the control device 105 using the GUI. The
evaluation and analytics module 470 can also include search
functions for the detection log to allow operators to review
detection and response history. The detection history can be shared
with other control devices 105 and received from other control
devices 105 via the network 111.
[0086] Thus, the evaluation and analytics module 470 can trigger
certain actions in response to the results of its analysis. The
triggered actions can include raising a warning or alarm at the
operator level (via the GUI 460 or electronic messaging) to
initiating corrective actions on the protected system 103 via
drivers at the local security device 101. The applicability and
availability of corrective actions can be defined based on
characteristics of the protected system 103 and the control device
105 can include the capability to model corrective actions,
including definition of the outputs and indications associated with
each corrective action, using configuration tools. For example, the
control device 105 can provide actions such as, but not limited to,
displaying a message at the control device 105 using the GUI 460,
sending an email message to a set of recipients, triggering a
corrective action automatically via the local security device 101,
displaying instructions (which may also include a suggested course
of action), providing a button via the GUI 460 for the operator to
trigger an action or series of actions on the local security device
101, opening a situational awareness portal via the GUI 460 which,
in at least one embodiment, can comprise a window containing
instructions to an operator for handling scenarios when a given
detection occurs. The instructions can include, for example, items
such as standard operating procedures, a checklist, a link to a
collaboration/incident management suite, or other relevant
resources (e.g., weather data, historical maintenance information,
phone numbers of manufacturers, etc.). The situational awareness
portal window can also be configured to contain selected data
viewers for incoming sensor data such as, for example, charts, maps
(e.g., a dynamic map for tracking reported location(s) over time),
an action panel (e.g., implementing a "Revert to previous waypoint"
button), and/or text logs (e.g., displaying database entries in
textual representation, live automatic updates, search and filter
functions, etc.).
[0087] In some embodiments, the corrective actions that may be
available may depend on the particular capabilities supported by
the protected system 103. Therefore, a list of available corrective
actions can be configured using the control device 103 during
initial system setup of the local security device 101 based on the
specific implementation and its available entry points into the
system. Examples of corrective actions can include: [0088] switch
to a backup system (e.g., instruct the protected system 103 or one
or more components to start using a backup controller); [0089]
change the controlled value (e.g., instruct the protected system
103 to set the thermostat to maintain a different temperature);
[0090] restart the system; [0091] reload and reset the local
security device 101; [0092] reset the input data (e.g., re-upload a
flight path from a secure location); [0093] no change in operation
but logs data and send alert and support information to appropriate
analysts and managers for forensic analysis.
[0094] In various embodiments, when the control device 105 triggers
a corrective action, one or more associated commands are
transmitted to one or more corresponding local security devices 101
which in turn instruct or command the protected system 103, via the
communication interface 320 which may include an adapter or driver,
to direct the protected system 103 to modify its behavior as
determined by the control device 105. In some embodiments, the
local security device 101 can be configured to determine a set of
one or more commands to send to the protected device 103 based on
the command(s) or instructions received from the control device
105.
[0095] The control device 105 also provides management and control
of the local security device 101. In particular, the control device
105 provides run-time modification of various parameters associated
with local security device 101 functionality, either automatically
via commands and instructions to the local security devices 101, or
via commands and instructions sent in response to operator input at
the control device 105 via the GUI 460. These may include, but are
not limited to, user-triggered corrective actions based on data and
events reported by the control device 105.
[0096] The management and control of the local security device 101
includes initial configuration and setup of the local security
devices(s) 101 during initial deployment of the cyber security
system 100. During the initial setup, local security device 101
parameters to be controlled by the operator from the control device
105 GUI 460 are captured and configured using an administrative
module or via call to an API at the local security device 101.
Specifically, for each local security device 101 it is identified
how to communicate with it (which may only require defining the
local security device's 101 IP address, in at least some
embodiments) and the parameters are available to be controlled.
Examples of types of parameters that can be controlled include:
[0097] Enumeration--such parameters can take one of several
predefined values, typically offered for selection in a drop-down
format. An example of such parameter is the type of detection
algorithm to be used, the mode it should run in (e.g., demo vs.
live), etc. [0098] Range--such parameters can take any value within
a specified range. The GUI can be modeled by a simple text box
(associated with proper validation) or by a slider, a knob, etc.
[0099] Text--such parameters can take any content, and validation
via a regular expression can be provided.
[0100] While during run time operation parameters may be dependent
on each other (e.g., the range parameter is only applicable if the
enumeration parameter has a certain value), during configuration
the control device 105 may only display the parameters available
and provides labels using the GUI 460 to guide the user as to which
ones are applicable in which scenarios. Conditional relationships
among the parameters may be defined in subsequent steps.
[0101] During run time, parameters configured during system setup
are available to the control device 105 operator while the cyber
security system 100 is in operation. The operator can modify the
parameters as needed via the control device 105 GUI 460 and push
the changes into the corresponding local security device(s)
101.
[0102] The control device 105 can also allow for user management.
For example, personnel authorized to operate the control device 105
can be represented within the control device 105 through user
accounts. In various embodiments, each such person can be
represented by a single account. Initially, a single administrator
account can be created during initial configuration. Administrative
users can create accounts for other users who will have
more-restricted rights. Alternatively, users can register
themselves using a self-registration flow in which self-registered
users initially have access only to their own account, and can be
subsequently promoted by a control device 105 administrators into
their corresponding roles. Several roles can be defined for users
at the control device 105 each with a corresponding authorization
level such as, for example, but not limited to, Operator,
Administrator, Monitor, and Auditor. Each user account can be
assigned any combination of these roles (including none at all).
For example, operators can have access to features related to
running the cyber security system 100 during run time operation,
such as viewing detection logs and marking their resolution,
triggering corrective actions, and viewing situational views.
Administrators can set up and configure the control device 105
including the authority to create, delete, view, and edit user
accounts (including changes of user roles), configure detection
rules, add/edit/delete and configure individual local security
devices 101, and add/edit/delete/view situational viewers. Auditors
can access and view an audit log in which any changes performed by
users to the control device 105 are recorded. Monitors can view the
overall status of the cyber security system 100 which may be
represented by a red (e.g., problem status) or a green (e.g.,
normal status) icon displayed within a header portion of the GUI
460.
[0103] In various embodiments, the control device 105 can include
an audit log 480 that stores information about changes triggered by
users via the GUI 460. In particular, the audit log 480 can store
the first and last name as well as the email address of the user
who triggered the change, and this information remains captured as
it was in effect at the time of the event. The audit log 480 can
also store information regarding subsequent changes to the account
of the user who triggered the event (and including changes of name
or email or even deletion of the account) but cause no change in
the historical information stored by the audit log 480. Then it
also stores the area or function of the control device 105 where
the change occurred such as, for example, changes to detection
rules, users, local security devices 101, or situation viewers. The
audit log 480 can also capture the type of change (e.g., create,
edit, delete, configure) and a copy of the changed object (e.g.,
the updated user account).
[0104] As discussed previously, the control device 105 receives
measurements and other data about the monitored protected system
103 from local security devices 101 installed within the protected
system 103. However, in some embodiments, the control device 105
can also receive data from other sources. If the protected system
103 has a suitable API for reporting its status, or if another
independent measuring tool is already in place that can be
configured to report its findings to the control device 105, that
the control device 105 can also be configured to utilize this data
as well via the network 111. The local security devices 101 (or
other data sources) push information into the control device 105
using, for example, JSON over HTTP POST protocol. Other protocols
are also possible. An exemplary embodiment of a JSON formatted
message over HTTP POST protocol may contain the following
information.
[0105] URL where the data is submitted to
[0106] ID of the local security device/sensor sending the data
[0107] payload: the specific data being transferred
[0108] The control device 105 parses the payload according to the
configuration of the local security device 101 identified by its
ID. The payload object can be, for example, of these types.
[0109] Single value: a number or a string
[0110] Location: Two numbers representing geographical location
[0111] Feature Collection: A collection of geometric objects
including their
[0112] visualization parameters, typically to be used as an overlay
in a map view
[0113] A JSON over HTTP POST message can also be sent from the
control device 105 to the local security device 101 to trigger
configuration of the local security device 101, as well as to
trigger corrective action at the local security device 101. In at
least one embodiment, a single POST contains configuration of all
required local security device 101 parameters.
[0114] In various embodiments, a single control device 105 can
manage multiple local security devices 101 and thereby multiple
protected systems 103. Control device 105 operator management
maintains enforcement of proper access privileges for individual
operators (e.g., view only, view and trigger actions, etc.).
Furthermore, each operator can have his/her own custom status
awareness view, i.e., their own configuration of windows
representing applicable data visualizers for systems they are
authorized to be viewing. Due to the browser/server architecture,
multiple operators can access the control device 105 at the same
time. Furthermore, the GUI 460 can be designed to facilitate
viewing of control device 105 outputs across mobile devices.
[0115] During system 100 setup, operators are identified and
accounts created. Protected systems 103 are identified and an entry
for each is created. Individual operators are authorized to access
individual systems 103 as appropriate. Each protected system 103
has one or more associated local security devices 101 associated
with it, and the local security devices 101 provide for interfacing
the protected system(s) 103 with the cyber security system 100 to
take independent measurements of the health of the system 103.
These local security devices 101 are also registered with at least
one control device 105. In particular, the data sources are
registered and identified by their assigned IDs, corrective action
facilitators are registered using their IP addresses, and the
corrective action they are capable of executing upon control
device's 105 request. For example, communication between local
security devices 101 and the control device 105 is can be, for
example, authenticated and encrypted JSON over HTTP POST.
[0116] In at least one embodiment, the control device 105 can store
data using the database 410, which may be, for example, a
MongoDB.TM. Database Management System (DBMS). Control device 105
data stored in the database 410 can include the following
collections (additional internal-use fields contained in individual
collections are omitted): users, systems, sensor data, detection
rules, detection log, local security device 101 data, and audit log
collections.
[0117] An exemplary data model for user data is shown below and may
contain:
[0118] A user model contains the following fields:
TABLE-US-00001 First Name: "<first name>", Last Name:
"<last name>", Display Name: "<name used within GUI>",
Email address: "<email address>", User name: "<login
ID>", Password: "<password>", Roles: a set of privileges
that determines access rights of the user within the system
[0119] A data model for systems data collection can represent
situational views, which may be a collection of viewers each
showing one or more incoming streams of data in real-time. A
situational view displays selected measurements and other inputs in
real time in their natural context (e.g., a location is displayed
in the context of a map). Observed together they provide a
comprehensive picture on the status and health of the protected
system. A specific example of a situation view for an aircraft can
includes three sections--a map with the current and recent
locations as reported by the system, current and recent locations
as measured by local security devices; a chart indicating current
and past exhaust gas temperatures as reported by the system and as
measured by local security devices; text status view showing most
recent status updates provided by local security devices in textual
form. Viewers configured within this collection can be also used
within the Detection log's Situational Awareness action type. In at
least one embodiment, each item in the Systems collection contains
an array of view ports where each viewport contains an array of IDs
that identify individual data sources (e.g., as facilitated by
local security devices 101) to be visualized by this view port. The
viewer type field identifies how (i.e., using which GUI module)
this sensor data should be visualized (e.g., chart viewer, map
viewer, . . . ):
[0120] An exemplary data model is shown below. A situational view
may include information such as: [0121] label: "used to identify
this system within GUI" [0122] description: "further info on system
within GUI" [0123] textual (human targeting) description of the
Situational View [0124] list of viewers, each identifying the type
of viewer (map, chart, text, . . . ) and relevant configuration
parameters (e.g., starting location and zoom level for a map view,
minimum and maximum values for a chart view, etc.
[0125] An exemplary data model for sensor data is the same as for
payload data described above, in various embodiments.
[0126] A detection rule can combine a condition to be evaluated
with a list of actions to be taken if the condition is met. The
condition can be selected from a condition library from the
database 410, which inputs and parameters for the detection rule
being selected via GUI 460 when the rule is established. Examples
of detection rules include:
[0127] If a timestamp differs by more than x seconds, but less than
y seconds, trigger an event (E1). (Such a rule could be triggered
to indicate that reporting doesn't work as it should (i.e.,
communication down) but could also indicate a possible attack.)
Else, if the timestamp differs by more than y seconds, trigger
event E2. (This rule could indicate that the communication has been
done for long time.) Else (i.e., timestamp difference is less than
x), if the waypoint_id values are different, trigger an event (E3).
(This rule could indicate that a monitored asset is somewhere else
than intended). The rule evaluator can be set up to trigger several
different events such as, for example, the following: [0128] a.
E1--display a warning in the Console action panel; [0129] b.
E2--display an error message and trigger an alert; [0130] c.
E3--display an error message, trigger an alert and enable an
operator-confirmed "revert to previous waypoint" corrective
action.
[0131] The list of inputs and parameters needed by the condition is
included as part of each entry in the condition library. An
exemplary data model for detection rules is shown below:
TABLE-US-00002 Detection rule name: <rule name>,
ignore_Repeats_for: <in seconds> control ,- makes sure a
persistent condition doesn't trigger the rule more often than
configured last_triggered: <timestamp>, condition - defines
what condition should be tested for in determining whether this
rule is triggered; it includes selection of the evaluation module,
the list of input streams to be provided to this module and the
list of parameters that are configuring behavior of this module: {
evaluatorId: "<evaluator ID from evaluator JS file>", inputs:
{ <stream1>: "<id1>", <stream2>: "<id2>",
... }, parameters: { <param1>: "<value1>", ... } },
actions: a list of actions to be taken when this detection rule is
triggered [ // see Action Types below ] Action Types: Example
actions include: .cndot. Screen Popup - a given message is shown on
the screen { type: "screenpopup", message: "<fixed message>"
} .cndot. E-mail - an email message is sent to the preconfigured
list of recipients { type: "email", addresses: [<email
address>,...] message: "<fixed message>" } .cndot. SMS - a
SMS message is sent to the preconfigured list of recipients { type:
"sms", phones: [< international phone number>...] message:
"<fixed message (160 chars max)>" } .cndot. Situational
Awareness - a situational awareness view as composed specifically
in response to this detection rule { type: "situation", message:
"<HTML description of situation, links, checklists, ...>"
viewers: [ <copies of selected items from systems.viewports>,
... ] .cndot. } .cndot. Automatic Corrective action - triggers a
selected corrective action (via the local security device
associated with this corrective action) { type: "autocorrection",
auto_corrective_action: { hostname: "<copy from
local.hostname>", label: "<combination of local and
corrective action labels>", local_id: "<copy from
locals.local_id>", payload: {<copy of corresponding
locals.corrective_action element>} } }
Manual Corrective action--creates a user interface component that
allows the operator to trigger one of the preselected corrective
actions.
[0132] In various embodiments, the detection log can list all
detections that occurred as well as actions taken. Each entry in
the detection log can include a copy of the associated detection
rule or rules that were activated. The detection log can be
implemented as a capped collection, i.e., oldest entries in excess
of the preset limit are automatically purged from the database 410.
An exemplary data model for detection log will contain information
such as:
TABLE-US-00003 { name: <rule name>, triggered:
<timestamp> condition: <copy of condition>, actions:
<copy of actions field in detection_ rules> } Detection rule
that was triggered Date and time when it was triggered Condition
that triggered the detection rule Actions that were taken in
response
[0133] In various embodiments, the detection log can also be
implemented as a capped collection, i.e., oldest entries in excess
of the preset limit are automatically purged from the database 410.
An exemplary data model for the audit log is: [0134] First and last
names and email address of the operator that triggered the change
[0135] The type of information that was modified (e.g., detection
rules, users, situational awareness, . . . ) [0136] Date and time
of the change [0137] The type of change (e.g., an entry was
created, edited, deleted) [0138] A copy of the object that was
affected by the change
[0139] In at least one embodiment, the control device 105 can also
include custom condition evaluators. For example, each of a number
of custom condition evaluators can be represented by a
Javascript.TM. file located within a folder (e.g., "evaluator"
folder) stored using the database 410. When the control device 105
commences processing, the evaluator files are imported and the code
and configuration implemented therein becomes available to a
runtime engine of the control device 105. The evaluator files can
implement the condition evaluation algorithm as well as define how
the GUI 460 should be built within the condition section of a rule
in order to capture the inputs and parameters needed by the
algorithm. The inputs and parameters captured via the GUI 460 can
be stored in the database 410 within the detection_rule entry. For
example, a custom condition evaluation record can require as inputs
the IDs identifying relevant `sensor data` entries from the
database 410, and may include a number of parameters for the
algorithm such as, for example, over how long time or entries
should the algorithm run the evaluation, what sensitivity to use,
etc.). An exemplary data model for a custom condition evaluator is
shown below: [0140] Evaluator ID [0141] Evaluator name [0142] List
of input streams this evaluator needs to access [0143] List of
parameters that configure behavior of this evaluator [0144] Actual
implementation of the evaluator, i.e., the computer code that will
be executed when this evaluator is triggered
[0145] As described above, the cyber security system 100 can
further include at least one global device 107 operatively coupled
with one or more control devices 105 via the network 109. The
global device 107 can connect multiple protected systems 103 and
aggregate information coming from multiple clusters of systems 103.
As such, the global device 107 can provide global insight into the
health of multiple infrastructure points and automatically analyze
the aggregated data for anomalies and other signs of large-scale
attacks spanning multiple systems 103.
[0146] As shown in FIG. 6, the global device 107 itself can be
deployed in a hierarchical manner. Referring now to FIG. 6, a
corporation or an agency with multiple protected systems 103
spanning multiple locations, for example, can choose to deploy one
global device 107 for each location to provide situational
awareness for multiple protected systems 103 within the location,
and another global device 107 at the headquarters level where
information from all the individual locations is aggregated. In at
least one embodiment, the user corporation or agency can also
choose to communicate with other global devices 107 operated by
other entities, as it is foreseeable that large-scale attacks could
affect multiple targets. In at least one embodiment, the global
device 107 can further complement information provided by the cyber
security system 100 with external information by tracking
third-party data sources (such as RSS, Twitter, etc.).
[0147] In various embodiments, the global device 107 can be
implemented as a server solution that can be deployed both on site
and in a cloud architecture (public or private). The global device
107 can comprise an administration module for managing operator
accounts and authorizations, configuration, logging; a database
which stores all reported data for visualization and reporting; a
data source management module which manages connections to data
sources which includes control devices 105 and other global devices
107, a situational awareness portal, and a rules manager. In
various embodiments, connections to data sources can be initiated
by the data provider and approved by the data consumer (i.e., the
global device 107). In order to support the situational awareness
portal, data available at the source system (e.g., a control device
105) can be pushed to the global device 107. This data can include
data statistics, reports on rule violations, and actions taken, and
can be visualized in a manner customizable to each operator
independently. The rules manager can be used to establish rules set
up to trigger certain actions based on incoming data. For example,
when the global device 107 determines there are more than a certain
number of automatically or manually triggered corrective actions
across all the monitored protected systems 103, the global device
107 can raise and/or output a global alarm.
[0148] Therefore, the cyber security system 100 can be used to
provide System-Aware detection of and correction from cyber attacks
in a variety of environments. For example, the cyber security
system 100 can be used to secure airborne assets and systems by,
for example, providing a local security device 101 for each
airborne component (such as, for example, an aircraft) as well as
for ground-based control and communications elements of an airborne
system. The aircraft and ground station local security devices 101
can communicate with each other using a Radio Frequency (RF)-based
network 113, and can communicate with local components of the
protected system 103 using one or more serial ports. The airborne
local security device 101 can include one or more Embedded Hardware
Processors (EHPs) each attached to a number of sensors 150, such as
a Global Positioning System (GPS) receiver, one or more Inertial
Measurement Units (IMUs), a satellite communications detector, an
Electromagnetic Pulse (EMP) detector, radar data or a microwave
energy detector. In certain embodiments, the local security device
101 on the ground can receive and integrate data from the local
security device(s) 101 of the airborne assets to detect various
cyber threats/attacks. For example, position data from multiple
sources including diverse GPS systems and other position systems
such and IMU/TNS can be used to evaluate the validity of positional
data received via GPS sensor data.
[0149] One or more control devices 105 can also be provided with
which the local security devices 101 can register. The local
security device(s) 101 of the ground station can forward
information it receives from the local security devices 101 of the
airborne asset via a network 111 to the one more control devices
105. The local security devices 101 of the airborne assets can
auto-register and deregister with a particular control device 105
based on latitude and longitude proximity to the control device
105. The control device(s) 105 may be ground-based. The network 111
can be a wired connection such as Ethernet, or it can be a wireless
network. The control device 105 can be configured to detect threats
such as a trusted insider threat, or to detect other subtle attacks
that may be coordinated across multiple airborne assets, by
validating correct operations of the airborne assets (such as, for
example, by comparing the actual location of the airborne asset(s)
with the intended location at a given time. If a discrepancy is
detected, the system is configured to raise an alarm with the
operator and an action is offered in the form of a button that
triggers an event back on the airborne asset of the protected
system 103 to reprogram its destination to the one intended.
[0150] In this example, the cyber security system 100 can include
detection rules for key functions to be monitored, such as the
vehicle flying along the intended waypoint flight plan path. One
method for assessing that the flight plan is followed can involve
several location detectors such as GPS or INS sensors (from
different vendors and, different location services) that report
their respective location measurements to the onboard local
security device(s) 101. The local security device 101 aggregates
these measurements and establishes whether the reported
measurements correct for the most likely current location. The
local security device 101 then compares its current location with
the location expected at that time by the flight plan to determine
whether a discrepancy is occurring.
[0151] Another detection rule can determine whether the aircraft
maintains altitude within a predefined mission bracket. The
altitude can be read from an independent sensor 150, calculated
from the changes in location over time, as well as obtained from
the vehicle's own altimeter. These values are aggregated into the
most likely current altitude and if the vehicle descends prior to
the intended time, an alert is sent to the operations center via
the control device 105.
[0152] In the rules examples above, the monitored values (e.g.,
location with respect to the flight path and the speed) are
evaluated for cyber attacks by the local security device 101
onboard the vehicle. Any associated system data, or detections that
require integration with data from outside the system, are
transmitted to the control device 105 for further evaluation. This
may be provided in the form of alerts to system operators, and may
provide information for possible corrective action taking.
[0153] Furthermore, a global device 107 can be deployed in a cloud
architecture. Each control device 105 can be registered with the
global device 107 and configured to report status and updates to
the global device 107 via the network 109. The global device 107
can be utilized by a using agency's officers at the headquarters,
for example, to monitor health and operation availability of their
airborne fleet by evaluating detections from individual assets and
also gaining by insights from gathering cyber security status
across multiple deployed assets at one time.
[0154] Another exemplary deployment environment for the cyber
security system 100 is for autonomous ground vehicles and for
driver assistive technologies available in consumer vehicles. For
example, in the military autonomous vehicles may be used to
minimize the threat posed to drivers of logistics resupply convoys.
These convoys of such autonomous vehicles may operate in an urban
environment where they are potentially exposed to numerous hazards
including sharp turns around buildings or traffic circles,
obstacles or abandoned vehicles, non-combatant pedestrians, other
road traffic, or enemy direct attacks. Using a variety of sensors,
the autonomous vehicles must sense their position and successfully
navigate to avoid collisions with the vehicles they are following.
Each vehicle must individually avoid hazards such as roadblocks as
well as pedestrians. Therefore, autonomous vehicles are often
equipped with systems that sense and understand the operating
environment such as, for example, Light Detection and Ranging
(LIDAR) remote sensing technology, to assist the vehicle control
system in performing the driving functions of accelerating,
braking, and turning. Furthermore, vehicles may also include
functions such as collision avoidance, adaptive cruise control, and
object detection and avoidance, which functions are increasingly
found in consumer vehicles as well. In such embodiments, the local
security device 101 can perform cyber protections in order to
protect these functions. Other systems may communicate with a
command center to report position, speed, and vehicle and system
health. These systems may also be guided through the use of GPS
guidance systems which are critical to providing pathways for the
ground system to follow and to utilize their payload systems at
certain location-based times in the mission.
[0155] In such embodiments, the system 100 can provide System-Aware
Cyber Security to: (1) monitor selected critical systems for cyber
attacks, (2) store system information for forensics, (3) detect
when an attack was in progress, (4) inform the driver, and (5) take
automated corrective action to protect the driver, passengers and
vehicle against advanced cyber attacks against critical systems
that affect acceleration, braking, and control. For example, one
cyber attack may be designed to cause the vehicle to accelerate,
rather than brake, even though the obstacle avoidance system (using
LIDAR, for example) detects an object in front of the car. Rather
than slowing down, the compromised vehicle hits the object in front
of the object at high speed causing damage to the car and potential
threat to the life and safety of the passengers in the car under
attack and in the car being struck. Another attack scenario causes
an unexplained, rapid, emergency stop (hard braking) rather than
slowed acceleration or gentle braking when the vehicle uses a
feature such as adaptive cruise control or collision mitigation
braking. Still another cyber attack can affect the vehicle's
ability to maintain control of the vehicle when obstacles are
detected by an automated object detection system based on data from
laser sensors: Attacks can be initiated against the object
detection and collision avoidance system of the vehicle in order to
override the automatic braking functions of the vehicle when an
object is detected. In such scenarios, embodiments can monitor the
data received from the vehicle object detection sensors, validate
the associated user activity, evaluate the speed of the vehicle,
determine whether the vehicle was acting logically in response to
the object, alert the driver to a cyber threat, automatically turn
off the automated system, and inform the driver to take control and
brake to avoid a collision.
[0156] In a convoy of this type, there may be a mix of manned and
unmanned vehicles to include armed security, command and control,
and operation of surveillance and other payload components, with
the majority being unmanned logistics vehicles, plus other support
such as maintenance and wreckers for any broken down vehicles. The
vehicles could navigate via different methods to include station
keeping on leading vehicles, GPS with a pre-planned route, or a
combination. Therefore, critical systems to protect are the
navigation method, speed controls, and vehicle health reporting. A
command and control vehicle in the convoy as well as the operating
base may receive reports from the vehicles to be able to
effectively manage the convoy and any potential problems.
[0157] Accordingly, each of the unmanned or remotely piloted
vehicles can be provided with a local security device 101 which
communicate with one or more control devices 105 or other local
security devices 101 using a serial or Internet Protocol (IP)
network interfaces available on the particular vehicle and payload
control system. For example, the local security device 101 provided
at the vehicle can comprise a TMR configuration of three diverse
Single Board Computers (for example, one Phidget.TM. board-based
available from Phidgets Inc. of Calgary, Alberta, Canada, a
Beaglebone.TM. Black, and a Minnow.TM. Board), each of which may
run a different operating system and be attached to separate,
diverse GPS sensors (i.e., different than the base GPS for the
vehicle) and/or spatial/accelerometer-based sensors that provide
3-axis information on speed and direction. Each of these external
devices or sensors can provide, with different degrees of fidelity,
information useful to verify system position as well as the
direction of travel.
[0158] In such embodiments, the onboard local security device(s)
101 have monitoring and detection capabilities for systems that are
independently verifiable on the vehicle. Position data from
multiple sources, including diverse GPS systems and other position
systems such and IMU/INS, can be used to evaluate the validity of
positional data received from a main GPS used by the vehicle
controller to determine a potential attack on that system. In
addition, basic commands, such as turning the vehicle 90 degrees to
the left, can be verified by the spatial accelerometer-based
sensors 150 to confirm if the system is in fact doing what the
operator intended. These sensors 150 can also maintain a rough
track of the system's position relative to its planned path and be
used to verify location and give a fallback for navigation
functionality. These components may be networked together, for
example, using Ethernet cables connected to a switch. This
equipment is sized to be powered by the available vehicle's onboard
power source and to fit within the size and weight limitations of
the available payload space. Corrective actions are also either
self initiated on the vehicle itself or sent from the base
controller to the vehicle through radio communications.
[0159] Furthermore, a local security device 101 of a base
controller can integrate data received from the local security
devices 101 of the unmanned vehicles with other data to provide
different types of cyber threat detections. At the base controller
unit, redundant local security devices 101 can be hosted in a
diverse cloud environment used to protect the monitoring of the
base system data, to detect potential threat, and to provide data
from both the monitors and from the systems back to the control
device 105. This data can also be used for further monitoring,
performing tests for detections that require integration of data
from sources outside the vehicle, outputting alerts that notify the
system and system operators of potential threats, and also allowing
for corrective actions.
[0160] Furthermore, the operation of a fully autonomous vehicle
(i.e., a self driving vehicle) involves automatically adjusting the
speed and direction of the vehicle in response to the detection of
possible obstacles and hazards. A key variable to be adjusted is
the velocity of the vehicle. For example, in the event the vehicle
detects an obstacle blocking its forward path the vehicle should
reduce its velocity as needed to avoid the obstacle. This may mean
bringing the vehicle to a complete stop. However, a cyber attack
may wish to damage and/or harm the occupants of the vehicle. The
cyber attack may accomplish this by recognizing that the detection
of an obstacle only triggers a change in the vehicle's velocity as
the distance between the vehicle and obstacle shrink. A cyber
attack could cause a collision between the vehicle and an object by
overriding how the vehicle behaves as it closes in proximity with a
potential obstacle. For example, the cyber attack may cause the
vehicle to increase its velocity as the distance to the obstacle
decreases. This illuminates the need for a security solution to
verify that the vehicle and its automated systems are behaving as
they should.
[0161] In this example, to defend the vehicle against this type of
cyber attack a local security device 101 is deployed in the vehicle
to monitor and verify the integrity of the vehicle. The local
security device 101 monitors data coming from two sensor systems:
(1) LIDAR equipped on the vehicle used for obstacle detection, and
(2) an accelerometer connected directly to the security device or
to a system independent from the protected vehicle such as a smart
phone equipped with these types of sensors. The local security
device 101 knows that the vehicle should adjust its velocity based
on the detection of possible obstacles and hazards. It can use its
equipped accelerometer to estimate the current speed of the vehicle
and determine if the vehicle is adjusting its velocity in response
to detected obstacles. If the vehicle is not (for example due to a
potential cyber attack), the security device can disengage the
autonomous functions of the vehicle and return control to a human
driver. For example, suppose that the vehicle is equipped with a
LIDAR that can detection obstacles at a distance of 80 meters. In
addition, we know that the vehicle is designed to travel at a rate
of 40 km/hr, and its velocity is set according to the function f(d)
where d is the distance reported by the LIDAR between the vehicle
and an obstacle in meters. For this example, we will say that f(d)
is:
v=40 km/hr for all d>30 m Eq. 1:
v=(40/30*(d-1)) km/hr for 0<=d<=30 m Eq. 2:
[0162] In addition, let us assume that we can use the accelerometer
to estimate the current speed of the vehicle within 1 km/hr; i.e.,
if the vehicle is traveling at 40 km/hr our security device will
register a velocity between 41 km/hr and 39 km/hr. If a cyber
attack were initiated to keep the vehicle traveling at 40 km/hr, as
soon as the vehicle detected a obstacle that was 75 m away the
security device would detect the inconsistency when the LIDAR
reported a distance of 29.5 m (((29.5-1)*40/30)=38 km/hr outside of
the range our security device had determined using its
accelerometer) and initiate appropriate protections; i.e.,
disabling the automated controls. If needed, the security device
could use a sliding window to help reduce false alarms (e.g., need
to see at least 10 measurements that were outside of the expected
behavior).
[0163] Another exemplary deployment environment for the cyber
security system 100 is Industrial Control Systems (ICS). ICSs are
used to manage processes that operate mechanical devices that make
things or move things, control power plants, energy production,
storage, or transportation facilities, or water treatment centers,
or that control larger machines that move people or cargo.
Exploiting an ICS vulnerability can therefore have a broad range of
impacts and consequences including: (1) Direct physical damage to
affected equipment and systems; (2) Small-scale, local disruption;
(3) Injury or death to operators, passengers or the general public;
or (4) Catastrophic disruptions to the transportation system. For
example, Industrial Control Systems (ICS) for maritime port
container handling are used to control key functions at the many
port facilities such as safety, security, and access control. ICSs
can also be used to monitor pressure flow and pathways of oil and
gas pipelines and refineries, to control and monitor power
generation transmission and distribution, to monitor and control
terminal operating systems; to monitor and control shipboard
navigation systems, etc. In addition to insider and supply-chain
based attack vectors, several factors have contributed to the
escalation of risk to these systems: 1) adoption of standardized
technologies with known vulnerabilities, 2) connectivity of control
systems to other networks, 3) non-secure remote connections, and 4)
the widespread availability of technical information on these
systems. The cyber security system 100 can be used to provide
protections for one or more ICS or Supervisory Control And Data
Acquisition (SCADA) based systems.
[0164] For example, shipping containers move the vast majority of
non-bulk or petroleum oil or lubricants that flow through US ports.
Arriving and departing on container ships, these shipping
containers transit to and from the port on trucks or trains and the
process from arrival to the port is computerized, automated, and
subject to manipulation and cyber attacks. The ICSs that control
the offload/onload, movement, and tracking is particularly critical
as the port system is one of the primary intermodal touch points
for the US transportation and trade sectors. An exemplary
embodiment in which the System-Aware protections provided by the
cyber security system 100 for an ICS that manages the unloading and
shipping out of containers from ships may include multiple local
security devices 101 placed at various stages of the automated
processes that guide a container from a ship to the crane that
takes the container off the ship, to the temporary storage area
where the container will then be transferred to a land-based
transportation service such as rail or long-haul trucking. If a
cyber-attack emanating from a trusted insider were launched, for
example, to attempt to switch the position of two containers in
which one contains harmful material and the other contains
refrigerated food products, and to allow the harmful container to
be shipped to a location that was originally listed as the place to
ship the refrigerated food, at each location, the local security
device 101 can be deployed to serve as an interface to collect
data, independent of the identification numbers on the container
itself, and/or to validate the contents and the location of a
container. For example, by obtaining data from independent weight
and temperature sensors 150, the local security device 150 can
validate that the contents of the container that is supposed to be
refrigerated is in fact suitably refrigerated (i.e., interior
temperature below 35.degree. F.) and that the weight
characteristics of the container are consistent with expected
values, before the containers are loaded on a truck for a
destination. A control device 105 operably coupled with the local
security devices 101 can monitor for anomalies in the
characteristics of the containers and alert operators or port
managers to a detected threat, thus allowing for corrective actions
including manual intervention from a human.
[0165] Thus, detection rules can be provided by the cyber security
system 100 for key functionality identified to be protected for
this particular protected system 103. Examples of key functionality
include whether the temperature inside the refrigerated section is
within fixed predefined limits, or pressure inside the compressors
that control the heat exchange process that keeps the system
cooling functions operational are operating normally and
effectively changing system temperature within system
specifications. One method for measuring the correct temperature
involves introducing several thermometers (from different vendors)
inside the refrigerated section and a pressure gauge inside the
compressor will provide independent measurements of the physical
state of the system which can be compared to the existing
manufacturer-provided functionality, with the capability to both
compare the independent and standard readings for discrepancies,
and also to compare the system for logical discrepancies using the
independent sensors 150 such as lower pressure leading to higher
temperature, or the reverse. The local security device 101 detects
and reports the temperature measurements, the pressure readings,
and any detections which occur on the refrigeration system to a
control device 105 for further evaluation, or detections that
require integration with data from outside the system, alerts
system operators, and provides for possible corrective action
taking.
[0166] It will be appreciated that the modules, processes, systems,
and sections described above can be implemented in hardware,
hardware programmed by software, software instructions stored on a
non-transitory computer readable medium or a combination of the
above. A cyber security system, for example, can include using a
processor configured to execute a sequence of programmed
instructions stored on a non-transitory computer readable medium.
For example, the processor can include, but not be limited to, a
personal computer or workstation or other such computing system
that includes a processor, microprocessor, microcontroller device,
or is comprised of control logic including integrated circuits such
as, for example, an Application Specific Integrated Circuit (ASIC).
The instructions can be compiled from source code instructions
provided in accordance with a programming language such as Java,
C++, C#.net or the like. The instructions can also comprise code
and data objects provided in accordance with, for example, the
Visual Basic.TM. language, or another structured or object-oriented
programming language. The sequence of programmed instructions and
data associated therewith can be stored in a non-transitory
computer-readable medium such as a computer memory or transponder
device which may be any suitable memory apparatus, such as, but not
limited to ROM, PROM, EEPROM, RAM, flash memory, disk drive and the
like.
[0167] Furthermore, the modules, processes systems, and sections
can be implemented as a single processor or as a distributed
processor. Further, it should be appreciated that the steps
mentioned above may be performed on a single or distributed
processor (single and/or multi-core, or cloud computing system).
Also, the processes, system components, modules, and sub-modules
described in the various figures of and for embodiments above may
be distributed across multiple computers or systems or may be
co-located in a single processor or system. Exemplary structural
embodiment alternatives suitable for implementing the modules,
sections, systems, means, or processes described herein are
provided below.
[0168] The modules, processors or systems described above can be
implemented as an electronic device programmed with microcode, a
hard-wired analog logic circuit, software stored on a
computer-readable medium or signal, an optical computing device, a
networked system of electronic and/or optical devices, a special
purpose computing device, an integrated circuit device, a
semiconductor chip, and a software module or object stored on a
computer-readable medium or signal, for example.
[0169] Embodiments of the method and system (or their
sub-components or modules), may be implemented on a special-purpose
computer, a programmed microprocessor or microcontroller and
peripheral integrated circuit element, an ASIC or other integrated
circuit, a digital signal processor, a hardwired electronic or
logic circuit such as a discrete element circuit, a programmed
logic circuit such as a PLD, PLA, FPGA, PAL, or the like.
[0170] Furthermore, embodiments of the disclosed method, system,
and computer program product may be readily implemented, fully or
partially, in software using, for example, object or
object-oriented software development environments that provide
portable source code that can be used on a variety of computer
platforms. Alternatively, embodiments of the disclosed method,
system, and computer program product can be implemented partially
or fully in hardware using, for example, standard logic circuits or
a VLSI design. Other hardware or software can be used to implement
embodiments depending on the speed and/or efficiency requirements
of the systems, the particular function, and/or particular software
or hardware system, microprocessor, or microcomputer being
utilized. Embodiments of the method, system, and computer program
product can be implemented in hardware and/or software using any
known or later developed systems or structures, devices and/or
software by those of ordinary skill in the applicable art from the
function description provided herein and with a general basic
knowledge of the computer programming and electrical/computer
engineering arts.
[0171] Therefore, in various embodiments, a cyber security system
can comprise at least one local security device configured to
monitor operational information of an associated protected system,
in which the at least one local security device is configured to
determine an occurrence of a security condition present at one or
more of the protected systems based on analysis of the at monitored
operational information, in which the at least one local security
device is configured to output an indication of the security
condition via a user interface, and to calculate and indicate one
or more response options via the user interface, and in which the
at least one local security device is configured to issue device
commands to the associated protected system to restore a desired
operating state of the protected system.
[0172] Embodiments can further comprise at least one control device
operatively coupled with one of more of the plurality of local
security devices via a network, and configured to receive the
monitored operational information from each of the at least one
local security device, and can also further comprise at least one
global device operatively coupled with a plurality of the control
devices. Each of the at least one local security device and each of
the at least one control device can be configured to communicate
securely using encryption, in which each of the at least one local
security device is configured to auto register with at least one of
the control devices via, and in which the at least one control
device is configured to authenticate the local security device. In
various embodiments, the at least one control device can be further
configured to output one or more commands associated with one of
more the response options to one or more the local security
devices.
[0173] The at least one the local security device can be co-located
with its associated protected system, and the user interface can
include a console configuration tool. The at least one control
device can be configured to determine the security condition using
the monitored operational information and external data. In various
embodiments, the operational information can be received from two
or more of the local security devices.
[0174] In other embodiments, the cyber security system can comprise
at least one control device configured to monitor operational
information of an associated protected system, in which the at
least one control device is configured to determine an occurrence
of a security condition present at one or more of the protected
systems based on analysis of the at monitored operational
information, the at least one control device is configured to issue
device commands to the associated protected system to restore a
desired operating state of the protected system, and the at least
one control device is configured to output an indication of the
security condition via a user interface, and to calculate and
indicate one or more response options via the user interface.
[0175] Furthermore, in some embodiments, at least one local
security device can be operatively coupled with one of more of the
at least one control device via a network, and at least one control
device can be configured to transmit the monitored operational
information to the at least one local security device. At least one
global device can also be operatively coupled with a plurality of
the control devices.
[0176] In various embodiments, each of the at least one local
security devices and each of the at least one control devices can
be configured to communicate securely using encryption, and each or
the at least one local security devices can be configured to auto
register with at least one of the control devices. The at least one
control device can be configured to authenticate the local security
device. The at least one control device can be further configured
to output one or more commands associated with one of more the
response options to one or more the local security devices, and,
upon receiving the one or more commands, the local security device
can be configured to issue device commands to the associated
protected system to restore a desired operating state of the
protected system.
[0177] In various embodiments, the at least one control device can
be configured to determine the security condition using the
monitored operational information and external data. The
operational information can be received from one or more of the
local security devices.
[0178] Embodiments can comprise a cyber security method which
includes monitoring a protected system by identifying data to be
collected and assessing relevant operational information or
measurements of the protected system; detecting a potential cyber
attack by performing security analysis to determine a cyber
security threat or breach event comprising an unwanted condition or
state of the protected system based on the monitored operational
information or measurements; informing by outputting electronic
information associated with the cyber security threat or breach
event; and correcting the cyber security threat or breach event by
outputting one or more commands to the protected system suitable to
cause the protected system to cease operating in the unwanted
condition or state.
[0179] The cyber security method can also, in some embodiments,
include storing information related to the cyber security threat or
breach event for forensic analysis.
[0180] Detecting can comprise determining a cyber security threat
or breach event by comparing the monitored operational information
or measurements to known system behaviors. Detecting can comprise
determining the a cyber security threat or breach event using
verifiable voting among a plurality of results of the security
analysis, and/or determining the a cyber security threat or breach
event by performing security analysis of security design patterns
detected among multiple the local security devices.
[0181] The cyber security method can be performed by at least one
local security device, at least one control device, or a
combination of one more of each.
[0182] In various embodiments, informing can comprise outputting
human and system actions to be taken in response to the cyber
security threat or breach event. One or more of the monitoring,
detecting, informing, and correcting can be performed in
real-time.
[0183] Embodiments can further comprise a non-transitory computer
readable medium having stored thereon software instructions that,
when executed by a processor, cause the processor to perform cyber
security operations including:
[0184] monitoring a protected system, using at least one local
security device, by identifying data to be collected and assessing
relevant operational information or measurements of the protected
system:
[0185] detecting a potential cyber attack by performing security
analysis to determine a cyber security threat or breach event
comprising an unwanted condition or state of the protected system
based on the monitored operational information or measurements;
[0186] informing, by a control device operably coupled to the at
least one local security device, by outputting electronic
information associated with the cyber security threat or breach
event; and
[0187] correcting the cyber security threat or breach event by
transmitting, by the control device, an electronic message to the
at least one local security device to cause the at least one local
security device to output one or more commands to the protected
system suitable to cause the protected system to cease operating in
the unwanted condition or state.
[0188] The non-transitory computer readable medium can further
include storing information related to the cyber security threat or
breach event for forensic analysis.
[0189] While the invention has been described in conjunction with a
number of embodiments, it is evident that many alternatives,
modifications and variations would be or are apparent to those of
ordinary skill in the applicable arts. Accordingly, Applicants
intend to embrace all such alternatives, modifications, equivalents
and variations that are within the spirit and scope of the
invention.
[0190] Thus, has been shown a cyber security system and method that
includes one or more local security devices and/or at least one
control device coupled to the one or more local security devices
and configured to determine a cyber security threat or breach event
based on analysis of one or more operational information of a
protected system.
* * * * *
References