- <section>
- <heading>Data processing.</heading>
- <para>The data processing has four tasks:</para>
- <itemize>
- <item>
- <para>Extracting data from e-mail and store it in the input-buffer. This can be done by a daemon that checks the e-mail<footnote>It would be logical to place an e-mail server like sendmail or postfix on the server. In many cases the monitored computer will be featuring a SMTP daemon. If a system is comprimised no evidence that comes through will be really trustworthy. By sending it to another machine all evidence that is available will have left the system the moment a hack takes place.</footnote> with a certain interval extracts the e-mails and leave the content in a file in the input buffer. This daemon has only rights to write to the directory it has to write to. <emph>We may as well have the email captured directly by a program with a "gnucomo: |/usr/local/bin/gnucomo-input" - like alias.</emph></para>
- </item>
- <item>
- <para>Detect files in the input buffer decrypt the content and verify the signature. Another daemon will see the log-files and starts checking if the origin is correct (by verifying the signature) and decrypting the content. The legible files will be processed by entering the data into the database.</para>
- </item>
- <item>
- <para>The database will accept the data and perform a certain number of checks as the data comes in. During the processing of the data abnormalities will be detected and entered into a notification table. The database system will also carry out more complex tasks on given moments in time and enter them as well in the notification table.</para>
- </item>
- <item>
- <para>The database system must be able to undertake action when high alerts are being entered into the database. This can be a couple of things to begin with: send an e-mail or SMS. In a later stage other technologies may be added as well. In this scheme we also make a possibility to escalate problems when no action is taken in a certain amount of time.</para>
- </item>
- </itemize>
- </section>
- <section>
- <heading>Web interface.</heading>
- <para>The web interface will used to interact with the user. The interface should be intuitive and easy to understand. More important warnings should directly draw attention. The user must be able to perform settings so that warnings can be rated differently than the original settings. </para>
- <para>The interface will do the following things:</para>
- <itemize>
- <item>
- <para>Show a list of warnings that are currently open.</para>
- </item>
- <item>
- <para>It must be possible to sort the list on all the fields shown.</para>
- </item>
- <item>
- <para>Deliver detailed information (logbook entries) upon request that have led to the warning. </para>
- </item>
- <item>
- <para>Undertake certain actions like sending <reference href="mailto:abuse@internet-provider.net">abuse@internet-provider.net</reference> e-mails with information.</para>
- </item>
- <item>
- <para>Monitor actions on outstanding issues. </para>
- </item>
- </itemize>
- <para/>
- </section>
+<section>
+ <heading>Data processing.</heading>
+
+<para>The data processing has four tasks:</para>
+<itemize>
+ <item>
+ Extracting data from e-mail and store it in the input-buffer.
+ This can be done by a daemon that checks the e-mail<footnote>It would be logical
+ to place an e-mail server like sendmail or postfix on the server.
+ In many cases the monitored computer will be featuring a SMTP daemon.
+ If a system is comprimised no evidence that comes through will be really
+ trustworthy. By sending it to another machine all evidence that is
+ available will have left the system the moment a hack takes place.</footnote>
+ with a certain interval extracts the e-mails and leave the content
+ in a file in the input buffer. This daemon has only rights to write
+ to the directory it has to write to. <emph>We may as well have the
+ email captured directly by a program with a
+ "gnucomo: |/usr/local/bin/gnucomo-input" - like alias.</emph>
+ </item>
+ <item>
+ Detect files in the input buffer decrypt the content and verify the signature.
+ Another daemon will see the log-files and starts checking if the origin is
+ correct (by verifying the signature) and decrypting the content.
+ The legible files will be processed by entering the data into the database.
+ </item>
+ <item>
+ The database will accept the data and perform a certain number of
+ checks as the data comes in. During the processing of the data
+ abnormalities will be detected and entered into a notification table.
+ The database system will also carry out more complex tasks on given
+ moments in time and enter them as well in the notification table.
+ </item>
+ <item>
+ The database system must be able to undertake action when high
+ alerts are being entered into the database.
+ This can be a couple of things to begin with:
+ send an e-mail or SMS. In a later stage other technologies may be added as well.
+ In this scheme we also make a possibility to escalate problems when no
+ action is taken in a certain amount of time.
+ </item>
+</itemize>
+</section>
+
+<section>
+ <heading>Web interface.</heading>
+
+<para>
+The web interface will used to interact with the user.
+The interface should be intuitive and easy to understand.
+More important warnings should directly draw attention.
+The user must be able to perform settings so that warnings
+can be rated differently than the original settings.
+</para>
+<para>
+The interface will do the following things:
+</para>
+<itemize>
+ <item>
+ Show a list of warnings that are currently open.
+ </item>
+ <item>
+ It must be possible to sort the list on all the fields shown.
+ </item>
+ <item>
+ Deliver detailed information (logbook entries) upon request that have led to the warning.
+ </item>
+ <item>
+ Undertake certain actions like sending
+ <reference href="mailto:abuse@internet-provider.net">abuse@internet-provider.net</reference>
+ e-mails with information.
+ </item>
+ <item>
+ Monitor actions on outstanding issues.
+ </item>
+</itemize>
+<para/>
+</section>