USB Thumb Drive Security

Users are utilizing thumb drives to connect to USB ports on company workstations. A technician is concerned that sensitive files can be copied to the USB drives. Which of the following mitigation techniques would address this concern?

A. Disable USB within the workstations BIOS.
B. Install anti-virus software on the USB drives.
C. Apply the concept of least privilege to USB drives.
D. Run spyware detection against all workstations.
E. Disable the USB root hub within the OS.

The answer is A, but I'm not sure why it couldn't also be E. I realize that A might be more secure if you also password protect BIOS access. However, given a large number of workstations, wouldn't E be more efficient to implement via group policy? Would E be less secure? Do you agree that A is the best answer?

Find more posts tagged with

Comments

Ivanjam

Both A and E seem like viable alternatives to me too.

ptilsen

If you don't do A, I can boot to media other than the hard drive and get files that way. A would of course necessitate password protecting the BIOS for efficacy.

It really depends on the true goal. If the idea is to prevent regular end-users from copying files to USB, E will work.

The better option is to encrypt the hard drives and disable or control removable media through policy. This prevents booting to other media as a vector to place data on removable drives as well as negates the need for a more drastic action like disabling USB entirely.

I don't remember any Sec+ questions providing a selection of answers quite as poor as this, so this might be more reflective of your preparation material's quality than something you're likely to face on the exam.

teancum144

ptilsen wrote: »

If you don't do A, I can boot to media other than the hard drive and get files that way. A would of course necessitate password protecting the BIOS for efficacy. It really depends on the true goal. If the idea is to prevent regular end-users from copying files to USB, E will work.

So E would not prevent booting from USB drive? I'm not sure I understand why?

ptilsen wrote: »

The better option is to encrypt the hard drives and disable or control removable media through policy.

Do you mean group policy (technical control)?

ptilsen wrote: »

This prevents booting to other media as a vector to place data on removable drives as well as negates the need for a more drastic action like disabling USB entirely.

Please help me understand how this would be accomplished if E were in place.

ptilsen wrote: »

I don't remember any Sec+ questions providing a selection of answers quite as poor as this, so this might be more reflective of your preparation material's quality than something you're likely to face on the exam.

Good to know. Sometimes poor questions (like this one) motivate me to dig in and understand the issue better. I realize that I don't fully understand the limitations of "disabling the USB root hub within the OS".

ptilsen

teancum144 wrote: »

So E would not prevent booting from USB drive? I'm not sure I understand why?

E disables USB in the OS. This doesn't prevent a user from booting to other media or accessing the BIOS. It only affects access within the OS.

teancum144 wrote: »

Do you mean group policy (technical control)?

Yes, I mean Group Policy or a similar technical control (not written policy).

teancum144 wrote: »

Please help me understand how this would be accomplished if E were in place.

This method is an alternative to E, not something that would be implemented at the same time. Hard drive encryption negates the need for A, since the drive is inaccessible outside of the BIOS to those who don't know the encryption key and have significant technical ability. Technical control over the ability to write to USB media in the OS negates the need to disable USB entirely in the OS (which is not an option you'll see seriously considered in many environments, even military).

teancum144 wrote: »

I realize that I don't fully understand the limitations of "disabling the USB root hub within the OS".

The key is that this only disables USB access within the operating system, not outside of it. My aside, which is important to understand in real life, is that it is a drastic measure which greatly impacts productivity (no use of other USB peripherals, such as mice, keyboards, and cameras) and as such is a poor alternative to other, more effective measures (ie, the combination of hard disk encryption and technical controls limited writing to removable media in-OS).

pgriffin7

I've seen this question as well and thought the same; that both would work. I agree that in a larger domain using GP would definitely be the way to go rather than to visit each workstation and screw with the BIOS. On the other hand, potentially a user (regular or nefarious) could re-enable the hub on the OS via privilege escalation while cracking the BIOS password would be much more difficult IMO. Poorly worded question regardless.

teancum144

ptilsen wrote: »

E disables USB in the OS. This doesn't prevent a user from booting to other media or accessing the BIOS. It only affects access within the OS. ... The key is that this only disables USB access within the operating system, not outside of it.

Ah, I see (seems obvious now, but I was missing this key point). Thank you.

ptilsen wrote: »

Hard drive encryption negates the need for A, since the drive is inaccessible outside of the BIOS to those who don't know the encryption key and have significant technical ability.

I see. While this doesn't prevent someone from booting using alternate media, it protects the data on the hard drive.

ptilsen wrote: »

Technical control over the ability to write to USB media in the OS negates the need to disable USB entirely in the OS (which is not an option you'll see seriously considered in many environments, even military).

Just to restate what I think you're saying: This type of technical control doesn't prevent USB mice, keyboards, etc. because USB read is allowed, but not write. Therefore, in the case of a USB camera, you could read pictures, but couldn't copy a picture onto your camera's memory (via USB). Again, this doesn't prevent a hacker from booting (outside the OS) via USB, but that is not the purpose of this control. The purpose is to prevent users from writing sensitive data to USB devices for transport. Is my understanding correct?

ptilsen wrote: »

My aside, which is important to understand in real life, is that it is a drastic measure which greatly impacts productivity (no use of other USB peripherals, such as mice, keyboards, and cameras) and as such is a poor alternative to other, more effective measures (ie, the combination of hard disk encryption and technical controls limited writing to removable media in-OS).

Make sense. Thanks for all this information. It has helped me to see how all these pieces fit together.

ptilsen

pgriffin7 wrote: »

On the other hand, potentially a user (regular or nefarious) could re-enable the hub on the OS via privilege escalation while cracking the BIOS password would be much more difficult IMO. Poorly worded question regardless.

I disagree. Coding a privilege escalation exploit would require advanced programming skills. Privilege escalation exploits in general are few, far between, and quickly patched. Breaking a BIOS password is trivial, and the solution is there for non-techies on a cursory Google search:
https://www.google.com/search?q=forgot+BIOS+password

E, however, is easily circumvented by booting to another OS, rather than by privilege escalation. Both answers are flawed, but I find E to be more flawed since the circumvention method is easier (no advanced skills required to boot to a USB flash device) and the drawbacks are greater (no USB devices can be used at all).

teancum144 wrote: »

Just to restate what I think you're saying: This type of technical control doesn't prevent USB mice, keyboards, etc. because USB read is allowed, but not write. Therefore, in the case of a USB camera, you could read pictures, but couldn't copy a picture onto your camera's memory (via USB). Again, this doesn't prevent a hacker from booting (outside the OS) via USB, but that is not the purpose of this control. The purpose is to prevent users from writing sensitive data to USB devices for transport. Is my understanding correct?

Yep, you got it!

pgriffin7

Thanks - I understand and you are correct.