Idea ID: 2705148

ArcMC to manage all ArcSight products and components

Status : Accepted
over 1 year ago

Add process automation orchestration supporting ArcSight component and product infrastructure management through ArcSight-provided workflows.

Minimally will manage and/or monitor: Connectors, Thub and Kafka, Logger, ESM, Investigate, Certificates, Licensing, ...

  • Thank you all for your ideas and specifics on what would be helpful for you.  This is also helpful for us to ensure we target what is most important.

    User and Group management seems to be a pervasive issue as does managing infrastructure end points in bulk and better reporting of status information, particularly exceptions showing "what's currently not working right".

    Please note that ArcMC 2.96, which was GA'ed on December 3rd, now has a new exceptions dashboard for hosts that are not in a HEALTHY status.

    Our intent is to totally revamp ArcMC, top-to-bottom and in our new Fusion UI/UX, which is fully API drivable.  This will be a multi-release journey, and the traditional ArcMC that you use today will continue to be maintained during this journey until a full cutover can be performed.   

    Driving tasks though an API-ready orchestration engine will also simplify and speed development of new capabilities.

    I'll keep you updated on our progress...

    Thanks,

    Wayne

     

  • I agree with multiple replies here.
    Struggles with our current deployment include:

    • Managing ESM separately
    • Managing load balancers separately
    • Having to manually created users via ArcMC and then sink them down to our many Loggers.
      • Using AD security groups would be wonderful. 
      • Not exposed via API either.
    • Having to manage users with ESM separately.
      • Again, AD security groups. 
      • Not exposed via API.
    • Manually pulling down Logger, ESM, ArcMC updates from the entitlement portal and deploy them. 
      • Once pushed to ArcMC, Logger, Connector, and ArcMC updates are relatively easy (though they sometime require manual steps).
      • ESM is a whole different beast. Lots of manual steps, some of which, in theory, can be automated, but not the whole process. 
    • Exposure of more functionality through the REST API. Mainly for automation purposes.
      • Consistency of API is also key here, so that developed code can be partially reused. 
  • Adding the capability to manage the Loadbalancer Connectors would be great. 

  • Hi,

    I agree with both of you regarding managing and alerting exception behaviors and ensuring the REST API is complete and consistent across the portfolio.  

    Please enumerate your suggestions on the types of features/functions you would like ArcMC to provide.  For monitoring, we are strongly considering employing SiteScope to monitor the infrastructure and provide alerts and exceptions that need to be communicated to administrators.    

    In conjunction with the orchestration engine, we believe this will be a powerful solution enabling both manual and automated responses that field teams and customers would be able to augment or modify where required.

  •  I think one of the most important is when planning the new REST API itself, all types of "resources" needs to be available through the API.

    Resources can be anything from like users and activelists to fieldset and network configuration, license status etc.

    One main issue is for larger organizations using centralized user management, even with a external authentication the users still need to create a local copy of the users as well, which currently cannot be automated.

    Another important note would be that the REST API should be as similar as possible over all products, so creating a user on ESM should be the same as creating a user on ArcMC over the API, this would be hugely beneficial for everyone!