Traditional Host Intrusion detection systems usually bring an attack to an operator's attention, but this asynchronous attack response paradigm may not be sufficient to stop an attack before it can do damage to a system. The solution, Amr Ali and Zach Dexter explain, is reactive security, or shutting down attacks in real-time, via collaborative attack vector closure.

1. SentryHQ’s Reactive Security: The New Host-Based Intrusion
Detection Paradigm
Traditional host intrusion detection systems usually bring an attack to an operator's attention,
but this asynchronous attack response paradigm may not be sufficient to stop an attack before
it can do damage to a system. The solution, Amr Ali and Zach Dexter explain, is reactive
security, or shutting down attacks in real-time, via collaborative attack vector closure.
Introduction
There are two problems with traditional host intrusion detection systems (HIDS). First,
the attack may not be detected, because traditional HIDS may not pick up on sophisticated
attacks or attacks that use new vectors. Second, even if an attack is detected, damage may
occur before an operator can respond. To solve the first problem, we propose an open-source
repository of attack detectors. To solve the second problem, we propose a system to respond to
attacks in real-time, including an open-source repository of attack responses.
Traditional host intrusion detection systems can abstractly detect attacks that are either
identical to previous attacks or similar to previous attacks. The former can be detected using
signature databases, and the latter by machine learning algorithms.
Pattern recognition is an inductive approach to intrusion detection: The HIDS infers that
an attack is taking place when an event shares characteristics of a prior attack. But what if we
know nothing about an attack? What if an attack uses a new vector? Traditional host intrusion
detection systems solve this problem by letting the attack happen and notify an operator, or
partially sever access to the system while being indifferent to the nature of the attack or the
operations of the system itself.
A traditional HIDS will update a rule database or exclude the just-discovered attack
vector from a training set of data on what constitutes the normal behavior of a system. The
problem with the traditional HIDS approach is that it seeks to stop poorly-executed or non-
coordinated attacks that look like previous attacks or otherwise fail to fool a system.
To stop sophisticated or new attacks, we must get the HIDS to deduce that an attack is
occurring, even if the HIDS has no knowledge whatsoever of the attack vector, and even if an
attack is clever enough to appear to machine-learning algorithms as normal behavior.
A deductive security system would specify a set of invariants. If even one of those
invariants changes, a system is said to be compromised. But how can any HIDS specify a set of
invariants large enough to provide meaningful coverage of attack vectors? How can a deductive
HIDS know how invariants might change across deployments to different machines? And what
does it mean to close an attack vector that the deductive HIDS doesn't even know is open?

2. The answer is collaborative attack vector closure, an easy-to-understand adaptation
of open-source software engineering principles. A community of attack detector authors
contributes to an open-source repository of invariants.
Let us call an invariant expressed via a programming language a detector. Contributors
generalize the invariants so that members of the community may clone any detector, provide
parameters relevant to their implementations, and store the customized detectors in a private
repository. After testing the customized detectors in the field, community members may commit
patches and merge them upstream to the main repository of detectors.
We propose to grow this open-source platform with a good number of invariants for most
pieces of software running on today's systems. Attackers will have little opportunity to avoid
detection, as the attack vectors that the HIDS doesn't even know about are now closed.
Once an attack is detected, a pre-configured response executes as a countermeasure
with the intention to either eliminate the threat or act as means of damage control.
Threat Detection & Response
There are predominantly two methodologies to address threats; either develop detection
methods for the specificities of different threats, or detect anomalies in the behavior of the
system and treat them as possible threats.
The approach of which a detection method is developed to identify a particular threat
works well if and only if we know intrinsic details of the threat we are trying to address. Since the
possibilities of threats and their mutations are theoretically infinite, this approach is ultimately
a never ending cat-mouse chase. However, this approach also comes with the advantage of
facing less false-positives because through it we know how the threat exactly behaves and how
we could respond to it.
On the other hand we could compile a set of invariants of a system which we know how
it behaves so that we abstractly normalize its operations and be able to detect a threat through
sensing anomalies in its behavior. This method comes with the disadvantage of being abstract
and thus prone to false-positives due to a legitimate change of an operation or an
unforeseeable logical branch in a well behaving set of instructions.
There is no one concrete solution to addressing threats but a combination of variants of
methodologies. Since humans are the cornerstone of the reason security as a philosophy
exists, we propose that people engage in catering the different security approaches to their
unique needs by allowing the community a platform which offers the tools necessary to
descriptively define their systems’ operations and at the same time be able to define anticipated
threats and how to respond to them.
SentryHQ’s the platform that allows the community to develop detectors for unbounded
number of operating systems and applications, detectors that are synchronously combined
with responses that are not only catered to the underlying operating system but also to the
applications running on-top of it. The locally synchronized combination of a detector and
response acts as a first layer of defense against any threat.

3. Real-Time Attack Mitigation
We believe that the only way to stop an attack is to prepare an automatic, immediate
response before the attack happens. Too often, an attack is over, and the attacker has made
off with valuable data, before the attack is noticed. Even if a traditional Host Intrusion Detection
System notices the attack, often nothing is done until an operator responds. SentryHQ bolsters
the operator’s capabilities by allowing her to configure immediate attack responses.
Attack detectors pick up on abnormal behavior, either by specifying invariant conditions
or by looking for signs of an attack. When a detector picks up on an attack, it does more than
simply notify the machine’s operator.
The detector fires any number of attack responses on any number of machines. If
there is an attack response listening on the compromised machine, the response can shut the
attacker out of that machine. If responses on other machines are also listening on the detector,
those responses will fire, too. Such flexibility allows the security context to not only be bound to
a single machine but an entire network of machines that can realize an attack and respond to it
in unanimity.
Collaborative Attack Vector Closure
Work together to achieve maximum attack vector coverage. Community members tag
attack detection and attack response code to place it in the public repository. Any member of
the community can clone these items, upgrade them, and publish the code back to the public
repository. Users can leave code with modifications specific to their machines unpublished.
Over time, SentryHQ will severely restrict the number of vectors still open to attackers.
For each detector made available to the community, an attack vector is closed. And each
response available in the public repository gives community members more power to stop
attacks before they result in damage.
Why SentryHQ?
No one likes nor have the time to dive into endless amount of configuration files and
foreign syntaxes to be able to run a HIDS that only reports back a compromise. Beyond initial
configuration of your account; SentryHQ components are entirely configurable through our
intuitive hosted web interface.
In cyberspace the first “O” of Boyd’s OODA (Observe, Orient, Decide, Act) loop is
always impaired; with SentryHQ we’ve managed to enable your entire network to be able to
observe an elaborated attack and respond to it on many levels and in dynamic configurations
through the detectors and responses deployed on any number of machines you have.

4. SentryHQ utilizes a custom implementation of SSHv2 protocol for all of its
communication, be it internal or external. We’ve taken great care to account for the worst
situations a system can be into including ours.
With SentryHQ you can benefit from and participate in an ever-growing community that
constantly supplies the public repository with new detectors and responses that addresses
threats that target most applications and their underlying operating systems.