Audit Trails and Security

May 16, 2006

Copyright 2006, R.James Holton. All rights reserved.

 

ESS’s Audit Trail

 

The Expense Submittal System maintains an audit trail of all import events while it is running.  These events are logged to the expense.log file.  Events include access tracking and file updates, as well as any event that may be useful in troubleshooting.  Expense.log contains detailed information on all expense transactions so it should be considered a sensitive document.

 

 

Log File Location

 

When ESS starts it opens expense.log, independent of any location input, and logs all important events.  While this ensures that if ESS is running that all events will be logged, it sometimes can be confusing to find and manage if you don't know where expense.log is located.  ESS opens expense.log in the following order:

 

1.      /var/ess

2.      ~/var/ess

3.      c:/ess

4.      ~

5.      Tomcat launch folder

 

If you want to change the location of the expense log, the best way is to create a location listed above with access of 777 and use that.

 

The default for Windows with the Appliance Edition is c:\windows\system32.  Adisoft recommend’s creating a c:\ess folder to store the log.

 

The default for Linux with the Appliance Edition is /home/{installer}/ESS-3.1.n/Jakarta-tomcat/bin.  Adisoft recommend’s creating a /var/ess folder to store the log.

 

Log Entry Description

Each expense.log entry begins with the time in Unix format and is followed by an entry code, which is followed by a detailed description. Below is a list of entry codes and what each code indocates. You can grep against these codes (e.g., grep -I "\[500\]" expense.log) to get a concise view of the log.

  1. [---] – Debug event. Contact support to have removed.
  2. [000] – Trace event.  Normal process that is being tracked in the event of troubleshooting.
  3. [001] – logging of SMTP conversation, ESS requestion
  4. [002] – logging of SMTP conversation, SMTP server response
  5. [005] – Start of the report submission process
  6. [006] – Start of the database submission (i.e., persisting report)
  7. [007] – End of the database submission process
  8. [200] – Indicates a successful completion of an important activity
  9. [220] – Login event - shows the email of who logged in, the IP from which they logged in, and the session ID.
  10. [221] – Logout event - user logout. show email and session ID
  11. [222] – Forced logout event. Shows the email of the person being logout out. If blank this shows the person had logged out.
  12. [224] – re-login event shows email, ip address and session ID
  13. [229] – Logs user to keep session active. Shows email.
  14. [240] – Password change - user's email
  15. [250] – Report register update (User’s xmlr file)
  16. [400] – Warning message. Indicates an item that is probably OK but could be related to a problem
  17. [500] – Generally indicates a problem.  There are a couple “false” 500’s currently.  The most prominent is when a new user logs in for the first time there will be a 500 event associated with not having xmlr and xmlu files.

Security

ESS handles security in several ways.  They are:

  1. ESS relies on file access security provided by the operating system.  Which every user starts the Application Server (e.g., Tomcat) needs access to the xmls, xmlu, xmlr, Web ess folder,Application ess-app folder and expense.log file.  Most other users can be excluded. The browser – server environment provides a natural degree of separation as the vast amount of users do not need direct access to ESS files.
  2. The security.xml file provides access control to ESS functions.  Currently, there are three privileged functions in ESS.  They are access to the audit module, ability to generate the ESS Javascript profiles, and ability to reset passwords.
  3. The USER and DEPART table defined relationships between users, enforcing an organizations approval processes.  In addition, users can be assigned limits to the size of a report that they can approve.  Users are verified against the USER table at time of login.
  4. Logins can be as either “application” or “host” dependant. With an application dependant login, ESS handles password verification.  With a host dependant login, ESS receives information from the host umbrella security systems which it uses to verify the user against the USER table.

Consult the “Administrator’s Installation Checklist” and the “Audit Menu and Functions” for more information on implementing a secure ESS.

 

###