New Feature: Activity Log (CSV)
Among the tasks surveillance administrators perform are exercising direct control over the quick-reaction teams during a security breach and analyzing the security response post factum. The latter is impossible without processing a lot of data collected from various sources, and Xeoma is capable of being one of them. In this article we’ll take a closer look at what Xeoma can keep logged and how this information can be extracted and utilized.
A common surveillance system works like this: there is a powerful central server with all the cameras connected to it – it does all the processing and archiving; there are security posts with client machines that connect to the central server to view live feeds and archives and keep the situation under control. If the server itself can monitor their activity, it will certainly simplify the administrator’s work.
|Read also: Event log embedded into Xeoma interface|
Enter Xeoma’s logs. One of them – activity log – keeps track of all users currently connected to the server and can be enabled via Main menu → Remote access → Users → Use the csv-file to record users’ actions. From now on, the directory you specified will contain the file log.csv. CSV is basically a spreadsheet or a table that can be viewed both by humans (via spreadsheet programs or simple notepad) and by software. The content looks like this:
On the surface – doesn’t look particularly informative. So, let’s learn to read it.
- ColumnA: this is a unique identifier for the session, its purpose is to let you easily distinguish between connections made from different machines under the same user.
Example: Line2 and Line3 show the same user (operatorA), but the IDs are different (66836424 vs 66836584) – these are two different people employing the same user credentials on two different machines. Cross-referencing that with Xeoma’s main log (…/Xeoma/Logs/
.log) will give you the IP addresses of the machines for both these people.
- ColumnB: username in Xeoma assigned upon their creation to this user.
- ColumnC: this is the name of the camera the user had maximized for the full screen (single camera view mode); the name is assigned in the “Universal camera” module, Source name parameter.
- ColumnD: the date for ColumnC.
- ColumnE: the time for ColumnC.
- ColumnF: the date that user minimized that camera’s window back (returned to multiple cameras view mode or exited in a different manner).
- ColumnG: time for ColumnF.
- ColumnH: this is the difference between ColumnE and ColumnG in milliseconds; it shows you exactly how much time the user spent checking that specific camera’s image in full screen.
Example: judging by Line7 and Line8, operatorA viewed the camera “Entrance2” for 9173ms (~ 9 sec.).
Now the seemingly confusing mess becomes a logical statement of facts, a data pack, that can be interpreted and analyzed, line-by-line. Statistics gathering software can use this data for e.g. annual analysis or optimization advice. Its practical applications are plentiful and we shall look at a couple of them.
An emergency occurred: someone managed to bypass the security using one of the entrances and made off with something valuable. The alarm was not set off upon the offender’s entry.
The guard on duty, tasked with controlling this particular entrance, is instantly brought under scrutiny. There are reasons to suspect that he was in cahoots with the perpetrator – this would explain why he neglected to sound the alarm in time. The administrator examines the activity log, checking the entries relating to the time of the emergency. The log indicates that at the time of the accident the guard was viewing several other cameras, one-by-one. The log also shows that this procedure was not unique: he made these “virtual rounds” every hour, following the protocol. The log could not have possibly been tempered with, since it is stored on the main server, the guard simply has no direct access to it. Apparently, the perpetrator either knew the exact time the entrance won’t be under direct surveillance or had a stroke of good luck. Thus, all suspicions are cleared.
The log’s help in this matter is twofold: an innocent man avoided being blamed for a crime he never committed; the administrators for this facility found a security breach in their system that can be mended by rearranging the timing for “virtual rounds” for every guard station, so that at any given time every single camera is observed by at least one guard.
The facility’s network indicates that one external connection has been made during the day.
This is reason enough to suspect a possible security breach. The administrator studies the activity log around the time of the connection. Session IDs (ColumnA) show that the same user viewed different sources at the same time using different machines. Now the administrator looks up this specific connection (by its time) in the main log to see if both connections were made from inside the local network or not. One of them is local (the guard), the other is external – a possible indication that unauthorized personnel gained remote access to the surveillance server. The main log gives the administrator the other machine’s public IP – it does not coincide with any of the known external supervisors.
At this point, the administrator is certain that this particular guard’s password has been compromised, willingly or on accident – this is not yet known. Thus, the first order of business is to change at least that password. Further down the line, a second layer of protection can be added by using SSL certificates and instructing the main server to accept only secure connections (the command is -sslconnection 1). As long as the actual certificates are unavailable to anyone other than the administrator (e.g. stored in the folder with limited permissions), only the authorized machines will be able to connect to the server.
The data stored in logs can serve as a guide to the system’s improvement and answer plenty of questions, as long as you have the desire (and time) to study it.
June, 6 2018