Re: open source artificial ignorance-like systems

Writing the rules assumes you apply a priori knowledge about the
relationship between log/event attributes to create the rule.

With supervised learning, you work backwards from empical data.  You
train the AI model by telling it 'given all this data, I want this
output'.  The model then figures out the multi-dimensional
relationships between these log attributes.  This can get complex when
you start introducing the time series element (sequence and
proximity).

Examples of log/event attributes include:  source, destination, ports,
ids signature, asset value, attack vector, application, OS, transport,
users, error codes, sequences between different events, volume,
frequency, time proximity, time of day, day of week, etc.

Each incoming log message is a new piece of input data.  The AI model
spits out output(s) value for each input (or combination of inputs).
Typical output includes 'do nothing' or 'alert me'.

You can also output quant values rather than an actionable event and
then feed those quant values into other analysis.  For example,
produce scores for % false positive, severity, risk exposure, etc.

(Note this covers supervised learning.  Unsupervised learning can
produce interesting information, but in my experience, you need to do
further analysis on the data/patterns extracted to turn that info
actionable information, e.g. when to ring the alarm).

Let me give you a real world example from a security event monitoring
perspective.  This is relatively straightforward b/c we're dealing
with a single event & device type.

1. Suppose you build a rule with a priori knowledge about log events,
your user population, your assets, and your business rules.

For a Windows failed login events.  You specify:

- must be a specific windows event id
- must have a specific error code (you don't care for expired
passwords, only wrong password or user doesn't exist)
- same user name
- same workstation
- at least 5 failed logins
- all within 5 minutes
- except for administrator user, where you want to be alerted after 3
failed logins
- but exclude these 5 hosts or networks because that is a QA env
- and ignore alerts at midnight to 1am for this source IP as that is
my daily scanner doing pen testing

You will generate an alert any time these conditions are true.  You
must know the relationship between all of these attributes to build
this rule.

2. For a supervised learning model, you can throw all this log data
(with the proper normalization to extract these log attributes) and
whenever you reach an alertable condition, the human supervisor says
'output=alert'.

Building the examples in this case is not that hard.  I give a
security admin all the logs in sequence and tell him to tell me 'at
what point would you take action'.  The last log event that triggers
the action or alert is marked in the log.  It is a fixed point in time
if u consider all log data as a time series of events. I then train
the network with this data, knowing nothing about why the human made
those decisions or any knowledge of the underlying business rules.

The best use of supervised learning is when you don't know all of the
criteria that would generate an alert... but you know when an alert
should be created.

You can capture patterns that a human say 'this is fishy, create an
alert' that an a priori rule would never find.  Say you see a sales
user logging in to hr payroll system.  Perhaps the payroll app has a
busted user permission or the sales guy changed his perms and it was
undetected.  If you don't have a rule to alert based on successful
logons based on user/group rights and data sources, this alert would
go unnoticed.  But a knowledgable human looking at the logs would
create an alert.

Note there is a large up front cost to produce accurate examples.
Some environments may already have this data in some eportable format
if they have dedicated security analysts looking at logs.

This is a completely different approach to 'tuning' or building rules.
 It takes empirical data and figures out the relationships.

The challenge is that the monitored env is not static.  Assets change,
vulnerabilities change, user behavior and business rules change, new
apps are deployed, new ids signatures are released, log formats are
revisioned, etc.  So you end up running a portfolio of models and age
them out over time.  You can augment these risks with preprocessing
and labelling of data (e.g. providing updated asset data, recurring
vuln scans, etc.)

You can break the problem into smaller pieces and focus on specific
event categories like only on user login behavior, or only on db
transaction behavior.

Tom

(pardon any typos as I am on a plane with my pda)

On 4/19/07, Marcus J. Ranum <[email protected]> wrote:
> Tom Le wrote:
> >But if you are talking about AI with regards to security event
> >monitoring, the only way to produce meaningfu³ actionable results is
> >with supervised training.
>
>
> What's the difference between "supervised training" and "writing the
> rules base"??
>
> mjr.
>
>