All, Thanks for the replies.
The short answer to why we made these changes instead of using markers, an extended logger, etc. is that we were looking to simply what a developer would need to do in order to log and audit security events. I and others have worked on a lot of projects in the past where logging wasn't done in the development phase due to time constraints and the need to get the functionality working in a timely manner. Going back after the fact and adding in the logging of security events in a large code base can also be quite expensive. So the main concepts around which we made our changes was to make it so that a developer could utilize a single function within a commonly used logging framework and also have a standardized means for security events to be logged in order to provide uniformity across a system. To sum up the process that we went through, we first explored the option of creating our own "extension" on top of Log4j that utilized an ExtendedLogger with a custom Security level and then a SecurityLogger class in which we implemented the single method idea in order to simplify and standardize the use of the security level. After this, we realized that it would make more sense for this to be included within the log4j2 code base as opposed to being provided as a layer on top of it. Essentially, we utilized the code from the ExtendedLogger to modify the areas inside the code base where other levels were defined and the functionality implemented. We then modified our SecurityLogger class to act in a similar manner to the EventLogger class that currently exists in the log4j code to provide another level of uniformity and familiarity for current users. Gary, as for your question about where the SECURITY level falls in the hierarchy, I've had some discussions with others and have had a fairly difficult time determining where exactly it would fit in. Currently we have it as being more specific than FATAL. I hope that helps explain what we have done a bit better and does not cause more confusion. Thanks, Bryan On Fri, Jan 8, 2016 at 3:14 PM, Gary Gregory <[email protected]> wrote: > Bryan, > > For a more concrete and low-level answer, there are two ways you can > contribute code: > > - Create a JIRA (https://issues.apache.org/jira/browse/log4j2/) and > attach your code as a diff file based on our Git master: > https://logging.apache.org/log4j/2.x/source-repository.html > - Do it the GitHub way from https://github.com/apache/logging-log4j2 > > 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 > -- Bryan Krol Software Engineer Technergetics, LLC [email protected] Phone: (315) 271-2096 Fax: (886) 307-4382
