[OpenCALEA] Re: control design

[Jesse Norell]

A very important consideration in either scenario is security.  Having a
completely comprehensive packet sniffing system, with access to the
entire network and delivery to an arbitrary location sure smells like a
prime target to me.  :)  It would probably be best to have the opencalea
machines physically powered off most of the time.

>From a security standpoint, I think the second possibility would be
favorable.  The first requires a robust authentication mechanism in the
controlling application/interfaces.  The second option requires
authentication in a single location, the database.  If I'm working on
it, I understand the latter better, and that's where I'd be heading
(which doesn't make it the "right" approach, but maybe "better" in my
case).

We also need authentication to the df_collector, especially when using
udp.  Likely this same mechanism could be used to the lea_collector.

And of course "authentication" above could be "authentication and
encryption".



On Thu, 2007-04-05 at 10:33 -0600, Jesse Norell wrote:
> Hello,
> 
>   More thoughts, on a different piece...
> 
>   To perform a surveillance, the specific data sources involved (ie. the
> specific IAP's collecting CmII and CmC) need to be identified, started,
> and monitored.  If for some reason something was interrupted, say a tap
> machine was rebooted, that needs to be caught and the surveillance
> restarted (and there are also some optional CmII events to be reported
> for that).
> 
>   In the short term this could quite viably be a manual process, which
> is the current track things are heading.  Eventually it would be nice to
> be able to define an "interception" in some manner, which would define
> exactly what IAP's are involved, what they're looking for, where to send
> the data, the case id, subscriber identity, etc. and have everything
> automated.
> 
>   One possibility is to have a controlling application that both allows
> creation of an "interception" object with the above info, which also
> knows how to invoke/monitor/restart the IAP's, and generates
> corresponding CmII events.  If the controlling app gets restarted, the
> surveillance object needs to be persistent and it can pick back up
> monitoring/etc.  The controlling app can also log some of the data that
> would be relevant to the "secure and accurate record of each
> interception" that we're required to keep (eg. date/time that
> interceptions are enabled/disabled, etc.).  Possibly the app could store
> the entirety of the record info to easily print (I believe the actual
> record needs to be on paper, as it has to be signed).
> 
>   Another option would be to define an "interception" in a database of
> sorts (rdbms or otherwise), and have every IAP source independently
> check that database periodically (frequently), and take appropriate
> action (eg. start/restart/stop an intercept, and send CmII events).
> There would still need to be an interface (possibly gui?) to define an
> intercept, and if each data source logged info it could also be used as
> part of the "secure and accurate record" we keep.
> 
>   Ideas for other options are certainly welcome.  Any anyone that wants
> to think about the pros/cons of the options and render an
> opinion/suggestion, please speak up.  I don't think I have a preference
> right now .. the record keeping on the first setup might be a little
> easier, the ongoing monitoring on the second may be easier (even more
> robust?).
> 
> Jesse
> 
> 
-- 
Jesse Norell - jesse@kci.net
Kentec Communications, Inc.