[Editor’s note: Part of a continuing series about best practices for log file management]
There are a variety of forms of security when talking about computers, the Internet, and smart phones. With respect to log files, the security discussed here has less to do with access to the log files, and is more concerned with access to modifying the configuration of the log files. We’ll look at a few challenges which should be taken seriously and managed accordingly within any size of organization.
While earlier it was stated that log files are ‘intellectual property’, log files tend not to contain any information that is critically confidential because there is no personally identifiable information—though web data should be considered critical business asset. Should the log files of any given organization get in the hands of others not warranted those rights, there isn’t much harm that can be done.
For the most part, even if your log files ended up in the hands of your closest competitor, they would have no advantage—the most useful competitive information is already available through services like Compete. A competitor likely wouldn’t even know what to do with the log files; let alone try to harvest them for information that gives them any advantage in the market.
Best practices and policies
Really, this blog is about policies rather than security. Every organization should have policies in place for who is able to modify the structure of the log files for corporate web assets. Whether it is for the corporate web site, the intranet, the extranet, or other online assets, only a select set of personnel should be able to modify the log file structure and the data points contained within them.
On more than one occasion within our client base, changes which have impacted the data contained within the log files have been made without company-wide notification. As a result, the data can become extremely inaccurate if we continue with the log file analysis.
To complicate matters, many large web sites are spread across multiple servers. When a change is made to a log file, it is critical that the same change be made immediately to the other servers supporting the web site. Should those changes not be made, or be made differently than the first server, the data can then be inaccurate upon processing with most web analytics engines.
A few tips
A common best practice to add a new field to a log file is to add it to the end of the configuration string or log entry such that the new data points are the last in each log entry. If an addition is made in the middle of the string, half the log file entry ‘shifts’ and the data may be attributed to the wrong field given the log file configuration for the web analytics engine. If the new data points are added at the end, they will not impact the previous data configuration. They may not get picked up immediately by the log analysis engine, but at least they will not affect the data negatively.
In short, log files need both security practices and policies to protect them and the data they represent. A great starting point is minimizing the number of people that have access to the logs to help prevent unwanted modification. A record (or a ‘log’) should also be kept about changes made to the log files (which would include the change made, the date, the person that made the change, etc.).
These simple tips can help minimize damage in the event of an error and help to track the responsible parties when changes are made. Keep these in mind to save yourself hours of work, so you can get back to helping visitors and customers.
