Skip to main content

I would love to see something like this added to the policy creation section. Think of steps that would be removed by no longer needing to download an existing revision, create a blank policy, and finally importing your revision over the blank. It’s a small thing but when you do it all the time, it’s not so small.

That is a great add-on . That will be really helpful in order to replicate certain policies for use cases.


💯

This is a great idea!


If you like this idea please don’t forget to upvote it in the ideas portal!


Other way to have this kind of feature :

  • “Duplicate” option in the list of existing policies 
  • “Convert to template” option in the list of existing policies

 

 


I would love to see something like this added to the policy creation section. Think of steps that would be removed by no longer needing to download an existing revision, create a blank policy, and finally importing your revision over the blank. It’s a small thing but when you do it all the time, it’s not so small.

https://beyondtrust-public.ideas.aha.io/ideas/T2EPM-I-1316 in the ideas portal


Vote done on idea :D


Hi, I am curious on the use cases that require you to do this frequently?


That is a great Idea.

If you can’t wait on the idea to become a reality, you can currently accomplish this with the API.

 


Hi, I am curious on the use cases that require you to do this frequently?

We do no rules testing using our production policy. As such, we create a testing policy. Once the rules have been shown to be successful, we port them over to the production policy. When complete, we delete the test policy. At any given time, we may be working on multiple rule requests.


Hey @Josh Bristow - I’m curious, do you use this workflow for creating forked configuration, as well as effectively creating a branch of an existing policy which you then merge back in?

If you (or any other posters) are forking configuration, I’d be really interested to understand what use-cases usually drive that approach, but also whether you find that it’s the whole configuration which you need, or are you more often cherry picking certain parts of the source configuration (so today you’re having to delete out large chunks to leave the parts you actually want)? 


Here is what I use for the function.


Hey @Josh Bristow - I’m curious, do you use this workflow for creating forked configuration, as well as effectively creating a branch of an existing policy which you then merge back in?

If you (or any other posters) are forking configuration, I’d be really interested to understand what use-cases usually drive that approach, but also whether you find that it’s the whole configuration which you need, or are you more often cherry picking certain parts of the source configuration (so today you’re having to delete out large chunks to leave the parts you actually want)? 

We are not cherry picking sections of the policy as we are testing to see how a possible newly added or removed item will effect the policy as a whole.


Hey @Josh Bristow, what if you were able to simulate a change to policy i.e. add a new application definition and understand if the new rule would hit within the PMC console? 

 

Preventing the need to deploy the test policy revision to a group of computers and manually replicate the match. By instead, basing the simlulated policy change on audited event data in Analytics.

 

Woud that help prevent the need to create duplicate policies and use them to test new rules or config changes?


Reply