Re: [openc2-lang] Debugging option

Agreed!

So, if we are focused on increased levels of debugging information in responses (with the requirement that production deployments ignore the setting from the Producer), then we might be getting closer to a proposal. Toby asked if this was a persistent setting, or something that only affects the given command. My leaning would be that is is NOT persistent (since I hate state) and that it affects the single command and all subsequent responses.

As to a tactical suggestion, perhaps there is a new "args" key that we add at the top-level, call it something like "debug_level" and have its value be an Integer. Anything 0 (or less than 0) would indicate default response information (as when it is not sent at all). Levels >0 would increase the debugging info in the response (or not) depending on how the particular Producer chooses (or not) to include more info... with the caveat that Production deployments will silently ignore this field.

First proposal. Go!

Cheers,

-Brian

On Tue, Jan 14, 2020 at 1:24 PM duncan sfractal.com <duncan@sfractal.com> wrote:

My main issue is for production I want the persistent option to never return any information on error. It’s amazing how easy it makes it for hackers if you have helpful error responses. But for plugfest debugging, returning info is helpful so I assume everyone will be doing some level and they will probably all be incompatible so we should think about harmonization - particularly prior to plugfest so we at least understand hiccups.

iPhone, iTypo, iApologize

From: Considine, Toby <Toby.Considine@unc.edu>
Sent: Wednesday, January 15, 2020 4:19:03 AM
To: Brian Berliner <brian.berliner@broadcom.com>; duncan sfractal.com <duncan@sfractal.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: RE: [openc2-lang] Debugging option

Do you see the persistence of the parameter to be the length of an individual communication or something longer?

Would detailed logging of a firewall request, for example, log the individual request, or would it notify the requester of future firewall changes. Alternately, if port 17 (“Quote of the Day”) is blocked is it the intent to log all attempts to use port 17? Alternately, if port 17 is unblocked, do you want to see all use of port 17 logged?

Alternately, does every command merely have a DBG switch, and when it is set, more info is returned?

If the command is for an SBoM request, does it include, say, the CPU time spent gathering the information? Does Debug simply mean tell me whatever you have, but the actual content of the response is not standardized?

It would be good to have standards, but I think we need to go a little deeper on what sort of response is being imagined here.

tc

From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> On Behalf Of Brian Berliner
Sent: Monday, January 13, 2020 7:10 PM
To: duncan sfractal.com <duncan@sfractal.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Debugging option

Hu Duncan,

Agreed!

It would be great if the LS had a standard way to indicate the verbosity of the response, which may or may not include debugging information. It's the kind of thing that has been hard to standardize, I think, as everyone has many opinions about how to do it and they are all often "right enough". So, I don't know if there are good examples for us to copy.

In Java, we use logging levels to indicate how verbose we want our logging to be. They are most typically "ERROR", "WARN", "INFO", "DEBUG", and "TRACE". Logging is not the same as API response verbosity or debugging, but you could imagine that verboseness can have levels too. We see this in many linux command-line apps which have a default verbose level, but accept a "-v" arg for making the output verbose, as well as a "-vv" for "even more verbose" and even a "-vvv" for "really, really verbose, like a TRACE".

I think you wanted to focus on "debugging" as opposed to "verboseness", and that's fine. I'm just pointing out that we'd want to allow for levels of debugging info as opposed to a boolean on/off setting... Numbers could be perfectly fine for that (which is essentially what the textual ones described above turn into, of course)...

Cheers,

-Brian

On Mon, Jan 13, 2020 at 3:48 PM duncan sfractal.com <duncan@sfractal.com> wrote:

Preparing for the plugfest I noticed https://github.com/bberliner/openc2-json-schema/blob/master/src/test/resources/commands/good/query_features_extension_args_number.json has an extension arg for debugging. I think we should have a standard debugging parameter in args. As a security geek I think “production” interfaces should provide as little info as possible ie no need to assist hackers -but as a developer writing/debugging I find the extra info on error conditions is quite helpful. So the answer to my dual personality is a debugging option to use in development but ignore in production. So I propose we add this argument to the language spec.

iPhone, iTypo, iApologize

openc2-lang message