Re: Regarding a selection for mobile code/scripting language

From: Eric Knight (eric_at_swordsoft.com)
Date: 01/14/04

  • Next message: Chris Anley: "RE: Buffer UNDERFLOWS: What do you know about it?" 
    To: "Bennett Todd" <bet@rahul.net>
Date: Tue, 13 Jan 2004 23:10:20 -0700

    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

  • Next message: Chris Anley: "RE: Buffer UNDERFLOWS: What do you know about it?"

    Relevant Pages

    • Re: Banana Republic (was Re: OpenVMS Book Wins award)
      ... overtaken by the more prosaic aspects of supporting WASD. ... for example), that it is better economy, if a client breaks the ... to allow a script to run to completion rather than try and ... The server just throws away ...
      (comp.os.vms)
    • Re: HTTPSConnection script fails, but only on some servers (long)
      ... (HTTP/CONNECT + switch to HTTPS) ... wget and my python script. ... >>The python script works with server A, ... the problem seems to depend on both the client ...
      (comp.lang.python)
    • Re: secure transfers and authentication
      ... Thanks james that looks to be a really handy guide on the whole thing. ... On a side note does anyone know why i have problems posting to the list using the reply function in my mail client? ... From the server ssh to your clients and save the rsa keys ... You could create a script like this: ...
      (Security-Basics)
    • Re: How do we get there from here?
      ... >> executing on the server as a pre-processor. ... If there are client side versions of PHP, ... > name implies a static text file, is it different from a PHP script? ...
      (comp.databases.pick)
    • Re: What doesnt lend itself to OO?
      ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
      (comp.object)