chap9.tex

\chapter{Summary of Contributions and Future Work}

\section{Contributions}

In this thesis, we present a summarization system that allows applications to summarize information in their Aeolus audit trails, as well as mark events for later archiving or deletion. We also present a query system that makes it easier for applications to both use our summarization system and query the Aeolus audit trails in general.

Note that summarization presents information in a condensed form. If that information is what is needed to run discovery queries, running these queries over the SUMMARY table will provide better performance than having to fetch all the underlying events from the LOG.

\section{Future Work}

The are two main directions in which our system could be extended in the future.

The first is improving the expressive power and performance of the current system. An example of the former is that it might be useful to define a ``no-mark'' query just once and have it apply to every marking to rule out certain events from being marked. Note that this matches how we do things in Aeolus (where events recording modifications of the authority state are never marked). This approach could replace the current arguments to the \emph{mark} method described in section \ref{model:summary-objects}, or it could be used in conjuction with those arguments; the latter approach would allow the application to identify events to not mark in a way that is specific to a particular call of the \emph{mark} method.

An example of the possible performance improvement is to provide the ability for the application to have materialized views. For example, in the Mint application, it would be really useful if the application could define a view that would produce the signup information of all users (shown in table \ref{table:users-info}) whenever requested. The presence of such a view could greatly speed up later uses of that query.

The second direction to extend our system is to allow applications to handle archiving and deletion. Right now we only mark events but we do not archive or delete them. Ultimately, though, it will be necessary do support those functions. But again the application will have to be specific about what to do: some marked records might be deleted, some might be archived, and some might be archived and then deleted. A possible direction to providing archiving and deletion is to allow the application to define particular queries to do the delete or archive, e.g., there could be a query that deletes all base events for sessions for users who no longer use mint and where those sessions are older than a year, or a query that deletes all but the events that add and remove banks, and archives those events.

Note that if events are archived we might also like to allow them to be fetched. The idea is that the user might want to ``drill down'': they have obtained information from the summaries and have decided they need to see the specific events that led to that summary. This is another feature that such an arhiving and deletion system should include.

%The first is to give applications more power through the query system. It is unclear how much power exactly should be given to the application, however, it is clear that applications should be able to do more than just select events from the LOG and SUMMARY tables through their queries, for example,  This would be an improvement upon the current of the system because the application wont have to store this information in memory, rather it is stored in the database and can be access again in the future without being recomputed. Our system could benefit from future.

%The second possible way to extend our system is to investigate how archival and deletion sholud be carried out, and build an interface that allows applications to do so. Such an interface would perhaps provide some flexibility to the application, while still providing some working framework for the application to use. This interface would have to be clear about how it operates, lest the application misuses it and important information is lost. Such an interface might also include features that build on our work, such as allowing the application to specify sets of events, through queries, that should never be deleted or archived.