-
Feature
-
Resolution: Unresolved
-
Minor
-
None
-
None
Goal Summary:
An elevator pitch (value statement) that describes the Feature in a clear, concise way. Complete during New status.
ACS Violation Reports are needed for several reasons
- The Alerts API has search (query) capabilities, but lacks filtering capabilities. Customers who send the violation info to a back-end system have complained that this creates a data overload which directly turns into cost, for processing by the retrieval point, network traffic to back-end, and most significantly for back-end system cost (charged by data volume)
- UI customers have asked for the same abilities as vulnerability reporting and export
Goals and expected user outcomes:
The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.
As a platform engineer, I want to minimize the amount of violation alert data pulled from ACS. I only want to include the necessary fields that the security team is asking for. This is so that I can dramatically decrease my costs from network traffic and back-end data charges. Specifically I typically do not need the policy text fields (category, description, rationale, guidance, mitre att&ck, etc)
As a security engineer, I want a convenient method to generate and to export customized violation reports , same as I get from vulnerability management, so that I can drive incident response and policy violation remediation workflows.
Acceptance Criteria:
A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.
- MVP: alerts API is extended with filters
- UI: Support the same abilities as dictated by ROX-22271
Success Criteria or KPIs measured:
A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during Refinement status.
<enter success criteria and/or KPIs here>
Use Cases (Optional):
Include use case diagrams, main success scenarios, alternative flow scenarios together with user type/persona. Initial completion during Refinement status.
<your text here>
Out of Scope (Optional):
High-level list of items that are out of scope. Initial completion during Refinement status.
<your text here>
- is related to
-
RFE-5804 Report policy violations through a prometheus metric
-
- Approved
-