We have had the USB Defender rule on our LEM for the duration of time I have been with my organization. It's connected to the UDLP policy and they opted to use a notepad document to catalog the Windows ID numbers that are to NOT to be blocked by the policy. So the rule is:

EventInfo: *Mass Storage Device*

AND

ExtraInfo: Allowed Group (associated with the notepad document imported)

I wanted to have SmartCard readers, the ones a select group of end users have built into their laptops (all the same brand) to not be checked against this list as i do not want them ever to be blocked. So i added:

AND

EventInfo is NOT: *Smart Card Reader Details*

Has anyone done something similar and did it work?

Presently it does not seem to be working. I am not in a position to test on a domain laptop at this second so i am looking for possibilities until I get my hands on one.

Oddly enough i disabled the policy and the same user's reader is still being blocked by policy. And from what i gather it's not possible to attribute the policy that is being used and this is the only one i can see that would action on detaching.

Firstly, if you're using UDLP you'll need to make sure that the devices are included in the white list. UDLP is evaluated FIRST and then the information goes to the LEM to trigger a rule if it applies.

There are plenty of ways to set up the rule, but you will want to be mindful of your grouping and operators if you're using multiple lines like that (instead of including the devices in the allowed group, for example).

If you've tested with a device included in the UDLP list and it's still being blocked then if you can post a screenshot of your rule correlation we may be able to better assist from there.

If i am understanding you correctly then i think therein lies my problem.

What i was trying to do was NOT block any of my Smartcard readers internally by setting an exception and not having to add those serial numbers to the list.

Perhaps if i tell you exactly what i am wanting to do you may have a suggestion. I want ALL USB Mass Storage devices to be blocked, unless explicitly allowed. I want all other devices (local printers, scanners & Smartcard readers) to always be allowed and just logged. I came into this role and the white list feature through the LEM was not used, instead they imported the notepad document to the UDLP connector and were not auditing or updating it. So it's a bit of a mess. I don't know whose is what and when it was added.

I would like to be utilizing the white-list within the LEM as it's much easier to manage/update and audit. Do you have any suggestions on how I could begin merging them?

The UDLP list and the Approved USB Devices (or equivalent group) are both white list groups. It's easiest to think of it as a two gate or man trap style setup. The device MUST be in the UDLP white list otherwise it is blocked. If it is in the UDLP white list and not in the Approved USB Devices group then it is blocked. If it is in both lists then it is allowed to attach.

If the USB information from the smart cards is similar enough you may be able to put a partial string with wild cards, otherwise you will want to explicitly identify the devices in the list.

If you had a screenshot of your rule as it stands now I may be able to provide suggestions otherwise if you engage Support directly you can get someone on the line and they may be able to help you in relatively short time.

The Approved USB Device list is on my LEM. The UDLP white-list is on my notepad document and imported. Currently, my Approved USB Device list is empty, the UDLP white-list is my primary resource. So this leads me to what you just said:

"The device MUST be in the UDLP white list otherwise it is blocked. If it is in the UDLP white list and not in the Approved USB Devices group then it is blocked. If it is in both lists then it is allowed to attach."

This is not presently the case as i am not using the built in approved white-list (except for 1 item that was put in before my time) and those that are in the UDLP list are not being blocked. So i am not sure what you mean by the underlined portion of the quote.

Thanks for your suggestion about perhaps using a wildcard i will look into whether that will work and i think it may. Will the wild work in the UDLP list just as the Approved list?

Would an OR rule work here? If the UDLP list is always checked first and therefore blocked, could an OR rule stating NOT *smartcard* fix it?

My rule is only as is right now because the exceptions are useless based on what you have said about the order of operation.

OK, you may want to start over with the Detach Unauthorized USB Device template rule as it has a pretty good starting point for the correlations you're working with. You will want to clone the Authorized USB Devices group and edit it to have a unique name and contain an "approved" device for testing.

The template rule is proven to work and contains additional correlations and a popup action you can delete if you don't need it. It just minimizes the pieces we need to check to make sure the rule is working as it is likely that the group is empty that is causing the issue, but with the correlation how it is we can rule out correlation settings as a cause by using the template.

Additionally you may want to go to the Monitor tab and the Overview filter group to review the Rule Activity filter. If the LEM is blocking it with a rule, you will see the rule fire and appear in that filter. Otherwise it likely is something else (UDLP or another process).

Yes I have been using the monitoring tab quite a bit and can see when the rule applies. So far, if the the device IS on the UDLP list and that list has been applied to the connector it works.

What issue are you thinking that I am having? As far as i am concerned, everything is working normally within the natural limitations of the way the rules function per your mentioning that the UDLP list will be queried FIRST so essentially the exceptions I could list (Smartcard reader, etc) have zero affect. Is that not the case? Me wanting to query the list but also exempt machines that are showing 'attach' and 'eventinfo' for *whatever devices i want to not be blocked without explicitly updating the UDLP list is my goal but again it does not seem possible.

Additionally the UDLP and the LEM white list both needing to contain device information in order for the device to NOT be detached seems redundant as I thought they were two separate options for achieving the same result but perhaps this is what you are referring to as far as the 'issue' you mentioned. My real concern is what is going to happen when i start filling in the white-list on the LEM while keeping the UDLP list working and from your previous post about the different scenarios if both have it - it works. Once I get it updated i can eventually only use the LEM's white-list and stop importing.

I went ahead and took your suggestion in anticipation of your response on recreating the rule from scratch (below).

"Additionally the UDLP and the LEM white list both needing to contain device information in order for the device to NOT be detached seems redundant as I thought they were two separate options for achieving the same result but perhaps this is what you are referring to as far as the 'issue' you mentioned. My real concern is what is going to happen when i start filling in the white-list on the LEM while keeping the UDLP list working and from your previous post about the different scenarios if both have it - it works. Once I get it updated i can eventually only use the LEM's white-list and stop importing."

In a way, they are redundant, but they have different uses. If your end goal is simply to block unauthorized devices then it is redundant. The main use case for using UDLP is for disconnected nodes (such as laptops) so that when a node isn't communicating with the LEM the USB devices can still be blocked. If you don't need that, then you probably don't need UDLP.

Once you add devices to the LEM white list then the devices will be allowed. If you don't want to maintain both lists and aren't worried about devices being attached if the endpoint isn't communicating with the LEM then you can likely get rid of UDLP.

Ohhhh! I apologize for missing that through the user-guide/reading and this conversation - I did not know that was the key difference between the two lists I thought they were just different means to an end. And now it all makes sense. : )

Considering my concern for the devices the LEM manages are internal (with the exception of a select few) how would you suggestion I transition off the UDLP to the White-list to not cause inconsistencies?

Considering how many lines of data i would be importing from the txt file for the UDLP I have is there another method to get these in the LEM (script perhaps) so i do not have to manually copy and paste these one by one?

Note: You will likely have to add some information to the UDLP file before you can import it as a UDG with the above instructions.

3) Make sure the correct group is in your rule correlation.

4) Make sure the rule is enabled and in test mode.

5) Make sure it isn't blocking an approved device.

6) Take the rule out of test mode (Activate Rules).

7) Disable the UDLP connector. Hopefully this is in a connector profile otherwise maybe you want to set one up if it makes sense and you can get all of your nodes or groups of nodes at once.

The idea is if both white lists are the same then an approved device shouldn't have any issues and you shouldn't see any end user side impact, it will be fully silent.

It cannot be stressed enough that you will want to test this for yourself. So make sure you test (a few times if you want to be thorough) as there may be some environmental quirks you catch in the process. To fully test it I would even suggest getting an unauthorized USB device or a new device if you're able, disable and delete the UDLP connector for a node, add it to the approved group for the rule and then test it to make sure that UDLP was fully removed and the device is allowed.

Actions

More Like This

Retrieving data ...

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 130,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining.

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website,
you consent to our use of cookies. For more information on cookies, see our cookie policy.