Java Swing

This week I am working with Java GUIs. This will tie in with prototypes and applications that other people have built. While I my code does not need to fit nicely, or interact from a GUI point of view at all, it might be nice to take some time and look at the Swing aspect of Java.

I do teach Java, maybe learning something extra of Java won't hurt. That's the best thing about a PhD, I think: the ability to take the week and go through Java tutorials. Or any tutorials.

Synthetic Test Data Generation

This week I have mostly been working in the synthetic data generation test suite. The purpose of the data is to create RBAC infrastructures, extract only the user-permission assignments from them and mine back the original roles.

While I'm not entirely convinced of the usefulness of this (skewed roles, random roles represent real enterprises?), the research community seem to think it's useful. So the plan of my algorithm is as follows:

Inputs:

1. number of users
   
2. number of roles
   
3. number of permissions
   
4. average number of roles per user
   
5. standard deviation of roles per user
   
6. average number of permissions per role
   
7. standard deviation of permissions per role
   

Constructing roles to users and permissions to roles then extracting fundamental relationships should not be too difficult. The only issue is how real is our model. What kind of distribution could our model take? So to start with, the number of roles to users and permissions to roles are normally (Gaussian) distributed. (Most thing are normal right?) After the number of roles and permissions are picked for each user and role respectively, that number of roles and permissions are picked according to a normal distribution given the mean and std. That is, which permission and which role is picked at based on a Gaussian number generator.

I initially had some problems with the Gaussian distribution, requiring an inverse error function to transform randomly generated numbers into a normal distribution. But then I was directed to some C code that does magical stuff. I was also made aware that Java's normalised Gaussian number generator could easily be translated to a number of whatever mean and std I gave it, so that's making the coding process easier.

Alternative, permissions or roles could be assigned randomly to roles and users respectively, given a max number of permissions per role and roles per user. Either option is feasible since the actual distribution is unknown.

yFiles in Action - Visual Representation

I've been moving through the demos that are offered through the yFiles Package. The basic base demos get you started with a normal graph, inserting nodes and edges and labelling of the nodes and edges. Extensions of existing objects and fast reference of existing objects is also demonstrated. The random graph generator probably isn't too useful, but accessibility, definition and label of the graphs is definitely useful. I probably won't be extending any objects either.

To display the graphs, you need to specify the layout that you want. The module demo of is of a graph with twenty nodes with edges in different layout formats. For a quick visual understanding of what can be done, this demo is very informative. Incremental hierarchical and normal hierarchical formats seem to be the most appropriate format (surprise surprise, I'm creating a hierarchy). I originally thought tree but yFile trees appear to not recognise my structures as trees. I suppose their trees only want one parent and my nodes can have multiple parents. This is important, one of the problems of a previous research approach didn't address nodes with multiple parents. So it's best if we just don't have that constraint to begin with.

After choosing a layout, of the graph, you can output it quite easily using the IO handlers. The io demonstrations show reading in of gml files and outputting them out to images or placing them in a JPanel window. They can also be placed in html files. I don't think I need the extra functionality. It is also possible to create a dynamic graph that can be modified through a view. I also think that this is excessive for what I need to do. Very nifty because you can point and click nodes and objects and add edges ad hoc. But for my basic algorithm, I think creating a graph and showing it is sufficient.

So here are some visual representations of my very simple example.



This first picture shows our basic relationship, simple users to permissions.



This situation is an intermediate step with the addition of roles.



Finally, roles are merged. This is a very simple example.

SQL Server

I have recently received some data of SiteMinder Policies to manipulate. At the moment, it is just raw text dump that I have to wade through and extract some meaning. Trevor has given me his understanding of the conceptual objects within the files. I have will draw up the relationships with Visio and after more analysis, it has been decided that we will try to read in all the policy data and place it into a database. I have installed MS Sql server and created a server using Windows Authentication. I plan to read everything using Java. Tim mentioned that there may be some issues connecting to the database due to the authentication method. I am trying to use the SQLServerDataSource to connect. I think it assumes SQL Server Authentication as the norm. According to the Internet, Windows Authentication is based on Kerberos, and the only software I could find that assists in connection with was the The DataDirect Connect for JDBC SQL Server driver. It wants money. I’ve recently changed the Sql server to allow for SQL Server Authentication. After playing around with it with the normal SQL Server Authentication method with a user/password model, I have no problems logging in and updating my database. I just had to make sure the user I created had permissions to modify, drop etc.

The only issue with doing this is ensuring my tables are dropped at the end of every operation. On start up, I have to decrypt my files, load them into the database for queries. After I'm done, everything has to be removed and returned to its encrypted state.

yFiles

After extraction of the frequent patterns, we wish to graph them to find correlations between roles and permission sets. This can be done with basic data structures in any language but it would be nice to have some sort of a visual representation.

After looking at some options, we decided that yFiles offers some useful tools for representation and manipulation of graph objects. For our research, we wish to build hierarchical structures and perform some manipulations on them.

yWorks itself offers a free version of diagramming software (yEd) that is compatible with a number of graphing markup languages (graphML, xml based graph descriptions) as well as YGF, it's own graphing mark up language format. I could produce infrastructures in my code and parse them into a language that yWorks understands. However, yFiles offers classes that are compatible to yEd as well as additional graph algorithms, analysis and computation operations. The one that draws my fancy in particular is transitive closure. Shortest path might be useful for later manipulations, as a cost metric maybe?

The basic yFiles provides a subset of the available tools but for real development, you want the compete package. For usage of yFiles, Basic to Complete, the prices range from US$700 to $6000. For servers and site usage, it's just more, much much more. I personally don't have need for the source code. The package as a jar file is enough. And this is what I have. My industry sponsors have bought a couple of licenses for our use. I'm finding it quite interesting and fun right now.

Frequent pattern mining code

I wish to apply some frequent pattern mining techniques to my current area of security research. While Weka offers are large number of packages, for the large number of possible values in each transaction, it does not perform particularly well (or at all). It is not scalable to my data.

Also, for now, I only wish to extract frequent patterns and evaluate their use. Instead of implementing my own frequent pattern algorithm, I looked on the Internet for existing implementations. My first find was http://fimi.cs.helsinki.fi/, a repository of implementation from papers published in 2003/2004. The all performed different variations on pattern mining.

To narrow my search for something that was more directly aligned with my data type/implementation, Rao suggested I look at Han et al.'s Frequent Pattern Tree and that I look at their existing implementations. This approach is known as a very efficient way to identify candidate frequent patterns so it is expect that many implementations of this approach exists. It makes sense to use the most efficient implementation to do what I want and it makes sense to use someone else’s implementation and make it do what I want. This led me to Frequent Itemset Mining Template Library. However, I had difficulty compiling on my system.

Finally, I found another implementation based on Han et al.’s approach. This one was in C++, and required data in the form of all items per transaction per line. This I could do.

So I translated the data that I have into the format that I the FPTree implementation required. Each set of roles found and its support is given, sorted based on support. Next is working out what to do with it. I will talk to Rao on Wednesday see if he as any ideas. Maybe look at identification of the best roles and trying to convert into a hierarchy of some sort is required.

Weka

Weka is a Java program that contains data mining algorithms for data in arff (attribute-relation file format).

This was the main software used by a Machine Learning subject taught at honours and masters level at my university. This subject contains the theory and some practical aspects of many basic Machine learning and data mining algorithms. I've had a play around with Weka in unix and on windows. I prefer the unix environment because it's run like any other Java program.

For example, a command line argument to play with some association mining followed by the results would be
>> java weka.associations.Apriori -t weather.nominal.arff

Apriori
=======

Minimum support: 0.15 (2 instances)
Minimum metric : 0.9
Number of cycles performed: 17

Generated sets of large itemsets:

Size of set of large itemsets L(1): 12

Size of set of large itemsets L(2): 47

Size of set of large itemsets L(3): 39

Size of set of large itemsets L(4): 6

Best rules found:

1. humidity=normal windy=FALSE 4 ==> play=yes 4 conf:(1)
2. temperature=cool 4 ==> humidity=normal 4 conf:(1)
3. outlook=overcast 4 ==> play=yes 4 conf:(1)
4. temperature=cool play=yes 3 ==> humidity=normal 3 conf:(1)
5. outlook=rainy windy=FALSE 3 ==> play=yes 3 conf:(1)
6. outlook=rainy play=yes 3 ==> windy=FALSE 3 conf:(1)
7. outlook=sunny humidity=high 3 ==> play=no 3 conf:(1)
8. outlook=sunny play=no 3 ==> humidity=high 3 conf:(1)
9. temperature=cool windy=FALSE 2 ==> humidity=normal play=yes 2 conf:(1)
10. temperature=cool humidity=normal windy=FALSE 2 ==> play=yes 2 conf:(1)

Installation in Unix is fairly simple to do, making sure your CLASSPATH is set correctly to include the weka.jar.

I've also installed it onto Windows and had a play around with that. The products provided offer much more than what I really need. The Explorer, KnowledgeFlow and Experimenter look interesting but I never really had a play with it. I mostly used the SimpleCLI because I wanted to do some different basic mining on my data to see if it produced sensible results. This is pretty much gives the same results as when running from unix. Windows installation is fairly simple to do, there's a .exe file that installs everything for you. Just make sure you have Java 1.4/1.5 somewhere.

You can do all sorts of clever things with classification using Weka. You can filter attributes, cluster data, build trees, do some linear regression, bayes and so on. As long as you have suitable data or data that Weka was designed for, it will work.

My data was not quite built for Weka so I had some problems. Weka takes files in arff format where arff stands for attribute-relation file format. An example of the generic that is contained with the download is
@relation weather.symbolic

@attribute outlook {sunny, overcast, rainy}
@attribute temperature {hot, mild, cool}
@attribute humidity {high, normal}
@attribute windy {TRUE, FALSE}
@attribute play {yes, no}

@data
sunny,hot,high,FALSE,no
sunny,hot,high,TRUE,no
overcast,hot,high,FALSE,yes
rainy,mild,high,FALSE,yes
rainy,cool,normal,FALSE,yes
rainy,cool,normal,TRUE,no
overcast,cool,normal,TRUE,yes
sunny,mild,high,FALSE,no
sunny,cool,normal,FALSE,yes
rainy,mild,normal,FALSE,yes
sunny,mild,normal,TRUE,yes
overcast,mild,high,TRUE,yes
overcast,hot,normal,FALSE,yes
rainy,mild,high,TRUE,no

So you say what the relation is called, then you describe the attributes and after you've defined the attributes and the possible values, the transactions can be listed. The format is fairly simple and it is not too difficult to copy.

I tried to use it for my user-object permission assignment data to see if any of the mining algorithms could produce things that were interesting. The one that I was most interested in was frequent pattern mining that could be generated through association mining.

While fundamentally an access control matrix can be placed into the required format, the transactions produced would be very large. Arff file transactions are all the same length with each allowable attribute value defined. So in an access control matrix, either the users are attributes or permissions are attributes. Either way, the static transaction length would be enormous. Even with only a couple of transactions, Weka is unable to process the data. This was due to the long transaction length. Also associations rules in Weka do not accept numerical values. Which is fine, I just need another way to represent 0 and 1 (yes/no).

Under unix, the following error was produced:


>> java weka.associations.Apriori -t group.short.arff
Exception in thread "main" java.lang.OutOfMemoryError:
JVMXE006:OutOfMemoryError, stAllocArray for executeJava failed
at weka.associations.AprioriItemSet.mergeAllItemSets(Unknown Source)
at weka.associations.Apriori.findLargeItemSets(Unknown Source)
at weka.associations.Apriori.buildAssociations(Unknown Source)
at weka.associations.Apriori.main(Unknown Source)

The process is simply […killed] under Windows, even when I give it more VM.

It appears to be unfortunate for our data. Weka is implemented in Java and unable to process data sets with length attribute lists. It was hoped that Weka can process this arff file because it offers a suite of machine learning tools and had the potential to offer us more insight into what different mining techniques could find.

Although I do not need all the functionality of Weka, some supervisors suggested using a jprofiler in NetBeans IDE to have a look at what Weka is doing wrong and why it is being so crazy. Maybe I will, but since I only really need frequent mining for now, I might investigate alternative methods for extracting what I need.