Re: Regarding a selection for mobile code/scripting language

["Eric Knight" <eric () swordsoft com>]

Bennett:

That's an excellent starting point.  Thank you for the link. :)

I should have tried to be more clear, I didn't necessarily want to cram all
the information possible into that message and see if I couldn't trigger
some imagination.

The following areas I feel a scripting language needs to be created for the
defenisve IW framework:

Client Side scripting, so the server can send script commands to the client.
Sandbox:  Necessary and detailed
Client Side programming, so the agent can perform security tasks
independantly: Sandbox: None.
Server Side scripting, so the server can respond to client requests.
Sandbox:  None, the server doesn't take orders from the Clients, only
information and basic requests that may or may not be fulfilled.
Server Side programming, so the server can extend its internal functions:
Sanbox:  Classification System

The Sandbox is for functions that allow casual browsing of information.  For
example, I have a function that allows me to browse through the filesystem
at will.  An executive of a company doesn't want a system administrator to
have 24/7 browse-at-will capabilities for the host, so the Sandbox to
prevent abuses would be placed on the client and the server, so that if the
server abuses the sandbox, the client will detect it.  I feel this can
entirely be accomplished inside the library.

I have my own requirement for compatibility with a data structure that I use
throughout the system called a "dynamic", but any language that I can plug
in that has the ability to have linked lists, vectors, or some equiv will
work fine.

Okay, so what's the purpose:

Rapid Administration Development:

Lets take an example and say I need to install a new product across
the enterprise, I turn on the event macro recorder, and do the task one time
for one host.  Script is generated automatically.  The script is then placed
in the schedule queue to execute at the next host startup or at a specific
time, and each host then installs the software.  I want to see the whole
process to create the conditions for deploying a product enterprise wide in
a controlled manner to be accomplished in only a couple of minutes from
start to finish.

In this particular framework, patch management/installation, software
deployment, remote backup, "dirty word searches", software piracy spot
checks, and anything in the category of "employee abuse" all can exist with
a minimum effort with a 'learn by example'/'script language' combo.  I feel
this is mandatory, not a "nice to have".

Rapid Response Development:

The process of creating reaction and response needs to be a custom process
as well as an integrated one.  Reaction/response technology is something
along the lines of "intrusion prevention" but should be easier to produce.
The VES framework allows for what we see in all IP products, but has the
ability to extend across all of them.  For example:

Speaking out the code:  "Check the tasklist on the host to see if Norton's
Anti-Virus running, if not, then execute the script that launches forensics
examinations, notify the server, and reactive Norton's Anti-Virus."

Simple code, really.  There are millions of these "active responses" that
need to be generated.  I thought about hardcoding them all, but then after
careful thought, I decided they should be scripted and mobile code.

In its current state, I can check the tasklist, I can create a snap-shot of
the forensics of the host, I can relaunch Norton's, but to what end?  There
are so many of these and so many environments that a little script
modification would make a world of difference for deployment compared to
having people require me to code them.

Right now, I'm hardcoding these and have 18 "basic" active responses, I want
to skip the hardcoding process entirely before I commit myself to doing them
all hardcoded.  These responses should be mobile code, as when a new tool is
deployed, so should the relevant responses, and if not, no point burdoning
the client with tons of unnecessary components to streamline performance.

Security Product Integration:

The ability needs to exist to analyze log files on the client and pass them
to the server.  This should be flexible and easy to implement for anyone
wishing to add their components into the framework, or for us to add tools,
or integration of custom tools.  I'll provide an event driven interface, but
since a lot of security tools are result based and not event driven, I
figure this option should exist as well.

For example, lets say you have a trojan horse detection tool, but it never
was built with a master console and works only one computer at a time.  By
creating a script that does something like this:

Client Side, Mobile Code as sent by server from the scheduler:

Run remote program, wait for end of execution (VES can do this, EXECUTEWAIT
INVISIBLE <filename>)
Parse the log file, adding timestamps and appropriate severity, cause,
description data fields.
Client notifes server of results (RECORDSEND <subsystem>)

Serrver Side, as defined as a subsystem:

First script, as fed to the scheduler, causes the program to be executed
across the associated group:
Inform client to run program (EXECUTEWAIT INVISIBLE <filename>)

Second script, server internal, captured the reply event from the network
framework handler and performs standard analysis tasks:

OnRecordArrived Event captured, script triggered.

Calls Delta Engine (to weed out repeat messages and redunancies)
Stores records to archive
Trigger onAnalysisComplete event
Calls any scripts for autoresponses that may be present..

Third script, server internal, called from the console, to produce a visual
list and a chart control on the desktop.

Load archive data
Apply Histogram for appropriate time period
Open ListView control onto desktop
Populate ListView
Open ChartView control onto desktop
Populate ChartView

In this way, I'm hoping that the basic tools gain enterprise use quickly and
easily without the need to create a whole new framework for each of them.

Bottom line:

Open architecture, allow for as much as possible to enter the framework,
allow for the easiest possible administration abilities, and have the
ability to automate and respond to problems.  The largest reason I wrote
this beast is so that I never again have to worry about having to "rebuy"
the same architecture over and over and over to perform similar functions.
In my mind, we need only one, and it needs to be solid, designed with
security concerns at the onset of its creation, provide the necessary basic
tools for visualization and analysis, and most importantly, be easy to use.

Okay, enough of that, I'm brainfried and writing a book again. :)  I hope
this helps explain what I'm working on better.

Take it easy,

Eric


----- Original Message -----
From: "Bennett Todd" <bet () rahul net>
To: "Eric Knight" <eric () swordsoft com>
Sent: Tuesday, January 13, 2004 11:53 AM
Subject: Re: Regarding a selection for mobile code/scripting language


I'm not 100% clear I understand every aspect of how you intend to
use this, you mention mobile code, and you suggest both with and
without attempting to sandbox.

You might want to take a look at Lua <URL:http://www.lua.org/>, it's
very light and small, designed to be cleanly embeddable. Each new
release is smaller, faster, and more powerful than the preceeding
one, while remaining portable ANSI C.

-Bennett