christian.heinrich at owasp.org
Wed Aug 5 21:19:52 EDT 2009
In relation to network packet capture statement I would like to quote your
recent Blog Post at
"*Afterwards, Kris from Heartland made a few one comments on DLP: they use
it for discovery and data auditing, not for data leak prevention (which is
definitely very reasonable). Another interesting theme (brought up by Ed)
was not just awareness of what is going on your network (which is hard), but
also on all the supplier networks that connect to it. This is a curious mix
of technical security and legal, contractual stuff.*"
I disagree with implementing DLP only (which is simply a subset of network
packet capture) but it does demonstrate that there is greater value in (at
least some) network packet capture over host generated logs.
On Fri, Jun 19, 2009 at 4:21 PM, Christian Heinrich <
christian.heinrich at owasp.org> wrote:
> I disagree that OWASP should be providing specific advice on
> Web/Application Log (unless it is high level app development guidance on
> integrating with Windows Event Log/syslog) as the PCI SSC will attempt to
> spin that this OWASP Project was the cause of their next breach. Hence, the
> agenda behind PCI SSC specifying "vague", i.e. open for their
> interpretation/spin, requirement for logging.
> The slides which you cited (and I wish to acknowledge you disclosing your
> conflict of interest) did not consider the business case "over time" of
> building or purchasing a log management solution and in my experience
> building a log management solution is *cheaper*, including to "support" and
> it removes the residual risk of the vendor selling due to VC demands.
> In addition, I have seen a number of business cases based on the illusion
> that merchant's has no time to review logs and once this is measured the
> business case is rejected.
> While the PCI SSC claims PCI DSS to represent "good practice", it is
> medoric at best considering their web application testing requirement is the
> OWASP Top Ten, CISA, CISM and/or CISSP qualitifications for PA-QSA, etc.
> Please don't refer to network packet capture as "absurd for many, many
> years." as
> http://chuvakin.blogspot.com/2007/04/on-packet-logging-and-ehhh-log-logging.htmlclearly shows that you had no knowledge of this until I informed you of this
> two years ago (not for "many, many years" as you stated).
> On Fri, Jun 12, 2009 at 8:07 AM, Anton Chuvakin <anton at chuvakin.org>wrote:
>> Just wanted to offer a few comments about the logging topic, hopefully
>> useful for the emerging OWASP PCI guidance.
>> >> I would agree with you mostly here, in my experience the SIEM vendors
>> >> far short of their marketing. For medium sized enterprises you're
>> >> off with a custom solution, integrating the best products that fit your
>> >> needs.
>> I'd not sign my name under such recommendation for "custom solutions",
>> for sure. Please refer to slide #10 of
>> to know why. In one word, ongoing support of such custom tools killed
>> 100.00% of such projects that I've seen over the years (and no, I
>> don't sell log mgt tools [anymore])
>> >> applications. You don't want to accept the logging application
>> defaults, or
>> >> the vendors recommendations without detailed a review understanding
>> what are
>> >> your ricks and what are the compliance issues.
>> So, if we'd like to add application logging recommendation to this
>> OWASP guide to PCI, we definitely should. How about this: we define a
>> list of apps (starting from web servers, to top app servers, to
>> [maybe] databases) and define a list of things to log in them - with
>> the focus on PCI DSS. Sounds like fun!
>> > It is in the best of interest of the merchant to accept the default PCI
>> > reporting provided by the SIEM vendor in order to transfer their
>> > and duty of care by arguing that the SIEM vendor was the Subject Matter
>> > Expert in the event of a breach.
>> This worries me. Apart from never being observed in reality combined
>> with a high-likelihood of failure if made, such claim pretty much
>> kills ANY "best practices" / "good security guidance" effort,
>> including this one. Think about it: "OWASP PCI project guidance MADE
>> ME fail my audit; let's sue the bastards" :-)
>> >> My recommendation would be to engineer a solution based on directing
>> >> Windows Event Log to multiple syslog servers which then normalize this
>> >> into a DB as people then gain experience with logging rather then
>> >> trusting the claims of the SIEM vendor.
>> This is nice, but completely forgets that many app log entries are >
>> 1500bytes in size and thus will cause "syslog trouble" (tm); it also
>> ignores the fact that "database log/audit trail"->syslog is hard and
>> there are no tools for it.
>> >> I would also like to highlight that there is greater value in network
>> >> packet capture over syslog, Windows Event Log and custom Application
>> >> Logging.
>> Sorry, but I have not heard anything that absurd for many, many years.
>> People always complain that logging is "too much data" but packet cap
>> is probably 100x the log volume. Such a recommendation should never be
>> made to a wide audience, only specific narrow niches (DoD, etc)
>> Anton Chuvakin, Ph.D
>> Owasp-pci-project mailing list
>> Owasp-pci-project at lists.owasp.org
> Christian Heinrich - http://sn.im/cmlh_linkedin_profile
> OWASP "Google Hacking" Project Lead - http://sn.im/owasp_google_hacking
> Speaking Schedule at http://sn.im/cmlh_speaking_schedule
Christian Heinrich - http://sn.im/cmlh_linkedin_profile
OWASP "Google Hacking" Project Lead - http://sn.im/owasp_google_hacking
Speaking Schedule at http://sn.im/cmlh_speaking_schedule
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-pci-project