Next: 2.2.0.3 Communications security
Up: 2.2 Communication between the
Previous: 2.2.0.1 Back- and front-end
2.2.0.2 The
adaptive
security
application
programming
interface
(AS-API)
The
AS-API
defines
the
way
the
KBS
and
the
plug-ins
interact.
A
standardized
API
should
contain
definitions
for
data
types,
functionality
and
protocols.
Several
types
of
data
have
to
be
exchanged
between
the
various
components:
- control
data
commands
for
controlling
the
peripheral
applications
or
the
adaptive
security
management
system
and
changing
their
behaviour
(``start'',
``stop'',
``activate'',
``deactivate'',
``pause'',
``resume'',
``change
settings'',
``apply
settings'',...)
- application
data
data
that
the
peripheral
application
needs
in
order
to
change
its
settings,
definitions
that
are
passed
between
the
definition
application
and
an
adaptive
security
engine
to
modify
its
rule-base,
etc.
For
example:
the
adaptive
security
management
service
may
want
to
change
the
settings
of
a
firewall.
Therefore,
it
contacts
the
firewall
according
to
a
certain
protocol.
This
protocol
describes
to
first
open
the
connection,
then
issue
a
``change
settings''-command,
next
feed
the
data
to
the
firewall,
wait
for
acknowledgement,
apply
the
settings
and
then
tear
down
the
connection.
The
interfaces
can
be
grouped
according
to
their
location
in
the
model:
- AS-API
1:
monitoring
application
and
decision
enforcement
application
API
This
API
defines
the
interface
with
the
back-end
processors
of
the
applications
that
are
shown
in
the
bottom
part
of
figure
2.1
on
page
![[*]](cross_ref_motif.gif)
:
the
monitoring
application
and
the
decision
enforcement
application.
Via
the
API
the
management
system
can
look
up
the
functionality
that
is
provided
by
its
corresponding
front-end
device.
This
includes
the
type
of
information
it
can
request
and
the
commands
it
can
send
to
the
application
or
device
(or
in
fact,
to
its
back-end
processor).
It
also
gives
the
central
management
system
an
interface
to
access
information
gathered
by
the
monitors
and
implements
a
signalling
system
to
raise
alarms.
- AS-API
2:
security
definition
and
management
application
and
logging
and
auditing
application
API
The
``cockpit''
of
an
adaptive
security
system
consists
of
a
console
where
a
security
manager
can
check
the
state
of
the
system
and
has
the
means
to
interfere
manually
with
its
operation.
It
needs
to
provide
the
functionality
required
to
feed
rules
to
the
system
that
are
input
either
directly
or
through
a
definition
application.
Changes
made
to
the
rules
will
be
based
on
output
from
the
system
that
is
collected
in
the
logs.
Additional
functionality
can
be
provided
to
directly
manipulate
the
peripheral
applications
so
that
the
management
console
functions
as
a
single
central
console
for
modifying
the
various
components
of
the
system:
starting
and
stopping
services
at
network
servers
or
firewalls,
changing
routing
rules,
changing
the
settings
of
network
interfaces
from
promiscuous
to
non-promiscuous
mode
and
so
on.
AS-API
2
sits
between
the
adaptive
security
management
system
and
the
upper
part
of
figure
2.1.
- AS-API
3:
security
service
provider
API
This
is
likely
to
be
the
most
difficult
API
to
define
because
of
the
wide
variety
of
services
to
be
supported.
Also,
in
certain
circumstances
the
information
that
is
exchanged
between
various
components
is
confidential,
for
instance
when
a
client
asks
a
key
management
service
to
generate
a
secret
key.
Possibly
not
only
the
application
data
is
sensitive,
but
information
could
also
be
derived
from
simply
watching
the
commands
that
are
passed
through
the
system
(i.e. the
control
data).
- AS-API
4:
adaptive
security
management
system
and
security
engine
API
As
discussed
in
section
2.1.7,
several
adaptive
security
management
systems
may
wish
to
interact
or
exchange
definition
information.
AS-API
4
deals
with
this
type
of
interoperability.
The
API
could
also
define
an
interface
for
various
engines
to
share
information
without
having
to
pass
through
the
central
management
system,
for
instance
for
replication
of
data.
Engines
may
also
be
configured
to
share
data
with
each
other
so
that
intrusion
information
can
be
aggregated
on
a
higher
level.
The
degree
to
which
a
standard
security
framework
can
be
created
clearly
depends
on
the
feasibility
of
creating
standardized
APIs.
It
does
not
seem
realistic
to
expect
systems
to
emerge
that
would
fully
implement
all
functionality
of
these
APIs.
On
the
other
hand,
systems
may
already
exist
that
provide
functionality
that
corresponds
to
what
is
listed
above
or
that
contain
a
subset
of
the
functions
described
above.
Various
levels
of
interoperability
could
be
defined
according
to
the
provided
functionality.
In
my
opinion,
at
least
some
functionality
from
AS-API
1
would
have
to
be
present
in
order
to
comply
with
the
framework
and
the
definition
of
a
standardized
adaptive
security
management
system.
This
should
at
least
allow
for
popular
existing
peripheral
applications
like
firewalls
or
routers
to
be
dynamically
reconfigured.
Next: 2.2.0.3 Communications security
Up: 2.2 Communication between the
Previous: 2.2.0.1 Back- and front-end
(c) 1998, Filip Schepers