[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536790#comment-17536790
]
Matt Sicker commented on LOG4J2-2665:
-
I'm thinking that a message id could be an arbitrary string that acts as a
dynamic equivalent to defining audit events. Though now that I re-read this
more, this seems more relevant to the builder DSL for map messages or a fluent
message builder API in general (see LOG4J2-3344).
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535838#comment-17535838
]
Ralph Goers commented on LOG4J2-2665:
-
I am not sure why this is still open. Matt, as for the sid field, can you
explain how a policy statement id relates to a message being logged?
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535136#comment-17535136
]
Matt Sicker commented on LOG4J2-2665:
-
I noticed that this concept is similar to the "Sid" field in AWS IAM policies.
Basically, some sort of description or identifier that's primarily used for
human consumption but can also double as an id.
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894939#comment-16894939
]
Ralph Goers commented on LOG4J2-2665:
-
I should add that log4j-audit does something sort of like what you are looking
for. With it you create a catalog of events you want audited. They are stored
in git in JSON format. When the build runs a Maven plugin generates the audit
events as interfaces and then the application coder uses those interfaces in
their application when logging. The event catalog is meant to be queried and
provides a service that can retrieve the event definitions. But this only works
with the events defined in the catalog, not arbitrary log messages.
You could do something similar by requiring the engineers to add an annotation
to the class with the descriptions in them, but unfortunately referencing them
from the logging calls would be difficult unless the id is included in the
annotation and used in the logging call or the text is copied to both places -
which is very error prone.
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894921#comment-16894921
]
Ralph Goers commented on LOG4J2-2665:
-
You can already do part of this.
public void info(Message msg) does exactly the same thing. Just create a
DescriptionMessageBuilder class and use it like:
{code:java}
logger.info(DescriptionMessageBuilder.withFormat("{} was able to
login").withParameter(userid).withDescription("abcd));{code}
What you won't be able to do is generate the descriptionId at compile time or
verify it is a valid id at compile time. But the DescriptionMessage could
certainly format the output the way you are asking.
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894915#comment-16894915
]
Joubin Jabbari commented on LOG4J2-2665:
Exactly the last part you said. During compile time, a catalog of all log
events with their description is created.
The idea is that when an incident responder sees a specific log like:
{code:java}
c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
{code}
They would be able to reference the said catalog and get some awareness of the
reason it was logged.
{code:java}
c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
every user logs in
{code}
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894912#comment-16894912
]
Ralph Goers commented on LOG4J2-2665:
-
How will what you are proposing help? I still don't understand what you are
trying to achieve. In the log event example I showed the logging call would
have been logger.info("Subscriber Id: {}", id); If it had been "Subscriber id:
{}, description={}", id, description) what makes you think the description
would be any better? You are also saying Log4j is somehow supposed to match the
description text to some id. From where? You could try using LocalizedMessage
to get the messages from a ResourceBundle but it doesn't sound like that is
what you want either.
In short, I still don't understand your use case, what you expect developers to
do, and how you expect Log4j to work?
But if you want to create a DescribedMessage class that accepts a description
and outputs it as "description id: rest of formatted message" you can easily do
that now.
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894908#comment-16894908
]
Joubin Jabbari commented on LOG4J2-2665:
[~rgoers], I think this only solves non-unique events to the application. Where
this breaks down is in very large organizations, or even organizations where
the software wasn't written in-house. To be honest with you, reading that log
message proves my point.
I didn't read the manual as you can't expect Incident Responders to read
manuals of hundreds of logging libraries their organization could use. So here
is what I can take from that log message.
At some time, some http call was made with a given request it, given a session
id that corresponded to the a given user from some IP address and it had some
account. But I don't know why that was even logged. Is it important that they
made a request? Why INFO and not DEBUG? Honestly, to a responder, that log
message is more noise than it is helpful.
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894896#comment-16894896
]
Joubin Jabbari commented on LOG4J2-2665:
[~rgoers]:
Half of the problem why you need to log. Your logs need to be understood by
more than just the developers that wrote the logs.
[~ggregory]: To be totally honest, hash is just an example. I think markers,
UUIDs, or even partial hashes will all be equally useful.
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894872#comment-16894872
]
Gary Gregory commented on LOG4J2-2665:
--
Why not use markers instead of a hash?
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LOG4J2-2665) Incident Response Improvement for Log4J
[
https://issues.apache.org/jira/browse/LOG4J2-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894855#comment-16894855
]
Ralph Goers commented on LOG4J2-2665:
-
Logging something to a file only solves half of what problem? Your problem
description is lacking in what you are trying to achieve. I am not sure it
cannot already be achieved by using a custom Message implementation.
Furthermore, your example have me wondering if you shouldn't be looking at
[log4j-audit|[http://logging.apache.org/log4j-audit/latest/]]
> Incident Response Improvement for Log4J
> ---
>
> Key: LOG4J2-2665
> URL: https://issues.apache.org/jira/browse/LOG4J2-2665
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.12.0
>Reporter: Joubin Jabbari
>Priority: Major
>
> Issue:
> Logging something to a file only solves half of the problem. The log needs to
> readable and distinguishable by auditors and responders.
> This is a proposal to add a optional feature for the instantiation and
> compile process of the logger.
>
> # Allow for a description parameter for each log statement.
> # When the description is filled out, log events that correspond to that
> description are given a hash number that match the hash of the description
> # The descriptions of said log are extracted and paired with their hash into
> a "log description file" during the compile process
> Example:
> Previous Logging Method
> {code:java}
> logger.info(user.id + " was able to login")
> {code}
> Proposed change
> {code:java}
> logger.info(user.id + " was able to login", description="This log event
> appears right after every user logs in"){code}
> Log File example
> Previous:
> {code:java}
> user132 was able to login
> {code}
> Proposed:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: user132 was able to login
> {code}
> Proposed log file description file generated during compile time:
> {code:java}
> c58868be25f925102364ba7cf15b4fbcca5d3f11: This log event appears right after
> every user logs in{code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
