Audit logging and export to centralized logging (ProGet / BuildMaster)

dbojak

Hello,

We are currently evaluating ProGet and other Inedo products for enterprise use. As part of that evaluation, we need to understand what administrative and security events are captured, and how those events can be exported to our internal centralized logging platform.

Examples of gaps we have noticed currently in the system logging:

Changes to policies on a feed. Today we can see feed creation in proget event logs in the UI but thats about it.
Creation or deletion of API keys are not logged
Creation of User is logged but which permission was given to the user is not logged
If an anonymous user is provided access to something it only logs the privilege ID and doesn't provide more information that an anon user was provided administer, Manage Feed, Publish Package etc.

Please provide below if available:

Whether a documented, exhaustive list of audited event types exists per product
Whether the events are accessible via API or webhook, or whether direct database access is the only option, and if the latter, whether the schema is considered stable across product versions
Whether audit events are subject to the same automatic purge as Diagnostic Center messages, and whether the retention period is configurable

Thank you,
Dev

stevedennis

Hi @dbojak,

Great questions, and we're happy to help.

We're currently working on developing our best practices for application activity, and I'd like to share our current guidance, which is a work in progress. This is based on working closely with customers over many years, both proactively (developing policies) and reactively (actively helping investigate after an incident).

(Work in Progress)

Before looking to "ingest all the logs", identify a clear scenario that's contextualized to the product. For example, what does the Information Security team have in mind for monitoring, incident investigation, and compliance? What kind of incidents? What monitoring do they anticipate? And compliance with what?

ProGet attempts to provide appropriate "visibility into user activity and administrative actions", so if there are gaps I would start there. What is missing? How does duplicating data help? Etc.

For example, knowing which users download which Microsoft-owned packages on which day/time is not only impractical, but it serves no conceivable business benefit nor reduces any risk. But it could impact developer productivity and will increase costs across the board.

In addition, Microsoft Sentinel doesn't provide any contextualized visibility and, chances are, you will just end up back in ProGet searching for data anyway. So all the time and bandwidth spent exporting/duplicating data just ends up being waste.

That said, we don't have any built-in functionality to export this data, but it's relatively easy to export/ingest from the EventOccurrences table. These work differently in each product, but are similar in design.

[1] We do not have a documented, exhaustive list of audited event types exists per product, but it's relatively easy to attain through SELECT * FROM EventTypes type of query. That's the "source of truth" for events

[2] Direct database is the only option; we consider it quite stable, and it hasn't changed since like 1.0 of the products; there hasn't been any real demand to redesign or enhance it

[3] Audit events are never automatically purged, nor can they be deleted from the UI/API; they can only be manually purged from the database

As for the gaps you identified, those are things we can certainly consider addressing, provided it's within the confines of the existing design. It's relatively easy to add a new event type (if needed) or add additional audit data.

Overall, it's meant to be an "audit trail" instead of "change log" -- so it's not always the most user-friendly, uses more system-level concepts, and prefers immutable IDs over names.

Hope that helps!

STeve