Discussion/Proposal: new requirement for "log inventory"

[elarlang]

trafficstars

We should have for documentation/architecture requirement - like "log inventory", to (sub)category V1.7

Problem to solve: application owner does not know, what kind of logs application and/or it's components produces. Something may be "out of monitoring". Something, like accessible "temporary" debug log may cause sensitive information leakage etc. We have separate requirements for those problems, but pre-condition requirement should be: you know, what kind of logs you have.

Question to solve for me: how to set up the scope for testing logs. For a web application it's obvious, that web server and web application logs are in scope. Database engine logs should be there. Should this or separate requirement give some list of logs?

[jmanico]

This sounds like a reasonable level 2 architectural level requirement

[elarlang]

Any update on this? We are running into the same problem where we need to rely on the onCompleted callback which, as mentioned above, does not run when retrieving data from the cache. In our use case, we do not care about whether the result was retrieved from the cache or through a network call. We need to run the onCompleted callback in all cases or, as suggested here, provide an onCacheHit callback.

Frankly I'm a bit dismayed that Apollo decided that this should be the default behavior without exposing any kind of override.

[tghosth]

@elarlang I would have thought that only logs which the application is actually creating should be in scope? Are we expecting the developer to start investigating every other logging mechanism at every other level of the application/infrastructure stack?

[elarlang]

"application log inventory" should be correct title for the issue - but there is good question, where goes the line "what is application or it's component".

[tghosth]

I guess we could leave it a little open like:

Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, where that logging is stored and how it is used. (L2 or L3)

[elarlang]

First part is good, I think we need to be more precise with second part. I need to do some research first for this.

Current:

• where that logging is stored
• how it is used - I think this gives too many ways how to interpret it

Some more ideas:

• format for logs
• events in log
• log lifetime
• permissions - who can read it, who can remove it

[tghosth]

ok Elar, I have this as something you are working on

[tghosth]

@elarlang do we still need this open if you have a separate issue tracking this?

[tghosth]

@elarlang ping, does this need to stay open?

[elarlang]

Yes, need to rebuild entire logging part at once / all together. But not enough time for that at the moment.

[tghosth]

Do we want this to happen before 5.0? If so, now is the time...

[tghosth]

Based on discussion Josh/Elar.

Create documentation requirements in V1and map regular requirements back to them.

Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled and how long logs are kept for.

Verify that a sensitive data categorization has been prepared. (check 1.8.1)

Make these level 2 for now. Put into the relevant section for now.

Use issue #1231 to make sure that this documentation requirement section is comprehensive, i.e. in any requirement where some judgement or extra information would be needed in order to decide how to comply with the requirement.

[tghosth]

@set-reminder 5 weeks @tghosth to look at this

[octo-reminder[bot]]

⏰ Reminder Monday, January 16, 2023 12:00 AM (GMT+01:00)

@tghosth to look at this

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to look at this

[elarlang]

Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled and how long logs are kept for.

@tghosth - I think we can put this requirement in and finetune in the future. If the requirement is in, it probably get more attention and feedback as well.

I don't think it's major rework as labeled, it's just pre-condition requirements in (current) V7 where some rework is needed.

[tghosth]

But if it is documentation, should that not go in V1?

[elarlang]

But if it is documentation, should that not go in V1?

Yes, the requirement goes to V1.

V7 comment is that requirements in V7 category waits this requirement as precondition.

[elarlang]

Done with this one, another piece is opened as separate issue: https://github.com/OWASP/ASVS/issues/1759