Ah - I haven't had time to look at UEFI. Sounds like a definite step forward.
Kurt On Tue, Dec 13, 2011 at 15:05, Michael B. Smith <[email protected]>wrote: > There are a few answers to that, but people complain.**** > > ** ** > > UEFI is designed to do just that. Cryptographic hashes on all boot > components to ensure that boot is secure, then allow Windows (or whatever > OS) to verify via cryptographic hash that individual components are secure. > **** > > ** ** > > It’s a hierarchical protection mechanism, but it must begin at POST.**** > > ** ** > > Regards,**** > > ** ** > > Michael B. Smith**** > > Consultant and Exchange MVP**** > > http://TheEssentialExchange.com**** > > ** ** > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Tuesday, December 13, 2011 5:55 PM > > *To:* NT System Admin Issues > *Subject:* Re: McAfee deep defender**** > > ** ** > > A rootkit doesn't have to be deployed via user access only. A > vulnerability in a kernel level component could enable an attacker to get > the code into the system.**** > > ** ** > > What then? How does the OS protect you when the OS has been subverted? > (Which is exactly why rootkits are so deadly)**** > > ** ** > > ** ** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > > > **** > > On Tue, Dec 13, 2011 at 5:20 PM, Kurt Buff <[email protected]> wrote:*** > * > > If the user can't write to kernel space, or install software that does > (separation of privileges, and proper segregation of userland from the > kernel), then the prevention is done, and the logging is nice to have. > > As you know, one of the major abuses that OSes make is to allow users to > install printer and graphics drivers that write to the kernel's address > space. It's handy and faster, but oh, so wrong...**** > > ** ** > > On Tue, Dec 13, 2011 at 12:24, Andrew S. Baker <[email protected]> wrote:* > *** > > So, hardening ones OS can provide the following benefits?**** > > ** ** > > • Preventing and logging write attempts to the system’s interrupt > descriptor table (IDT) and the system service dispatch table (SSDT)**** > > • Stopping changes to the processor system transitioning table**** > > ** ** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > > > **** > > On Tue, Dec 13, 2011 at 3:12 PM, Kurt Buff <[email protected]> wrote:*** > * > > Same answers as always: Harden the OS, impose separation of abilities and > limit administrator access. Whitelisting apps, too, for that matter. **** > > ** ** > > On Tue, Dec 13, 2011 at 08:15, Andrew S. Baker <[email protected]> wrote:* > *** > > Rootkits are largely already invisible to the end user.**** > > ** ** > > Of course, there is an element of risk to this, but doing nothing is not a > valid response to the existing threats, and you have yet to substantiate > any specific weakness that would allow malware writers to have a "field > day" with this.**** > > ** ** > > Allowing the end user to install or deploy technology early enough that it > can circumvent a rootkit is highly desirable, is it not? If you > disagree, please feel free to offer some viable alternatives... > **** > > ** ** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > > > **** > > On Tue, Dec 13, 2011 at 8:42 AM, Kurt Buff <[email protected]> wrote:*** > * > > Because once they corrupt it, it will be at least as invisible to the end > user as a rootkit. And you know it's going to be a big fat target.**** > > ** ** > > On Tue, Dec 13, 2011 at 04:41, Andrew S. Baker <[email protected]> wrote:* > *** > > Why would they have a "field day" with this? > **** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > > > **** > > On Mon, Dec 12, 2011 at 5:13 PM, Kurt Buff <[email protected]> wrote:*** > * > > Yes, it will be very effective for malware writers, who are going to > have a field day with this. It's just another layer of abstraction to > obfuscate functionality, and make it even harder to troubleshoot > problems. > > > > Kurt**** > > > On Mon, Dec 12, 2011 at 11:27, David Lum <[email protected]> wrote: > > Anyone care to comment on this? > > http://www.mcafee.com/us/resources/data-sheets/ds-deep-defender.pdf > > > > > > > > Note the requirements and specifications on the left. Looks like the > Intel > > purchase of McAfee is responsible for this one, the questions is will it > > really be effective? > > > > David Lum > > Systems Engineer // NWEATM > > Office 503.548.5229 // Cell (voice/text) 503.267.9764 > >**** > > ** ** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin**** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
