[Owasp-appsensor-project] appsensor architecture [feeback requested]

John Melton jtmelton at gmail.com
Mon Oct 17 23:00:48 EDT 2011

At the AppSensor summit, we discussed the way forward for AppSensor as a
project. Part of that discussion involved the reference implementation and
it's go-forward status. We talked about a lot of great ideas, many of which
seek to improve the usefulness of the implementation, but also greatly
increase the complexity. As I've tried to get the concepts written down,
I've come up with a littany of questions I had on my own. Many of you have a
lot more experience in enterprises than I do and can offer valuable insight
here so we don't go down the wrong path (at least out of the gate). I'd
really appreciate it if you could take a look at the attached basic
architecture diagrams and the questions below and give your _honest_
feedback (if it sucks, say it sucks, please!). Respond to as few or as many
questions as you are able. Feel free to respond to me off list if needed.

Attached are some basic drawings and below are a list of questions and
topics for discussion. I think I'll keep this discussion open for about 1-2
weeks to give everyone time to respond with feedback.

 - Any experience and/or good ideas for correlation of users across
applications? The thought is we identify a "bad" user in one app, and can
prevent that user from attacking not just the original app, but also other
apps. We discussed using IP, UID, Browser Agent, some hash of multiple
items. My thought would be to try to do it based on IP, but store the app
specific UID (per app) so we can use that as part of the data sent back to
the application(s) as part of the response actions in case they need to
perform some user specific function (like logout)
5. A base assumption we're working on is that if you hook up multiple
applications to a single engine, then "intrusion detection" works across all
apps. 1 Engine = 1 config file w/ 1 set of thresholds. Is that reasonable?

Intrusion Detector/Responder --> Analysis Engine
- How should communication to engine work? Rest service, SOAP service. etc.
? presumably over SSL/TLS?
- How should authn work? Mutual auth w/ certs, token based auth, basic
shared key crypto ???
- Good ideas for data format? XML, JSON, ...?

Reporting Client (Admin Monitor) --> Analysis Engine
Same questions as ID->engine

Analysis Engine --> Intrusion Detector/Responder
Same as ID->engine AND ...
- What about comms back to application? Can't make application a "server"
and open a port to listen to response from engine. Any functionality like
websockets available? What about polling? Any good options/ideas here?

Analysis Engine --> Other Systems
- Is CEF format over a syslog transport the right option to use or at least
start with (that's what we discussed)
- If using syslog, is authn taken care of? If not, options?

Other Systems --> Analysis Engine
same as Engine --> Other systems

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20111017/703feea2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AppSensorComplex.png
Type: image/png
Size: 41073 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20111017/703feea2/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AppSensorSimple.png
Type: image/png
Size: 37765 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20111017/703feea2/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AppSensorEmbedded.png
Type: image/png
Size: 18949 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20111017/703feea2/attachment-0005.png 

More information about the Owasp-appsensor-project mailing list