Security Awareness (SA004-10): System Log Files Transmission
A system or network log file is a file containing piece of vital information about the system or the network. These pieces of information are time-stamped recorded activities and events that had happened on, and to the system or network.
System or network logs contain very useful pieces of information to both users and attackers. Logs are useful to users when performing auditing, troubleshooting system or network problems/faults and also when carrying out forensic analysis, and are used to support internal investigations, establish baselines, identify operational trends and long-term problems.
To attackers, logs can be extremely useful to gather and piece together the target environment, especially when such logs contain publicly available pieces of information such as routable IP address, DNS entries and location information etc.
When there’s a fault on the network which can’t be immediately resolved, vendors supporting the platform often request logs file be sent to them. Why there is no problem in sending logs files to support vendors, however, this log file can be accidentally sent to the wrong person, or could be intercepted on transit or could be abused by someone working for the vendor. Therefore, it’s absolutely important that log files are protected at all times, in store or in transit.
The practice is usually that logs stored on one’s network is protected, but when in transit, fewer people remember to consider protecting log files, even before sending it to a legitimate supplier or vendor.
Here are a few tips on how to protect log files before sending it to a supplier or vendor:
• Sanitise all log files before sending it externally to a vendor or supplier. This means, replacing publicly available information with made-up information. For example,
o replace all public IP address with private addresses;
o replace fully qualified hostnames with random strings, and
o DNS server with a local copy of non-routable IP etc
• Anonymise log files. This means replacing user identifiable information in the log file, such as
o remove all sensitive user information from the log, such as usernames, password, hashed passwords, SNMP strings, etc
• Sanitised/anonymised log data must be encrypted (Use any method of encryption to ensure the file is properly protected. For example,
o use PGP (Pretty Good Privacy) if installed, or
o use Zip + authentication pass-phrase
• Obtain a hash of the ‘sanitised’ log being sent. This will ensure that when the supplier/vendor receives the log, they can ensure that it has not being tampered. Example,
o MD5 digest/hash, checksum or other mechanisms readily available to you.
• The encrypted log data should be sent via encrypted, or trustworthy channel, such as SFTP, PGP email, or VPN connection etc
o Where STFP is used, please ensure that the password is communicated to the vendor/supplier in a secure way.
System or network logs contain very useful pieces of information to both users and attackers. Logs are useful to users when performing auditing, troubleshooting system or network problems/faults and also when carrying out forensic analysis, and are used to support internal investigations, establish baselines, identify operational trends and long-term problems.
To attackers, logs can be extremely useful to gather and piece together the target environment, especially when such logs contain publicly available pieces of information such as routable IP address, DNS entries and location information etc.
When there’s a fault on the network which can’t be immediately resolved, vendors supporting the platform often request logs file be sent to them. Why there is no problem in sending logs files to support vendors, however, this log file can be accidentally sent to the wrong person, or could be intercepted on transit or could be abused by someone working for the vendor. Therefore, it’s absolutely important that log files are protected at all times, in store or in transit.
The practice is usually that logs stored on one’s network is protected, but when in transit, fewer people remember to consider protecting log files, even before sending it to a legitimate supplier or vendor.
Here are a few tips on how to protect log files before sending it to a supplier or vendor:
• Sanitise all log files before sending it externally to a vendor or supplier. This means, replacing publicly available information with made-up information. For example,
o replace all public IP address with private addresses;
o replace fully qualified hostnames with random strings, and
o DNS server with a local copy of non-routable IP etc
• Anonymise log files. This means replacing user identifiable information in the log file, such as
o remove all sensitive user information from the log, such as usernames, password, hashed passwords, SNMP strings, etc
• Sanitised/anonymised log data must be encrypted (Use any method of encryption to ensure the file is properly protected. For example,
o use PGP (Pretty Good Privacy) if installed, or
o use Zip + authentication pass-phrase
• Obtain a hash of the ‘sanitised’ log being sent. This will ensure that when the supplier/vendor receives the log, they can ensure that it has not being tampered. Example,
o MD5 digest/hash, checksum or other mechanisms readily available to you.
• The encrypted log data should be sent via encrypted, or trustworthy channel, such as SFTP, PGP email, or VPN connection etc
o Where STFP is used, please ensure that the password is communicated to the vendor/supplier in a secure way.
posted by Cyril at 8:58 PM
0 Comments:
Post a Comment
<< Home