Keeping tab on intrusion events: real security analysis

When a physical security violation occurs, we tend to divide such events
into either (1) reconaissance and (2) compromise.  Depending on the value
of confidentiality of the data (e.g. in the case of intellectual property)
or the impact of unauthorized changes we may choose to either respond or
ignore these events.  The majority of organisations will respond to (2),
while response to (1) will in most cases remain limited solely to
government agencies and larger corporations.

When an attempt to physical security violation occurs, which fails due to
our countermeasures, this may still be noticed.  E.g. a lock can be
damaged, or an intrusion detection system may have triggered on it.
Usually these incidents are logged and investigated.  This way we can
profile existing groups targeting our infrastructure, instead of starting
off-base each time an incident occurs.

IT Security Violations actually work in the same way.  An IDS system can
provide us with information about an actual attack, but so can logfiles of
devices themselves (e.g. a non-exploitable version of a daemon may still
log an error for an attempted exploitation).  Usually this information is
disregarded until a true security compromise took place.

If we would now use the same approach for IT Security violations, which
are not full compromises, we could learn a great deal about the
adversaries we are up to.  This means that we actually could profile
offenders and gather data on ongoing attacks, even before an actual
compromise occurs.  Usually a great deal of reconaissance takes place
prior to an actual penetration attempt.  There is no reason to believe
that this final penetration attempt would actually be noticed, if the
initial reconaissance has been performed in a qualitative way.  However,
those initial reconaissance attempts are usually discarded due to their
quantity.

In the end, this comes down to modernizing our current level of
correlation, and increasing our level of intelligence and analysis skills
(not purely on a technical, but on a "security" level).  Currently, we
usually only start correlating as soon as an actual compromise occurs.
Investigations are only launched just then, if we notice it.  If the
perimeter compromise is not noticed, and further correlation does not
occur on these "benign" false positives, we may not find out until
information has already left our network.

Currently, IT Security Investigations are often focused on the following
principle:
- we see sign of an intrusion event
- we investigate the destination host
- is it vulnerable, patch and verify host integrity
- not vulnerable, discard alert

This is not truly the way a physical security event is usually handled.
In order to get methodologies straight we should be moving closer into
this direction than moving away from it.

Ofcourse, this is easy to say, as there are significant resource concerns.
These security principles may also not all be equally applicable, due to
the concept of "class breaks", which are usually not present in physical
vulnerability management.  Another issue is the pure quantity of attempts,
although this could be solved if we have the opportunity to clearly show a
difference between "scans" and "focused attacks".

One way that I have seen the concept of this mail introduced in real-life
organisations is in the form of weekly reports, where intrusion attempts
are classified and even investigated further using different tools.  These
can go anywhere from a listing of the pure attempts up to a full-scale
investigation where events are even linked by source subnets and thus a
threat model is built for this specific attack pattern (true security
analysis).

I was wondering whether anyone is using such a methodology which is
closely linked to their corporate security scheme so they are handled
close-to-equally.  I perfectly understand this information is usually
confidential, but it may still be worth a little discussion.

Thanks for your time, best regards,
Maarten

--
Maarten Van Horenbeeck, GCIA <[email protected]>
http://www.daemon.be/maarten