Are Web Logs Required?

[nerdboy70]

We work with Level 4 Merchants that use Google Analytics (embeded site stats, not log parsing). Can web logging in Apache/IIS be disabled altogethor and still comply with the logging requirements in PCI-DSS 1.2? All system logs are centrally logged, archived, and filtered for vulnerabilities, but web site logs are not being treated the same way.

Thanks for the advise...

[lyalc]

If those web logs will help determine 'who did what and when' in the event a compromise occurs, then no, you can't disable them, and must keep and monitor them for indications of suspicious activity.

lyalc

[nerdboy70]

OK, I generally agree with you here, but I am going to play devils advocate a bit to make sure we hit the mark.

1. What would our monitoring of the web logs tell us? What would we look for?

2. We use WAF (Imperva), HIDS (tripwire), NIDS (Snort), DDOS Protection Appliances, and of course the ole trusty Cisco ASAs in front of the webservers... Is there going to be useful info in the web logs that wont be represented in one or more of the other systems?

3. Can you site any high volume (high number of web hits) web sites that actually centrally log HTTP hits for purposes of PCI-DSS compliance. We have been through approximately 20 Level 1/2 QSA audits and nobody has asked us about web log analysis...

[jbhall56]

The more information you have, the more likely it is that you will see an attack and be able to act on the attack. In this case, we are talking about log data and the correlation of that data. That is what those centralized log analysis tools do. They correlate the log data from your application firewall(s), network firewall(s), router(s), load balancer(s), switch(es), server(s) and any other devices involved. Those correlation engines operate the best when they have as much data from as many devices to analyze as possible.

Where I have seen this come into play is instances where one or all of the firewalls indicate that an attack has been blocked from a particular IP address only to also see that same IP address having a active connection with one of the servers in the DMZ. That is a situation that should generate an alert and be further investigated. Nine times out of ten, it is an attacker that is compromising your server(s). Without the data analysis, you would only know about the compromise after the data has left the server(s).

[nerdboy70]

We definately utilize centralized logging and coorelation tools for all the security components and host OSs, but we absolutely don't log positives (things that are allowed), and an HTTP hit on an IIS/Apache server on port 80/443 is absolutely whitelisted/allowed traffic.

Just the act of me pulling up this page on http://forum.paymentsecuritypros.com/ would generate 30-50 web log entries for activity that is absolutely allowed/expected/inspected. Where is the value in that data from a forensics perspective?

[lyalc]

PCI DSS requires successful and denied activities/attempts to be logged (10.2.1, 10.2.4, 10.3.4)
I would expect that the HTTP '2xx' and '3xx' events would be logged, along with 4xx and 5xx events.

Usually web logs show the request, time, date and data volume sent and received.
I have seen where a 'valid' login to a site accompanied by 'large' responses to requests showed which session (date, time, source IP) was involved and correlated to the amount of compromised data.
That helped a lot, forensically.

lyalc

[adam.ely]

We definately utilize centralized logging and coorelation tools for all the security components and host OSs, but we absolutely don't log positives (things that are allowed), and an HTTP hit on an IIS/Apache server on port 80/443 is absolutely whitelisted/allowed traffic.

Just the act of me pulling up this page on http://forum.paymentsecuritypros.com/ would generate 30-50 web log entries for activity that is absolutely allowed/expected/inspected. Where is the value in that data from a forensics perspective?


During incident response/forensics I have gone back to weblogs to find out what slipped by the WAF/NIDS/HIDS. 0-day exploits or simply deficiencies in the WAF/NIDS/HIDS (either configuration, product failure, or product flaw) have been to blame in most cases. In these, without the web logs we would not have been able to determine what occurred.

I have worked with two separate PCI assessors that have actually asked for the weblogs, all depends on whom you work with. My recommendation is to log whatever you can and whatever makes sense for your environment, put a reasonable retention policy around it, and make sure you have other controls/audit trails in place if a single one is not in place or fails to do the job.