Tag Archives: data
Effective database activity monitoring (Page 1 of 2)
There are a number of reasons for organisations to deploy Database Activity Monitoring or DAM solutions, which can range anywhere from compliance to cover overall security.
DAM is a data centre technology, which monitors how the data that is stored in core databases and file servers is being accessed; it works on analyzing access behaviour to detect data breaches, if any; and takes action accordingly to mitigate them.
Various rules and regulations, compliance laws, etc also are increasingly forcing organisations to tighten their control over sensitive data they store, and have a verifiable audit trail that can be signed off, if required, by the appropriate organisational executives.
Database Activity Monitoring Architecture
Different DAM vendors have different ways of tracking activities in a database and therefore implementation of architecture is also slightly different.
A DAM with single appliance or single server architecture provides 1-to-1 mapping of a database server with a monitoring appliance; thus it acts both as a sensor and a collector of appropriate data. DAM with this configuration is good for a small database; however, for larger databases it might not be enough effective. Then there is DAM with 2-tier architecture, consisting of a centralised management server; this server collects information from a set of remote sensors or collection points. With this architecture there is a better degree of system scalability.
DAM with hierarchical architecture builds further onto the 2-tier architecture; this system is best suited for larger organizations; these DAMs are capable of supporting a larger number of sensors and collectors, distributed across a large enterprise.
Advanced Database Activity Monitoring Techniques
The process through which all SQL traffic to a database is monitored is called Network monitoring. Network monitoring allows monitoring multiple databases simultaneously; all the commands that are sent across to databases under scrutiny, are kept track of. The activities of users that are logged directly into the server via a local console are not recorded. Performance of a database is not affected by network monitoring, as no overhead is placed over the database directly.
In remote monitoring, a SQL collector is placed on the database with administrative privileges; the native database auditing is also enabled. The collector aggregates all activity collected by the auditing tools. This type of monitoring imposes an overhead on the database as logging is enabled on the database server, causing it to work more. The advantage of remote monitoring is that all database activities are collected, including that of a user who is logged directly into the server.
One can install local agents on each database that is being monitored, but it is not necessary that they would be successful in detecting all database activity; it would depend on how these agents have been configured, and how much closer to the database they are allowed to sit.
SerialSniffer
Developers need exact information and are often forced to get access to serial ports for testing purpose.
The typical user of SerialSniffer is a software engineer. Most commonly an external device is connected to a PC, which is running a special application using a serial port. The external device may be: a sensor, a slide projector, a printer, a barcode scanner, … The serial connection has to be “ripped” and SerialSniffer is mounted in between the serial link. SerialSniffer will provide all data from one side of the connection to the other and vice versa, log all the data and, if applicable, manipulate them.
SerialSniffer
is a windows shareware to visualize data, which are exchanged over the serial ports (i.e. RS232 or RS422).
SerialSniffer gives you the possibility
– to have a deep view inside the data. The data stream, which is exchange on the serial ports, is visualized by SerialSniffer. You also can determine which data comes from which port.
– to log the data stream
– to tunnel the serial port through the network
– to exchange dedicated data parts from the data stream
– to search for seldom data
– to open a terminal dialog
– to use symbols instead of raw data
SerialSniffer is very easy to use
Simply choose the type of connection (serial, network or virtual serial port), the parameters (i.e. baud rate) and open the connection.
Not only the standard baud rates (like 9600 baud) but also user defined baud rates can be used. It is also possible to translate between different baud rates, as both comports can be configured independently.
Comport names up to ‘Com256:’ are supported to use SerialSniffer on systems with a lot of serial ports (provided by additional adapters, IRDA, Bluetooth etc).
The complete configuration will be stored automatically on closing the application. The user can also store it in customized files to re-load it for recurrently tasks.
Practical example
Test of a complex system: a test specification exists; SerialSniffer logs all the data to a file, which is attached to the test protocol. But how to test, the system deals with errors on the serial link? If the worst comes to the worst, the system will crash. To test this, SerialSniffer gets a set of rules, which data is to be manipulated. I.e. some datasets may be shortened, some may contain additional data or the checksums are changed. In most cases, it is not allowed to integrate the changes to the device under test, because you will not test the original system anymore. Using SerialSniffer, you are no longer forced to do so.
Practical example
Once, we had the mission to develop a trip recorder for a ferryboat. The main computer of the ship dumps all the data on a serial port without a return line (one way street for the data). During the development, we were not able to travel with the ship all day long. So we recorded the data with the SerialRecorder of SerialSniffer (similar to a traditional tape) and did a playback as often as needed.
Effective database activity monitoring (Page 1 of 2)
There are a number of reasons for organisations to deploy Database Activity Monitoring or DAM solutions, which can range anywhere from compliance to cover overall security.
DAM is a data centre technology, which monitors how the data that is stored in core databases and file servers is being accessed; it works on analyzing access behaviour to detect data breaches, if any; and takes action accordingly to mitigate them.
Various rules and regulations, compliance laws, etc also are increasingly forcing organisations to tighten their control over sensitive data they store, and have a verifiable audit trail that can be signed off, if required, by the appropriate organisational executives.
Database Activity Monitoring Architecture
Different DAM vendors have different ways of tracking activities in a database and therefore implementation of architecture is also slightly different.
A DAM with single appliance or single server architecture provides 1-to-1 mapping of a database server with a monitoring appliance; thus it acts both as a sensor and a collector of appropriate data. DAM with this configuration is good for a small database; however, for larger databases it might not be enough effective. Then there is DAM with 2-tier architecture, consisting of a centralised management server; this server collects information from a set of remote sensors or collection points. With this architecture there is a better degree of system scalability.
DAM with hierarchical architecture builds further onto the 2-tier architecture; this system is best suited for larger organizations; these DAMs are capable of supporting a larger number of sensors and collectors, distributed across a large enterprise.
Advanced Database Activity Monitoring Techniques
The process through which all SQL traffic to a database is monitored is called Network monitoring. Network monitoring allows monitoring multiple databases simultaneously; all the commands that are sent across to databases under scrutiny, are kept track of. The activities of users that are logged directly into the server via a local console are not recorded. Performance of a database is not affected by network monitoring, as no overhead is placed over the database directly.
In remote monitoring, a SQL collector is placed on the database with administrative privileges; the native database auditing is also enabled. The collector aggregates all activity collected by the auditing tools. This type of monitoring imposes an overhead on the database as logging is enabled on the database server, causing it to work more. The advantage of remote monitoring is that all database activities are collected, including that of a user who is logged directly into the server.
One can install local agents on each database that is being monitored, but it is not necessary that they would be successful in detecting all database activity; it would depend on how these agents have been configured, and how much closer to the database they are allowed to sit.