Security Model

The packet analyzer software has two points of interest from security attackers perspective. They are web app and custom analyzers. Without any security, a user can access all the analysis data from all the analyzers. Without a check on what custom plug-ins can do, data leakage happens left and right. Worse yet, custom analyzers can do real damage by modifying the system resources of the underlying OS.

The security model for the application requires setting up of security for analyzers, analysis tables on MySQL, and users. All the three entities (analyzers, analysis tables and users) follow a graded security model using privilege levels. All the privilege levels are numbers starting from 1,2,....; higher number indicates a higher privilege.

Analyzers

Analyzers are assigned a privilege level. The privilege levels of default analyzers are assigned by the application developers, but are amenable to change through configuration by application administrator.

The privilege levels of custom analyzers are inherited from the user who uploads them. There would be a way to set/modify the privilege level of the incoming custom analyzer.

In fact the analyzer classes (both default and custom) should not have permission to do anything on the system. Java security model should be used to restrict the activities of the analyzers. The following references are useful in restricting the security permissions of analyzers.

In general terms Java security architecture provides a mechanism called extensions to control permissions given to a set of class files put in a directory. See the two following URLs for examples.
https://docs.oracle.com/javase/tutorial/ext/security/policy.html
https://docs.oracle.com/javase/tutorial/ext/basics/index.html

keywords in java security: grant, permissions, security policy, extensions, java.policy

https://docs.oracle.com/javase/tutorial/ext/security/policy.html
https://docs.oracle.com/javase/tutorial/security/TOC.html
http://docs.oracle.com/cd/E12839_01/core.1111/e10043/introjps.htm#JISEC3065
http://docs.oracle.com/javase/1.5.0/docs/guide/security/spec/security-specTOC.fm.html
http://docs.oracle.com/javase/7/docs/api/java/security/package-summary.html

The analyzer classes only take a packet object, analyze the object and make a call to StoreClass to store the analysis in a pre-determined table. The analysis itself is forwarded to the StoreClass as a Results object to store. The results object would be predefined and maps to DB table. Thus analyzer class does not need or should not have permission to do anything else in the operating environment.

The analyzer is given the complete packet object which has both header and payload at that given level. Thus analyzer can glean quite a bit of inferences from traffic analysis and protocol analysis. But the only place the analyzer can send this information to is the designated table.

Analysis Tables

Each custom analyzer, at the time of its' initialization, will create a DB table for storing its' analysis results. The analyzer tables shall inherit the privilege levels of the user who uploaded the analyzer. These privilege levels can of course be modified by the administrator. After initialization, the analyzer must only store its' analysis in this table and no where else.

It is meaningful for analysis tables to have higher privilege level than the analyzer itself. But a privilege level lower than the analyzer is dangerous.

Users

Users of Web app shall have a graded security model using privilege levels. A user of given privilege level can only access analysis tables of a that privilege level or lower.

Plugin Approach

All the custom plug-ins can be dynamically loaded into the application at run-time. The protocol developers can develop the plug-ins using P4toJava and load them into the application. By forcing new custom analyzers to behave as plugins, we can control their access to resources like file operations and DB access. Plugin approach is suitable for our application because of two reasons -

1. If analyzers are implemented as plugins then we can enforce security policies on them which will make it impossible for them to execute any action outside of those policies. (See - Java Policy). This adds to the application security.
2. Analyzers don't need to have disk/DB access anyway. The input parsing is already being performed by core code. Output of analyzers is also not pushed directly to DB but passes through an intermediate layer of optimized DB write code. Thus analyzer behavior is compliant to a plugin definition.

For implementing plugin loading, see -

1. Adding Plugins to a Java Application
2. Java Plugin Framework

Spring Security Framework

Spring security framework can be used to secure the web application. A way needs to be found to utilize the spring security framework to limit the capabilities of analyzers. If we can't do that in Spring Framework, we can always default to Java security framework and its' permissions / policies.

Relevant references are:
http://projects.spring.io/spring-security/
http://www.dineshonjava.com/2013/02/spring-security-take-baby-step-to-secure.html#.Vjq3TZeqpCA
http://www.mkyong.com/tutorials/spring-security-tutorials/