Re: [OpenCALEA] Re: control design

[Manish Karir]

I have been punting on security for quite a while now and that is
the first question everyone asks. :(

Our thoughts on that atleast till the May deadline is to have
everything working and operational.  Security for us would then
be acheived by firewalling the controller/tap devices such that
only the controller can access them.  There will be one
fixed and designated controller in our architecture.

Not real security, but stop gap to buy us more time to build something
more proper.

-manish


On Thu, 5 Apr 2007, Jesse Norell wrote:

> 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.