Hello Bryan, Thank you for sharing your documentation.
I'll get right in the meat of it: "Problem 1: currently, many applications use the standard provided logging levels from frameworks such as Apache Log4j to provide basic logging functionality for their application. However, by using the standard provided levels, there is no way to easily distinguish security related events from the other events that are being logged for the application (e.g., Debug, Warnings, etc.)." This is exactly what "markers" are designed to address. Please see https://logging.apache.org/log4j/2.x/manual/markers.html Since you document implementing a custom "SECURITY" level, I have to say that this feels quite wrong to me for what amounts to a cross-cutting concern. Log4j does have a nice facility for defining custom levels though, which I guess have used in this case, or did you do it a different way? But how does SECURITY relate to other levels? Is it more or less detailed than DEBUG for example? It just does not fit in for me. As a marker on the other hand, it fits perfectly, and you can have more than one, and they can be hierarchical to boot! Without extending Log4j with custom levels! Can we talk about that first before we get deeper in with events? Gary On Fri, Jan 8, 2016 at 8:13 AM, Bryan Krol <[email protected]> wrote: > Hello all, > > As part of some other work I have been doing, our team has decided that it > would be worth extending the Log4j2 library in such a way as to better > support logging of security events. We also thought what we did would be > of interest to the larger Apache community, mostly because the need for > application-level security auditing is growing to help mitigate the > increase of application security incidents. In order to facilitate better > auditing practices, developers now have a need to include better security > logging practices in the development process. Application logs provide > valuable data for: > > - > > Identifying security threats > - > > Monitoring policy violations > - > > Providing details about problems and unusual conditions > - > > Contributing application-specific data for auditing which is lacking > in other sources > - > > Helping defend against vulnerability identification and exploitation > through attack detection. > > I have attached a document that more thoroughly explains what we have > done and what "problems" we were looking to solve with our changes. > I am looking for some guidance on how I should go about submitting these > changes back to the Apache Log4j 2.x team for inclusion in the code base. I > have implemented both the functionality and the appropriate JUnit code for > testing of the additions. > > If anyone could respond with some information to help, I would greatly > appreciate it. > > Thank you, > > -- > Bryan Krol > Software Engineer > Technergetics, LLC > [email protected] > Phone: (315) 271-2096 > Fax: (886) 307-4382 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
