the only way to maintain USB functionality and block the switchblade consistently is to use a filter driver and application blocking. The filter driver needs the following properties;
1. Must block moves/copies from a USB storage device into the PC
2. Detect and flag executables that start from the removeable drive
3. Detect and flag files opened from the USB storage device
Application blocking must have the following properties
1. Overt blocking of unknown executables from USB devices (blacklist or whitelist)
2. Covert blocking of saving of opened files originating from the USB device onto the PC (save-as blocking from whitelist applications)
The above will not protect against the following
1. person hand types batch files and executes
2. javascript in webpage stored on USB device
3. device driver attacks by USB devices masquarading as non-storage devices
4. any file stored on a USB device, accessed by a whitelisted application on the PC, which does not use normal save-as methods, or provides unusual access methods (examples include encrypted containers which mount locally and do not appear to be a removable drive)
5. filter driver attacks
For people who want to learn more, microsoft has an IFS kit with USB filter driver examples (currently being rolled into the new windows driver framework, so the toolkit name may have changed some). This is not for the faint of heart, as you start getting deep into kernel stuff and you can mess up badly. Typically, you'd want a guinea pig machine connected by serial to your dev/debug machine. The IFS kit costs some money, but I'm sure it can be acquired. There is some related stuff from sysinternals, but they stopped giving source code at an early version number, the source code isn't even available from their site anymore (gotta use wayback machine on mirror sites), and uses some truely ancient stuff to allow work with win98, so some of the methods may not even work anymore due to deprecation in the API's. But it is good reference materials. Developing file system filter drivers you can install on the fly requires good NTFS knowledge, but you can do some interesting things with it.
There's a reason why most of the filter driver work is done by israeli security companies (virtually all of them are staffed by former psyops and comm/info warfare guys who got out after training instead of going career military, so these guys are well trained). Application blocking is a relatively trivial exercise for whitelisiting, by doing quick and dirty hash signatures of every executable that should run, and blocking the rest through filter driver interception.