• False
    • Hide

      None

      Show
      None
    • False
    • Not Selected

      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

      1. 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)
      2. 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.

      1. MVP: alerts API is extended with filters
      2. 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>

              Unassigned Unassigned
              bmichael@redhat.com Boaz Michaely
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: