[ISM3 Users] Tuesday Insight: Blast from the Past - Information System Model

[Vicente Aceituno]

****Information System Model****originally posted Jul 28, 2006 9:43 am***

ISM3 uses the following model or information system:

REPOSITORIES are linked with CHANNELS to other REPOSITORIES and
INTERFACES.

MESSAGES travel through CHANNELS between REPOSITORIES

PROCESSES process information from REPOSITORIES and send MESSAGES

As you can see, ISM3 uses a model more complicated than the
file/process paradigm, but better adapted to networked systems.

An important choice when modeling the systems of an organization is to
choose at what OSI level are we goind to stay through the modeling.

For the NSA perhaps splitting a keyboard in interfaces (every key)
channels (every cable) and repositories (buffers) will make sense, but
for most businesses, a keyboard is an interface, full stop.

I have seen posts in other forums about people doing risk analysis and
splitting systems too thin. Excessive complexity is normally not a
good trade-off.

MESSAGE is a nice construct, as it avoids altogether the use of
strange expressions like "information in transit".

Note that a MESSAGE is different at every OSI level. At a high level,
a mail or a transaction are messages. At lower levels, a message is an
IP packet or even a eletrical signal.

Note that a CHANNEL can be a cable or any media that supports the
transmission of the message, like the air or vacuum for eletromagnetic
waves.

Note that INTERFACES includes monitors, printers, any input/output
device, and any connection between the borders of different
information systems. A router between two organizations can be
considered an INTERFACE.

Using this model, better security policies can be written, as it is
not necessary to make long and redundant rules for fax, printer,
monitor, etc. You can just talk about interfaces, and when new ones
appear in the market, the policy will normally cover them naturally
and won't need to be updated.

My best

Vicente

***Massimo Coletti then said***
I introduced two "extensions" to the standard
elements referenced in the methodology:
- Router (a specialization of Interface, as suggested)
- Route (a specialization of Channel, a "logical" channel connecting the
endpoints of a conversation)


***The answer was***
> - Router (a specialization of Interface, as
> suggested)
This is called in the ISM3 Glossary a "Node", which
emcompasses routers, switches and gateways at
different OSI levels.

> - Route (a specialization of Channel, a "logical"
> channel connecting the
> endpoints of a conversation)
Route = Logical Channel, seems like a reasonable
nickname. As it doesn't represent a new object, the
model will stay as it is, but if the term is popular
in the list, I might add a reference in the glossary.


***July 2007 notes***
ELML  v0.9 page 5 adds some detail to the model.

A new object is added: "Sessions: A temporary relationship of trust
between services." The different types of request types that can be
recorded in a log makes obvious the need of this object.

Generally speaking an object can be initiated, finalized, forzen,
unfrozen and its state can be queried or changed. Giving special names
for these actions for every object type you get:

"Any Component": Initiate - Finalize - Freeze - Unfreeze - Query State
- Change State
"Session": login, logout, suspend, resume, read state, write state
"Message": send, listen, retain, forward, read state, write state
"Repository": create, delete, block, unblock, read state, write state
"Interface": connect, disconnect, interrupt, continue, read state, write state
"Channel": open, close, hold, release, read state, write state
"Service": start, stop, pause, resume, read state, write state

My best

Vicente