Intel Buys McAfee

Intel buys McAfee.

It’s another example of a large non-security company buying a security company. I’ve been talking about this sort of thing for two and a half years:

It’s not consolidation as we’re used to. In the security industry, there are waves of consolidation, you know, big companies scoop up little companies and then there’s lots of consolidation. You’ve got Symantec and Network Associates that way. And then you have “best of breed” where a lot of little companies spring up doing one thing well and then you cobble together a suite yourself. What we’re going to see is consolidation of non-security companies buying security companies. So, remember, if security is going to no longer be an end-user component, companies that do things that are actually useful are going to need to provide security. So, we’re seeing Microsoft buying security companies, we’re seeing IBM Global Services buy security companies, my company was purchased by BT, another massive global outsourcer. So, that sort of consolidation we are seeing, it’s not consolidation of security; it’s really the absorption of security into more general IT products and services.

EDITED TO ADD (8/19): Here’s something else I wrote about the general trend, from 2007.

Tags: , ,

Posted on August 19, 2010 at 10:44 AM • 72 Comments

Comments

Clive Robinson • August 19, 2010 11:00 AM

I suspect that we are seeing the normal Breadth after Depth cycle.

As a technology starts you see the initial players opening a new vertical niche within the broader scope of the technology.

As the niches drill down they appear to start running out of steam from an outsiders perspective.

The organisations thatt have obtained a larger market share start to see the same “slow down” so start to broaden out their activities either by internal development or by buying in. Historicaly it was internal (see IBM) in more modern times where companies buy in repackage and sell of organisational units it is faster to buy in.

BF Skinner • August 19, 2010 11:43 AM

I’d say it is/could be a good thing if it does reflect a shift of security as bolt on after-market to integrated in-line with production-lines.

If you don’t know how to do security you’ve got three basic choices, learn yourself, hire someone to do it or hire someone to teach you. I would hope that Intel would have learned by now.

This sounds like a case of buying additional business lines that will be aimed outward to the market and not inwards to improving Intel’s.

Companies have forgotten IT&T’s lesson. If you grow just to be bigger and not better then Coglomerates don’t work.

The business line has to be in sync with the firm’s strategy. Look at News Corp. They only buy news operations and Republicans.

Clive Robinson • August 19, 2010 12:03 PM

@ BF Skinner,

“… if it does reflect a shift of security as bolt on after-market to integrated in-line with production-lines.”

That if should be a very big IF…

If you look at Intel’s line up their big turn over products are on the underside of the OS.

McAfee on the otherhand work on the other side of the OS.

So the question is what can McAfee do for Intel’s big turn over products?

If the answer is “not much” then you need to dig a bit deeper.

A question of relevance is what the real profit margin is in Intel’s “big turnover” products…

Also you need to ask why McAfee’s owners want to sell to Intel what’s in it for them (other than a large chunk of cash etc).

Conflicted • August 19, 2010 12:06 PM

A conflict of interest results when a non-security company buys a security company. The larger company may see certain security features as detrimental to its OS or other software. Compromises in the interest of the success of non-security products can result.

The other problem is that the security software itself might be given ‘features’ that are not so much concerned with security, but with selling the non-security software. E.g. a ‘security notice’ that informs you to buy the latest upgrade to your non-security software.

Andrew D • August 19, 2010 12:10 PM

This makes sense to me. I expect to see Intel chips with embedded security features in the next several years. Why not integrate security awareness into chips? Is it any different from integrating security software in the OS on in the ISP/MSP cloud?

BF Skinner • August 19, 2010 12:45 PM

@Clive “should be a very big IF”

bold and italizcized as well but no formatting 🙁

kashmarek • August 19, 2010 1:27 PM

I worry about this. Intel could use McAfee as a front for security but instead build systems that are only secure for the vendors, marketing, and whomever they provide the collected data to. Users? Nah. We don’t need to protect any stinking users. The security may only be to protect Intel.

Electric Dragon • August 19, 2010 1:40 PM

B.F. Skinner: “The business line has to be in sync with the firm’s strategy. Look at News Corp. They only buy news operations and Republicans.”

Forgotten about MySpace already? Sic transit, and all that.

Grande Mocha • August 19, 2010 2:48 PM

I see this as a very positive development for consumers. Intel has already started moving in a pro-security direction by providing more hardware support for virtualization and cryptography (the i7 has advanced support for both VMs and AES). Moving more of the security into the hardware reduces the implementation bugs that circumvent security models in software.

Personally, I see a combination of hardware support for virtualization (for sand-boxing), multi-level permissions, and cryptography as the best practical way to improve security in commercial products. So, it makes sense to me that Intel would want to get involved in the software that actually uses these hardware developments.

Of course, they are probably also looking at this from the IP side of the equation. Moving all the security down into the hardware allows the DRM to be far more pervasive and difficult to circumvent.

Brandioch Conner • August 19, 2010 4:43 PM

I have to agree with antibozo. The problem is that all of the “anti-virus” products out there that I’ve used also suck.

My question would be … what, exactly, is Intel getting out of this deal?

I use McAfee at work and when I suspect a machine has “mal-ware” on it, we use two other products IN ADDITION TO MCAFEE to scan the machine. That is because McAfee isn’t good enough to do it on its own.

And despite us paying McAfee a license fee every year, they just aren’t getting any better.

How about this scenario? Use PXE to boot the machine to a known-clean Linux build. The Linux system compares the hashes (and locations) of all the files on the machine to the hashes (and locations) of a list of files that are allowed to be on that machine. Anything not found is moved to a quarantine area for analysis.

Yes, that is possible. Look up National Software Reference Library.

There. While it will not stop you from being infected, it will make the clean-up operation as simple as rebooting the system.

For preventing the infection in the first place, Microsoft has built-in a service where you can restrict what apps run on the machines. Too bad that the UI sucks.

McAfee doesn’t even offer a boot disk for scanning a workstation.

Why does Intel want them?

James • August 19, 2010 4:50 PM

There are 2 possibilities:

1) Intel really wants to add security
2) Intel wants people to think that they’ve added security

Maybe it’s both, but likely it ends up being that the results are a mixture of the two. You don’t just buy a company and suddenly poof you have security, unless they’re targeting a very specific product.

James • August 19, 2010 4:56 PM

@Brandioch Conner

What you’re suggesting is more complicated than you think. What is “allowed on the machine”?

You have a word document, you modify it and then the hash has changed. Even more simple, you opened the document, the data of last read was changed even if you didn’t do anything to it. hash has changed. Now you’ve just added another file to the quarantine list. Just image millions of files. In this end this technique can help for important files that should never change, but not ordinary files that a user is expected to use.

You also have to create the list beforehand and if it’s a fresh install that might be possible, but once you start it’s difficult to scale it.

Again, it can help in certain scenarios but not in all and the tradeoff seems heavy to me insofar as scanning the quarantined list every time you boot. Want to prevent malaware 100%? Disconnect your PC from the internet and don’t add anything you didn’t create yourself. It worked for the NOC list machine in Mission Impossible 😀

richrumble • August 19, 2010 6:37 PM

I think intel might offer a chip (on a nic, in a gpu, or even the CPU) with mcafee “hardwired” in it, perhaps to be OS agnostic, perhaps as a value add, but more than likely as some creme de la creme (hardware)product. There is a port of ClamAV to the GPU that touts a very large speed increase (http://gpgpu.org/2010/07/04/gravity-antivirus-engine) although very few networks I know of could achieve such a high throughput to begin with… But if intel had something on the same level… Your ISP’s might buy these products and pass the “savings” on to you, by charging you more 🙂 My best guess is they’d make some AV engine in the CPU or NorthBridge that helps with the virtual machine market but would also benefit normal OS installs as well. No matter what, they will charge for it, be it some subscription, of some very high up front cost. Who knows, maybe they let mcafee be mcafee and never put an engine in a chip… Since the principal of least privilege is a lost cause on windows (even 7), I think an AV on a chip, or some dedicated hardware for AV tasks makes some sense. The NorthBridge is probably as good a place to put it as any where else.
-rich

A Poster • August 19, 2010 8:07 PM

With multi-core CPUs vulnerable to internal “cross-talk”, the embedded AV approach is to prevent a “SKYNET” incident.

nobodySpecial • August 19, 2010 9:20 PM

@ James
There is a 3rd possibility
Somebody in the upper reaches of Intel wanted to be a player, get on the cover of the WSJ and advance their career into CEO at the next company.

He looks around for somebody to buy that wont annoy the regulators. He his now the mover and shaker behind a $7bn M+A, by the time it turns out to be a bust he will have moved on.

Tom T. • August 20, 2010 2:29 AM

McAfee has a poor reputation among many. A “free trial” came on a friend’s machine, as a free trial of Norton came on one of mine. Both proved inferior to alternatives that are free for personal home use. A lot of home users find that free AV is superior (Avast, Avira, e. g.)

I’d call this a new subset of “Security Theater” — buy a “security company” — any one — to make customers feel warm and fuzzy. I think they wasted their money.

@ Bruce: So long as BT doesn’t actually interfere with your operations, you’re OK and can still sell value. As above, I don’t see McAfee adding value to Intel, and I share the concerns of others that there might be conflicts of interest.
As you’ve written many times, it’s about incentives. The incentives of McAfee may be altered for the worse.

Clive Robinson • August 20, 2010 3:56 AM

@ moderator, James,

My appologies for the last paragraph in my post above the slide out keyboard driver in my LG Android phone “took a walk in the park” and I’ve had to reboot the phone.

@ James, to continue….

Intel’s software side has been steadily growing over the past few years and the income compared to risk is way better than chip production. A new Fabrication plant of the sort Intel use would probably set you back well over 12Billion USD and the ROI does not look good currently or even in the near future and as was seen in Japan with an earthquake a number of years ago chip manufacturing is very vulnerable to the environment around not just the Fab plant but the manufactuing plants that supply the very very specialised and extreamly high grade raw materials. It’s nearly all “single source supply” and I’m sure since 9/11 Intel Directors are well aware of what could happen to their entire business should a 747 drop out of the sky in certain places. Some of these are well outside of US airspace and with the likes of China ratteling the saber over Taiwan and North Korea (supposadly) testing a nuke down a mine in more recent times diversification of investment would be a very sensible option.

Then of course there is the slowdown in the mainline product. Microsoft OS’s after XP have been spurned by many many businesses. In the process they did not upgrade their hardware. Thus various demand predictions had to be re-evalutated downwards. We are more easily seeing this in GPU manufacture where Graphics Chip companies new products offer a lot lot less improvment for the cost of their products.

Thus the acquisition of McAfee needs to be looked at in relation to Intel’s currently more profitable software side than it’s hardware side.

However you have to ask “where’s the related prodduct” in Intel’s software line up?

McAfee’s software is intimatly related (more so than other AV companies products) with the MS Win OS…

We have seen other large players make inroads on the OS side (Oracle Google) etc prior to “cloud”. And others with new “cloud OS’s” for clients and servers.

Now looking back at Intel’s hardware side, Cloud Computing is supposadly going to make substantial CapEx savings for business. Ask yourself how that is going to effect “Wintel” dynamics and who stands to be a loser and why?

If you look at MS OS products you will see they have four main parts the UI, Comms Support, Driver Support, Kernel, additionaly almost hidden away is file systems. Traditionaly the major development push was at the UI and MS had to run realy hard to keep up on the comms side a few years ago likewise file systems. More recently they are trying to “bolt on security” in the desktop products. But not much is being said about server side except on the small to medium business front and what about “Cloud Computing”…

If Intel has decided to develop it’s own OS like other large IT organisations then a “Cloud OS” focus would be a place to get an early and solid market share. For a number of reasons I would expect a large chunk of it to be a Telco Grade Unix that is Open Source and for Intel to use it to sell not only it’s hardware but also it’s existing development tools. What it would also need if it was not going to make the same mistake as MS is to build in Anti-malware and security right from the begining and not bolt it on as an after thought.

There are a number of Telco Grade OS’s out there offering excelent stability and reliability and availability, BUT they tend to lack the sort of security that will be required to get high assurance for a Cloud OS.

I need to note though that this is just one possible interpretation based on some of the facts, observations and indicators about not just Intel and McAfee but other market players and the market as well. I could well be wrong due to giving insufficient weight to some other indicators and facts so don’t start buying/selling shares on it make your own mind up 😉

Brandioch Conner • August 20, 2010 5:27 AM

@James
“You have a word document, you modify it and then the hash has changed.”

It doesn’t matter. It should be simple for you to identify what data files you have created.

“Again, it can help in certain scenarios but not in all and the tradeoff seems heavy to me insofar as scanning the quarantined list every time you boot.”

What quarantined list?

This is the opposite of that.

This is a list of what is allowed to run on your machine.

There is, practically, an infinite number of ways to disguise “mal-ware”. Attempting to identify the “bad” files is useless. As is the situation today.

Identifying the legitimate files is far easier.

Rob E • August 20, 2010 7:55 AM

As I have said elsewhere:

Intel might find a way to differentiate future processors by adding industrial-strength security to their chip(set)s by integrating AV and management suite facilities with specialized hardware, but Intel has always benefited from being the premiere supplier of open-platform technologies and they are forced to be that way both by the market and by regulation. If they build significantly proprietary systems to increase margins, they may become vulnerable to attack on both fronts.

To me, $8Bn is just too much for McAfee. I think they could have got the same capabilities for a lot less money. McAfee sells low-margin, crappy AV software. They earn a few hundred million a year. Intel earns 4x the return on investment in its existing business (relative to McAfee). They’re going to acquire that new income stream (such as it is) and an established organization of AV “experts” and management to use to build new features into their offerings. However, I believe the embarrassing products McAfee sells will not magically move up in quality by making the developers deal with a bunch of hardware guys. (Put another way: I’m not sure any amount of hardware could make McAfee run fast enough and even fast inaccurate scanning is still inaccurate). Also, McAfee’s 3rd-rate products will dilute Intel’s brand. In the words of Warren Buffett, as an INTC shareholder, “I feel poorer”.

mfe • August 20, 2010 8:47 AM

business pages report that intel bought MFE (stock exchange acronym) for its rising stock price. Unlikely that they will build security into the hardware. MFE does not do security very well, they are about selling MFE, perhaps now the little nag bubbles will say (your computer is not secure buy more MFE and intel) MFE is not top line security, but its marketing is ubiquitous.

David Thornley • August 20, 2010 9:39 AM

@Brandioch: So who maintains the whitelist?

If it’s the user, then the user will install malware. We know that. Most malware, nowadays, didn’t get into computers by self-replication or exploiting security flaws, but because it was specifically installed by people who didn’t know what they were doing.

If it’s a central authority, then what we’ve got isn’t a computer as we’ve been using the term for decades. The iPhone is like this: all executables (except Javascript code) are whitelisted by Apple. This has annoyed a good many people and hasn’t completely stopped malware. This is suitable for many business computers, which are often locked down as tightly as possible, and that is a large market, but not the only one. I couldn’t do my job if executables had to be whitelisted externally, because I’m constantly creating new executables.

Moreover, there’s not a sharp boundary between executable and data. There has been plenty of malware in Microsoft Office macros, Javascript scripts, and things like that. Note that the most locked-down platform in general use, the iPhone, still executes arbitrary Javascript.

So, we’ve got examples of both sorts of whitelisting in practice nowadays. Malware hasn’t gone away.

Warren • August 20, 2010 9:39 AM

I’m not a McAfee fan. Well, I’m a McAfee Knob fan, but that’s another topic.

Anyway, I think this is more of a bottom-line decision. Intel has to make a good return for investors and they feel like they have to add to their line-up in order to do so. They saw something they liked in McAfee’s financials so they drafted a check.

eCurmudgeon • August 20, 2010 9:45 AM

@Brandioch Conner: “How about this scenario? Use PXE to boot the machine to a known-clean Linux build. The Linux system compares the hashes (and locations) of all the files on the machine to the hashes (and locations) of a list of files that are allowed to be on that machine. Anything not found is moved to a quarantine area for analysis.”

How about a simpler solution: Use PXE to boot the machine to a known-clean Linux build (running SELinux extensions under the “strict” policy). At this point, present the user with a stripped-down web browser and/or a RDP client to a secured virtual system in the data center.

We used to do this with X-Terminals for years, and worked quite well.

Isaac • August 20, 2010 10:52 AM

Maybe the question isn’t “why did intel buy mcafee?” Maybe, the question is “What does mcafee have that intel wants?” maybe there is some IP intel is after and they feel that Mcafee can earn enough revenue to pay for the rest of it.

Clive Robinson • August 20, 2010 11:05 AM

@ Brandioch Conner,

There is a hole in your reasoning.

@ James said,

“You have a word document, you modify it and then the hash has changed. ”

Which is correct for the senario under discussion.

However your reply,

“It doesn’t matter. It should be simple for you to identify what data files you have created.”

Whilst correct avoids the issue of the file contents.

It is like you ariving at a forign Airport, you pick up your bag (the file) from the luggage claim (file system) and make your way to customs. They ask you if it’s your bag (file) you say yes as it looks like your bag (file) and has your luggage tags (file meta data). The customs officer asks if you packed it (yes) and if anybody has asked you to carry anything (no) you open the bag (file) and ther is a package of film full of kiddy porn (malware) hidden in there what do you say when the customs officer (your manager) to explain it?

Who will belive you when you say “it must have been. the baggage handlers” (executable in RAM).

The simple fact is as has been recently shown with the iPhone the equivalent of “baggage handlers” do hide stuff in innocent bags (files) whilst out of sight, and the same applies in the more general computer world.

Even the best of locked down systems are vulnarable to malware that the system AV software does not detect (zero day) and if the malware only modifies the system RAM and the current program image the user is running (MS Word’s a good target on a PC or Mac) then your white list system will not pick it up.

If the malware writes a copy of it’s self into a file file as the user saves it, your white list system detects the change and asks the User to say OK or not.

They will say OK as they have just saved the file. Sadly the system is infected at that point
and potentialy every file there after as the user carries on modifing/saving them and OKing them into the white list…

That is they are OKing the file meta data presented through the filter of the OS (think memory resident root kit) NOT the actual file contents…

Usually the file the file contents are in some propriatry binary format the user has no hope of understanding. And by say a buffer overflow or equivalent re-infects the program (say MS Word) in RAM each time the infected file is loaded by the user…

We have seen PC’s attacked via data files such as grafics files word pro files PDF files and numerous others.

Thus your “white list” system is vulnerable just as some AV software has been successfully owned by zero day malware…

Once the attackers “are in” they “are in period”. If they got in via a very obscure zero day and observe a very very low profile whilst in then they have cleared just about all of the hurdles for those “scarry” Advance Persistent Threats (APT) those wanabee cyber-bureaucrats keep banging on about to get appropriations out of the politicos.

And as long as the malware is saved in data files only and only modifies “in RAM” executables it will only be detected by either accident (Sony Rootkit) or when another OS on immutable media looks at the file data and somehow spots the malware. And as we know code can be hidden in text there is a very real chance it can be hidden permanently…

Now if this APT style attack only ever looks at the users files and uses covert communications it can slowly send them all out piggy backed on other user data (we know how to do this via time based covert channels see Matt Blazes home page for “keybugs” to see how it can be done.

swhx7 • August 20, 2010 11:06 AM

When wondering about the meanings of events, ask what the best and worst case scenarios are. kashmarek and Grande Mocha have suggested the worst in this case.

I don’t think this is about anti-virus. McAffee also makes encryption software, and Intel is a founder and big supporter of the (Orwellian) so-called “trusted computing” scheme.

The problem is that “security” only sometimes means real security, in which the computer owner is in control – but other times it is a euphemism for the opposite, i.e. DRM schemes where an outside party has “security” against the owner.

Frosty The RAM Snowman • August 20, 2010 12:57 PM

“Disconnect your PC from the internet and don’t add anything you didn’t create yourself. It worked for the NOC list machine in Mission Impossible”

The room/structure was likely heavily shielded, whereas most civvies don’t shield their house and computer rooms. There is more than meets the eye to modern hardware.

Google:

subversion hack:
tagmeme(dot)com/subhack/

network card rootkits and trojans
pci rootkits
packet radio
xmit “fm fingerprinting” software
“specific emitter identification”
forums(dot)qrz(dot)com

how many malware scanners scan bios/cmos and pci/agp cards for malware? zero, even the rootkit scanners. have you checksummed/dumped your bios/cmos and firmware for all your pci/agp devices and usb devices, esp vanity usb devices in and outside the realm of common usb devices (thumbdrives, external hdds, printers),

Unless your computer room is shielded properly, the computers may still be attacked and used, I’ve personally inspected computers with no network connection running mysterious code in the background which task manager for windows and the eqiv for *nix does not find, and this didn’t find it all.

Inspect your windows boot partition in *nix with hexdump and look for proxy packages mentioned along with command line burning programs and other oddities. Computers are more vulnerable than most would expect.

You can bet all of the malware scanners today, unless they are developed by some lone indy coder in a remote country, employ whitelisting of certain malware and none of them scan HARDWARE devices apart from the common usb devices.

Your network cards, sound cards, cd/dvd drives, graphics cards, all are capable of carrying malware to survive disk formatting/wiping.

Boot from a Linux live cd and use hexdump to examine your windows (and *nix) boot sectors to potentially discover interesting modifications by an unknown party.

MoJo • August 20, 2010 1:19 PM

This makes no sense. Why buy the shittiest anti-virus product on the market?

There are plenty more effective AV products that don’t break your computer as badly as McAfee does, so clearly they are not going to get much in the way of technical expertise. Maybe they just want the name, but even that is irreparably tarnished thanks to a decade to crapware.

Nick P • August 20, 2010 1:53 PM

@ guys talking hardware security

The real key to security is a secure TCB. This means the hardware and every privileged piece of software must work properly. All the secure OS’s in the world aren’t worth crap if the processor or firmware have exploitable flaws. With over 200 bugs in their mission critical Itanium line, Intel’s quality matches McAffee’s nicely. Their security-relevant features are also behind the competition like VIA or Freescale.

A practical processor will ideally have these features: minimally two-state design (user/kernel modes); Intel VT-style virtualization; IOMMU for devices; acceleration for encryption, hashing and public key; true RNG; TPM (onboard); high assurance microcode; zeroization of shared storage during context switch; instructions take same time to execute; no known bugs in firmware or processor.

VIA’s C7 and Eden chips have had most of these features for years. Eden has Intel VT, AES, SHA1, SHA256, RSA acceleration, and true RNG. Rockwell-Collins AAMP7G’s microcode and instructions were mathematically verified correct. It also embeds the Integrity-178B separation kernel, meaning strong isolation and wiping of shared storage on task switch. Intel Core i7 vPro provides TPM, AES, and their lowest bug count. The Aegis processor from MIT encrypts and signs data in RAM with onboard private key to prevent malicious modification.

So, if Intel really wanted a secure chip, they would redesign a chip to have all the features listed above. They would also use a low defect process to do it. Otherwise, existing attacks would still work. Adding security features doesn’t mean adding security: inevitable flaws often reduce security. Remember vPro? Remember caching attacks? Remember exploitable processor errata on Intel? Only a high assurance design prevents all this.

Currently, if a trustworthy x86 is desirable, I use a Core i7, disable all unnecessary features in BIOS, leave only 1 core on (reduce sync/timing/cache attacks), and use a custom BIOS/drivers/kernel with signed loading. Trusted software runs directly on the kernel and other software runs in paravirtualized Linux. I’ve been recently working on a design that combines SecVisor with a TPM for trusted initial state and then preventing writes into running Linux kernel.

Real security is hard and requires a fundamental redesign of our platforms. Intel and McAffee will not accomplish anything in direction of real security. Mark my words. Props to the companies doing the real thing, each in their own way. Here’s a list: Rockwell-Collins; NSA Type 1 device builders; Green Hills; LynuxWorks; NICTA; TU Dresden; SYSGO; XtratuM; VAMP team; Sirrix; Galois; Praxis. Intel can feel free to copy these people so my computer will actually be “securable.”

Doug Coulter • August 20, 2010 2:45 PM

Gee, everyone I talk to says McAfee really stinks and eats a whole machine, taking even a fast one to its knees, and they hate it and can’t get it fully uninstalled either. You’d think Intel would want them as they are — effectively promoting upgrades in hardware to run that trash and therefore more sales of new stuff by Intel.

But maybe they just want the innards so they can purpose some in cpu hardware to make it fast.

Me, I just run Linux and don’t need that crap.
Funny how the ratio of speed on the same hardware for Linux vs Windows latest keeps getting better…at least here. We only find it practical to run windows at all in virtual box, behind a firewall if we let it have net access at all, and fully backed up and easy to revert. Windows in a window is the way to go, and unencumbered by all that AV junk, XP isn’t that bad — if you need it for something.

Brandioch Conner • August 20, 2010 3:31 PM

@David Thornley
“So who maintains the whitelist?”

I don’t understand your question. Why does it have to be exclusive either/or? A central repository for the base and the users are allowed to alter the settings on their machines.

In a corporate environment that means that the “users” would be the admins in IT.

Which reduces the problem set.

“Moreover, there’s not a sharp boundary between executable and data. There has been plenty of malware in Microsoft Office macros, Javascript scripts, and things like that.”

So? There will always be bugs in software that can be exploited. This approach will allow identification and cleaning happen with a simple reboot and make it more difficult to get the “mal-ware” installed in the first place.

“So, we’ve got examples of both sorts of whitelisting in practice nowadays. Malware hasn’t gone away.”

Yeah. You might want to look into that.

The machines that I run that follow this process are not infected.

The machines that I see that are infected do NOT follow this.

Saying that “mal-ware” exists … on machines that do not follow this process … that’s just supporting my statement.

In order to counter my statement, you’ll have to show “mal-ware” remaining installed (or automatically re-installing itself) on a machine DESPITE following this process.

Clive Robinson • August 20, 2010 3:52 PM

@ Nick P,

“A practical processor will ideally have these features: minimally two-state design(user/kernel modes); Intel VT-style virtualization; IOMMU for devices; acceleration for encryption, hashing and public key; true RNG; TPM (onboard); high assurance microcode; zeroization of shared storage during context switch; instructions take same time to execute; no known bugs in firmware or processor.”

OK that’s step zero….

Some other Steps are,

A, EmSec passive (shielding / filtering),
A.1, Emission suppression.
A.2, Susceptance suppression.
A.3, Propergation suppression.
A.4, Input out of band Side channel suppression.
A.5, Output out of band Side channel suppression.
A.6, Out of band Side Channel propergation suppression.

B, EmSec active (limiting / DC restoration / shape correction),
B.1, Input in band side channnel disruption.
B.2, Output in band side channel disruption.
B.3, In Band side channel propercation suppression.

C, EmSec active (time, phase, frequency)
C.1, Input in band side channnel disruption.
C.2, Output in band side channel disruption.
C.3, In Band side channel propercation suppression.

D, EmSec active (Dump and back off)
D.1 Input error side channel suppression.
D.2 Output error side channel suppression.
D.3 Error side channel propergation suppression.

Side Channels are efectivly those “that exist as a consiquence of the normal operation of the system that might disclose information or be used by an attacker to disclose information”. In essence they exist by poor system design.

Covert Channels are effectively those “that exist as a consiquence of d

Input covert channel disruption.
6, Output covert Channel disruption.
7, Error injection suppression.
8, Error

Clive Robinson • August 20, 2010 4:00 PM

@ Nick P, Moderatot,

Sorry that’s twice in one day this slide out keyboard driver has hung up on this LG Android phone…

Looks like I’m going to have to have a chat with LG’s customer service about the “fit for purpose” clause in UK sales legislation…

@ Nick P and others,

I will do the bit on covert channels at another time when my serenity / karma has reached a more acceptable level 8(

David Thornley • August 20, 2010 4:12 PM

@Brandioch:

User whitelisting is essentially the same as allowing no application to run unless the user installs it. If the user is able to install software, and whitelist software, those will happen together. There’s plenty of malware running out there that was installed by the user.

A central list of available applications, and denial of the ability to install any other, is a whitelist, and that’s what Apple’s App Store is. Any app on that has been whitelisted by Apple. Without bothering to look it up, some of those apps have been found to do things they were not supposed to be doing, hence they are malware. Large whitelists don’t appear to work, although smaller ones (like game cartridges) apparently can.

Many business computers can be locked down tight, with a very short whitelist. Typically, an office worker can get by with the latest Windows, IE, Outlook Express, Word, and perhaps one or two other programs. In other parts of the business, this simply doesn’t work. As a software developer, I’d be useless working with a whitelist. There is always buggy software on my computer. Even with this, it’s necessary to lock down the input.

The reason it’s necessary to lock down the input is one you glossed over. Javascript and VBA are real computer languages, allowing arbitrary programs to run. The fact that these can support malware is independent of any software bugs, it’s inherent in being Turing-complete computer languages. The only way software bugs would affect this is that these really should be sandboxed, and people keep finding leaks in sandboxes. Therefore, these have to be whitelisted. This is difficult to accomplish, and the best idea is to accept Microsoft Office documents, web pages, PDFs, and so on, only from trusted sources, if at all possible.

So, whitelisting is inapplicable to many computers, as it would reduce their usefulness, possibly making them useless for their intended purposes. It is best done by locking down computers to a few different apps and screening the input, when that is possible. That can be effective.

antibozo • August 20, 2010 4:13 PM

McAfee is a lot more than anti-virus these days. McAfee has a constant habit of taking over companies that make other things–secure USB drives, full-disk encryption, IDS/IPS. As a result, they uniformly degrade the level of technical support available for all of these products.

I don’t see how Intel can make this situation any worse, and they might make it better.

John F • August 20, 2010 5:28 PM

@Antibozo: I keep coming back to the same thought. McAfee’s known for AV, but has a lot more than that in their portfolio (including patents).

On a somewhat less serious note, there is another possible explanation: It’s possible that Paul Otellini said something along the lines of “I just got a new PC, can you get me a copy of McAfee”, and a Jr. Level aide misunderstood what he said. 🙂

hah • August 20, 2010 6:49 PM

@Clive:

I can’t imagine why Intel would want to compete in the server-side OS market. That market is currently dominated by free OSes and OSes that are required for legacy reasons (such as IBM’s mainframe offerings). On commodity Intel CPUs, it would be foolish to use something other than Linux, BSD or (in some rare cases) Windows. Anyway I don’t think there’s any money to be made in that space that they couldn’t make just by building security applications for those same OSes.

Nick P • August 21, 2010 1:35 AM

@ hah

There is a niche market that wants products with the features/legacy/etc. of regular commercial offerings and security a little bit closer to high assurance offerings. These are the people that buy from the likes of Safenet, Sirrix, INTEGRITY Global Services, and Secure64.

Secure64 is an interesting example to support my claim. It’s an expensive DNS appliance designed to provide higher assurance than other DNS offerings, but with the same functionality. They started bottom-up: mission-critical, simple processor (Itanium); custom, strong OS (SourceT); careful, independently vetted DNS stack. The Itanium was wishful thinking, as it has some issues. However, the OS is quite interesting because it is designed in such a way as to make many kinds of app-level attacks impossible or hard. It also leverages every security-relevant function of the Itanium and uses layering to its advantage. The company is also regularly selling them. 😉

Secure64’s SourceT OS details
http://www.secure64.com/secure-operating-system

There are other examples like this. The idea is that certain companies would be willing to increase cost a little if they could get a great increase in assurance of confidentiality, integrity or availability. On the latter, Stratus’ Computers NonStop five nines servers come to mind. They are quite pricey and less open, but they sell plenty. So, if one is to sell a new OS, they must integrate it into a useful and wanted product. It won’t sell by itself except to others with useful product ideas. I’m currently working on product ideas for an EAL6-7 assurance system. I’ve found quite a few more than I thought I would. Still all tiny and of no concern to Intel, whose already in the high assurance markets with their VxWorks DO-178B and MILS product lines. I don’t see them doing any more high assurance, although they might do OS security feature addons.

Nick P • August 21, 2010 1:44 AM

@ Clive Robinson

Nice list of covert channel defenses for processors. I intentionally left most of that out for one reason: the chip I’m looking forward to will be versatile and in many affordable COTS devices. Do you really think we’ll see a slim, cheap smartphone whose hardware is certified to TEMPEST Level 1 and EAL7-level covert channel mitigation? Maybe I’m just pessimistic, but I don’t see it happening. I had to draw a line somewhere. I figure if attackers switch to that stuff, the news media will cause enough paranoia to increase demand for EMSEC. Otherwise, I’m leaving EMSEC off and focusing on covert channels that occur purely on the silicon due to processor design.

Now, for things like smart cards, EMSEC should be a top concern even if it affects affordability. Fortunately, reputable vendors currently design smart cards and tokens with quite a few side channel defenses. Not all of them, but I’ve seen it. I think it’s even mandated for those that get EAL5 certification, as the NSA pen tests them for data leakage.

Clive Robinson • August 21, 2010 3:53 AM

@ hah,

“I can’t imagine why Intel would want to compete in the server-side OS market That market is currently dominated by free OSes and OSes that are required for legacy reasons”

The reasons are amongst others “Brand Confidence” and “not to lose market share” on the high end CPU market place. If (and it’s a big if) Cloud Computing becomes a success.

You need to see an Intel OS as an “enabler” for their hardware and Apps not “compeating with other OS’s”. In this respect it could be part of another Open Source OS (like Nokias Telco Grade linux) gust tailoring to the Intel strengths.

The reason to do it is Cloud Computing could put a significant hole in Intels high end CPU sales (and MS’s Windows sales as well), and give significant ground to “Big Iron” like IBM’s Z servers and Sun’s Starfire servers which come with a standard OS across their respective ranges of hardware.

Intel has a problem in that it’s IAx86 is to “high end” for use much below desktops (such as embedded systems). And likewise not sufficiently “high end” for much more than medium size enterprise style servers.

Yes their CISC CPU’s do get used in large clusters but they don’t have any significant advantage. Even with the current substantial COTS advantage due to other aspects of the system architecture being more expensive it gets negated.

Effectivly the Intel IAx86 CPU market is getting squeezed at the bottom by the likes of ARM (via smart phones and Linux OS’s like Android) And their CISC CPU architecture is very far from ideal for high end server systems so they get squeezed at the top end by Z and Starfire systems.

Realisticly in many cases it has been MS Windows selling IAx86 CPU’s, and many feel that asspect is only still around due to what is effectivly “legacy” effects on “Personal” and “medium to small” servers.

Let’s be blunt MS Windows is not exactly the OS you’ld select for a smart device or a high end server if you wanted good cost / performance (and let’s be honest it’s security sucks at a fundemental level).

Now if Cloud Computing does take off ask yourself what will happen to Intel’s IAx86…

One view is that of “Web thin client” due to ubiquitous mobile communications will be the norm backed by OS agnostic services communicating via XML over HTTP (or whatever the future brings). These services running on “cloud computing” systems (as evidenced via Googles Chrom&Gears outlook amongst others).

That is the likes of Smart Phones, iPads and their look alikes and netbooks will start to become the platform of choice for everyday “Personal” and much business “Enterprise” use, that RIM etc are seeing (providing they don’t drop the ball over security).

That is we have got to the point where we are seeing Smart Phones doing pretty much all that most if not all the users require in terms of actual day to day activites.

The three main issues between a Smart phone and a current IAx86 based PC are physical UI, running cost and data storage.

Many will tell you that MS Windows “sucks” when it comes to UI and you get way better cost/performace from a games console. Also MS Windows platforms with Intel CISC CPU’s “suck” when it comes to “Environmental” issues such as the carbon foot print expressed as “running costs” (which killed off VDU’s and is rapidly doing the same to televisions). Many are looking at the uptake of netbooks (Intel atom) and also the likes of the iPad and “pocket portable” entertainment systems (ARM not IAx86) to overcome these issues.

As for data storage many users needs are satisfied “for free” in the current “cloud” we call the Internet made available via ubiquitous communications and physically small low cost Flash technology in USB “thumb drives” and smart device SD etc cards.

But what about applications etc, many will be surprised at how much has moved into the Internet cloud already via Google due to the joys of “always on”, “platform agnostic”, “use anywhere”, “collaborative” working…

That is “colabrative” Calendar, Diary, Word Pro, Spread Sheets etc which cover the bulk of everyday office activities can be had for next to nothing via the likes of Google. And to many users without the issues of backup and storage.

Better still they can use their smart phone or netbook or PC running whatever OS at any time on the document.

As for large data set business back end/office much of this has run untill very recently on the likes of IBM and Sun big iron (Z and Starfire servers) and it realy does run way better there in terms of cost / performance than it does on Wintel. The two advantages Wintel has so SMSE’s of “low entry cost” and “known OS” don’t apply when it comes to Cloud Computing.

The problem with Intel’s IAx86 is it realy “sucks” when it comes to scalling up to large data sets mainly due to CISC CPU issuse causing inter processor memory and comms issues.

Which means it’s very bad at certain activities that Z and Starfire multiprocessor systems excell at, and they offer at a large scale app platform at a cost / performance well ahead of IAx86 multiprocessor systems.

As for other activites such as running myriads of single user client-server apps (middleware and web page serving etc ) or certain restricted types of highly parallel computing not requiring inter processor communications or shared memory the IAx86 can do, the Z and Starfire systems can in many cases do as well if not better (all be it at a slightly higher price).

From the Admin side Z and Starfire systems are much easier to use and at lower cost. And provided you can maintain the load much less expensive on running costs.

A lot of the stuff businesses are looking to put into “Cloud Computing” is the large data set stuff that IAx86 sucks at, but the businesses where forced to use IAx86 due to the various costs of entry. Many of the cots of entry issues do not apply with Cloud Computing.

I’m sure that many at Intel think they have been cursed to “live in interesting times”…

One aspect to consider is the dependancy in the wintel tieup both past present and future.

Looking forward for MS, Windows is very dependant on IAx86.

However looking forward for Intel, IAx86 dependancy on Windows is very much less than it was and will lessen considerably more with time.

However unless Intel take the IAx86 further down the low power route they are going to see continued and growing market share loss to the likes of ARM CPU’s on smart devices for which there are almost as many OS’s as there are devices. MS almost to late woke up to the Intel atom on netbooks issue by reworking and life extending XP.

At the large system end however although IAx86 is in some super computer systems it has some disadvantages against Z and Starfire systems. One of which is each very large “cluster of blades” has a bespoke OS, Intel could improve the situation with a refrence design and standard OS.

To a limited extent IBM has already done this with it’s IAx86 blade systems. Intel however still produces some of the best language tools for the IAx86 and have shown they have the requred knowledge to produce an OS from scratch or modify an Open Source OS as required so it can and has been done.

However there is an area where the IAx86 can compeate in Cloud Computing if Intel get their act together and that is to take advantage of the poor interprocessor issues in the name “of security” and provide an appropriate OS to suit.

The problem with the likes of Z and Starfire systems is they have been designed to be very co-operative internaly at the core , and the assumption has always been that malware is not an issue and thus security in some respects is not in the core of these systems.

The issue of malware is not that great currently on Z and Starfire servers simply because they are generaly used within one organisation running just one or two large applications that need the interprocessor cooperation.

This is most definatly not the case with “cloud Computing” many organisations will have their own apps running. alongside that of their potential attackers. They will (or should) want very high segregation between their data and a potential attackers data. But they will still want to run apps that require reasonable inter processor cooperation.

At first sight you cann’t have it both ways. Whilst more true for Z and Starfire systems it is less so for IAx86 systems via CPU Bus encryption.

Put simply the shared external memory buses have AES or other encryption hardware put on them such that “off CPU” data is encrypted (this is a standard technique in some microcontrolers to protect chip probing). Most people just think about encrypting the data it’s self and don’t consider it is also posssible to encrypt the address information thus an attacker is faced not just with AES encrypted 128bit “words” of data but the entire data block itself is further “transposition” encrypted such that the attacker has no idea of the sequence the encrypted 128bit words fall in (As an overly simplistic view assume the memory size is prime to form a field and the address translation is calculated by a modulo reduction on a MAD).

This will require some specialised OS code to handle encryption keys etc.

However as Nick P has already pointed out there are other non Intel IAx86 CPU manufactures that have already put the required security hardware blocks into the chip (they just haven’t wired it up right yet 😉

Do Intel need their own OS for the IAx86, no but if they develop the in chip hardware and a refrence design and a high assurance OS to go with it, it will certainly gain market share. They could also cooperate with other OS and platform developers but they won’t get the same level of “brand confidence”.

Clive Robinson • August 21, 2010 4:26 PM

@ Brandioch Conner

The article below might give you pause for thought about how your whitelist can fail..

@ ALL,

The article is about a (sort of) Zero Day exploit that effects several hundred different Windows Applications, and due to legacy issues MS will probably not be able to issue an effective patch.

http://www.computerworld.com/s/article/9180978/Zero_day_Windows_bug_problem_worse_than_first_thought_says_expert

The reason it’s a “sort of” zero day bug is the overview of what the bug does is strikingly similar to a bug that has been described befor back “last century”… back when Win95 NT4 where the norm and that bug was simillar to a well known fault with the unix.

It is not so much a “code bug” but a “protocol bug” which are generaly the most devistatingly broad class of attack.

Apparently the issue here is in the way the OS finds and loads code. More specifficaly the loading of Dynamicaly Linked Libraries (dll’s) into memory from the “current directory” first…

The reason MS did this was to try to solve “DLL Hell” issues, where you could easily have an out of date copy of say VBRUN in your system directory and when you install a new application it would not work., Rather than have the installer overwrite the existing DLL and potentially break other installed apps that relied on the earlier DLL, the installer would put a copy of the DLLs it used into the directory the application executable code was installed.

To minimize DLL Hell MS plumped for the legacy aproach where you had to be in the same dirrectory as the application which made it your “current directory”. This was even after MS had created the %system% directory for DLLs to be put in…

A group of researchers investigating this bug “estimate” that there could easily be over 100 Billion instances of it out there (kind of guarenties that more than 90% of Win OS PC’s in the world are going to be vulnerable).

I keenly await the full disclosure to see if they have fully nailed the broad issue from last century…

Saddly this appears to be an instance of two issues I’ve highlighted as up and comming major security threats “supporting legacy code” and “protocol errors”…

Clive Robinson • August 21, 2010 4:31 PM

@ Moderator,

My LG Android smart phone has done it yet again…

Of my two comments just above can you remove the first as for some reason the phone posted it whilst I was still working on it…

J.D. Bertron • August 22, 2010 2:43 PM

Unfortunately, it has nothing to do with integrating security within the IT infrastructure. If that was the case, McAffee would be one of the worse candidates. Instead, it has to do with growth, and sustaining it.
McAffee has none of the capabilities required to make chips secure and even less capabilities to teach Intel how to do it.
It does however have the capabilities to implement securing (locking-in) the various contents and software to the platforms, much in the way that satellite TV has done for years. So, this move is much more directed at implementing DRM and customer lock-in than protecting platforms and adding ‘security’ for the customer.
In a way, this is similar to what Microsoft has done with Windows, where they spent more effort to ensure customers were using ‘licensed’ Windows versions than making sure Windows was secure.

Brandioch Conner • August 22, 2010 8:40 PM

@David Thornley

“There’s plenty of malware running out there that was installed by the user.”

You might want to look up the term “Trojan Horse”.

There is no way to stop users from installing trojans on their own machines.

Which is why my solution also included the ability to scan a machine from a clean boot and identify all of the apps installed (identification is accomplished by comparing multiple hash values).

So even if a trojan does get installed, it can be identified and easily removed. If the user wants to remove it.

There will always be a segment of users who do not care if they are running “mal-ware”. So what?

For those who do care (or companies that do not want their machines infected) this will solve their problems.

“So, whitelisting is inapplicable to many computers, as it would reduce their usefulness, possibly making them useless for their intended purposes.”

Not at all.

AC2 • August 23, 2010 1:12 AM

Say what you will but this buy seems to me a lot like buying a very expensive box of band-aids when the patient actually needs multiple surgeries…

Symantec has the enterprise AV market locked up pretty good and MS itself is making inroads into the consumer side. Given the poor reputation most commercial AV suppliers have this looks like a no-brainer in the future.

Many good folks have pointed out above what good things Intel can do to improve security at the hardware level, but I can’t link those descriptions to their MCAffee purchase…

The Intel CEO says “We believe that security will be most effective when enabled in hardware”. In the context of the McAffee purchase that would only work in a device where the OS is also running on firware and is controlled by Intel. Given that the current market share of such devices is ~0%, makes no sense to buy McAffee at a 50% premium.

But hell as someone else pointed out, they had the cash and possibly an egoistic whacko on hand…

Nick P • August 23, 2010 1:56 AM

@ Brandioch Conner

“There will always be a segment of users who do not care if they are running “mal-ware”. So what?”

I see you haven’t thought that through. How bout this scenario: hackers target the low hanging fruit, particularly those that don’t care. These computers become part of large botnets that send tons of spam and DDOS major websites or systems. Wait a second, this isn’t a dire prediction: it’s happening right now! And it’s mostly people using pirated copies of Windows XP who don’t care about downloading patches or preventing infections.

So, should I care about how such careless people make 250,000+ PC botnets worth of trouble possible? Or just say so what?

Note: Anyone wondering what careless peoples’ PC’s are capable of can look at the eToys.com vs. eToy.com vs. DDOS incident that brought eToys.com stock to zero. Some consider that a win, though. 😉

Clive Robinson • August 23, 2010 10:26 AM

@ Bruce, Nick P,

A “Heads Up”

Further to my comment above ( http://www.schneier.com/blog/archives/2010/08/intel_buys_mcaf.html#c455406 ) about MS siting on a series of serious zero day bugs for anything upto ten years. Which as the are based on “protocol” issues affect many many programs…

It has started to get more interesting,

http://www.infoworld.com%2Fd%2Fsecurity-central%2Fresearcher-told-microsoft-windows-apps-zero-day-bugs-6-months-ago-818%3Fpage%3D0%2C0

Apparently there is a paper from six months ago that actuall names applications and it covers the top apps you would find on 99.9…% of Computers…

As far as I can see it is all Vista and earlier MS OS’s going back to the start of NT and combined DOS & Windows (ie Win95…).

This has the potential to turn into quite a bellowing and baying for MS’s blood, which I’m sure they will weather but it will sure feal like “Interesting times” to them 😉

Number2 • August 23, 2010 10:44 AM

I think the purchase makes sense on a couple of levels:
1) The mobile market, sure I guess that’s a nice benefit to get a leg up on mobile devices that are secure
2) But to me, the work they’ve been doing with AMT/vPro stuff is important too. AMT/vPro is like 2nd generation, 3rd generation is on it’s way and nobody is using it. Most vendors have ignored it except McAfee. If they’re going to get it used, they need to be pushing it themselves and what better way than to snap up the company that’s made the most progress on it, McAfee.

Brandioch Conner • August 23, 2010 6:58 PM

@Nick P
“How bout this scenario: hackers target the low hanging fruit, particularly those that don’t care. These computers become part of large botnets that send tons of spam and DDOS major websites or systems.”

Again, so what?

There is nothing you can do to prevent that short of taking the computers away from those people.

I’m talking about the TECHNOLOGICAL resources to allow the people who want to protect their systems to do so easier and more efficiently.

If the person doesn’t care or even WANTS to run such “mal-ware” then that is a different subject.

And no, that is not the situation today. The situation today is that those zombies also include machines owned by companies and people who want to keep them clean but do not have adequate tools to do so in an efficient manner.

Nick P • August 24, 2010 2:21 AM

@ Brandioch Conner on The Real Problem

You’re talking about technological resources to stop things like botnets that simply don’t exist in the mainstream market place, for various (often non-compelling) reasons. David Thornley crushed your whitelisting for immunity argument, if that was indeed the argument, although it’s certainly useful as a layer of defense. I know Marcus Ranum is a big fan. TPM essentially whitelists the state of privileged code. I use whitelisting in my designs, but the OS and software must all be secure (usually read: mature and restrictive) for that to help. Otherwise, the system can be done in by keylogged user input, a malicious PDF, an overflow bug in a random app, or some other BS that should have no influence on the system’s security as a whole.

The real problem is that many processors’ and OS’s security models are fundamentally flawed patch-on jobs. Only systems designed to enforce POLA pervasively bottom-up can stop malware epidemics as we see today. HP’s Polaris Windows modification, the OP web browser, CapDesk desktop, INTEGRITY/OKL4 OS’s, and qmail are examples of doing it right in various ways. Good architecture, design, development processes and reviews throughout the lifecycle are necessary to produce the “invulnerable” systems Daniel J. Bernstein longs for. Anything less can’t be trusted and bugs found become more pervasive and devastating as we layer “untrustworthy” on top of “untrustworthy.”

Clive Robinson • August 24, 2010 3:02 AM

@ Number2,

“”

I was hoping to avoid talking about that very double edged sword.

As was pointed out in an OpEd piece a couple of years ago it is also “Big Brother in the Box” in corporate PC’s.

http://www.tgdaily.com/hardware-opinion/39455-big-brother-potentially-exists-right-now-in-our-pcs-compliments-of-intels-vpr

One thing to watch out for in the article is the authors use of “out of band” whilst it convays the point he is making it is not technicaly correct.

That is the communications to AMT in a vPro PC is done via the gigabit network connection and can clearly be seen along with the users traffic to a packet monitoring network device and is thus “in band” and can be filtered by an appropriate bridging device.

However to the vPro PC user the AMT traffic and activity is down below the software as it is done in hardware and thus not directly visable to the OS or the user thus is sort of “out of band” to the users activities.

It is the AMT subsystem I was looking at to implement a hardware security hypervisor in a cluster of blade computers (however it’s implementation is Oh so Slow compared to the operation of the blade it’s self).

If you look at it this way every byte of RAM (and most other types of memory) is available “across the wire” transparently to not just the user but any and all malware as well. Thus if you know what the RAM etc image should be without malware you should be able to see the change in RAM “that is the malware”.

Thus if you use the AMT hardware to scan the RAM image on a periodic basis you have a finite probability of spotting any malware.

Although it is not guarenteed to find malware that is in and out in less than one RAM scan, most Malware just cannot behave in that way so it offers the same benifits to security as “Monte Carlo Probabilistic Methods” do to mathmatics.

Sadly though AMT is pegged down by the communications channel it uses and is thus currently unsuitable for a hardware security hypervisor of this type.

Clive Robinson • August 24, 2010 6:43 AM

@ anum,

“Straight from the horse’s mouth, if you believe the horse..”

Did you read the “Forward Looking Statments Safe Harbour”….

It’s about the longest way of saying “this is just airware puffery” and “you cannot sue us on it” I’ve seen in a long while, most people stick with “Past performance cannot be used as an indicator to future performance”.

David Thornley • August 24, 2010 10:01 AM

@Brandioch:

I fail to see how my statement that end users install malware invites a suggestion to look up “Trojan Horse”.

Your idea of using whitelisting is to have a specific list of allowed applications, and to be able to identify these on a clean boot. Assuming there are no rootkits or even more devious malware, this will work very well when the computer in question only needs a limited number of applications, and is administered by people capable of correctly whitelisting them. This is useful when it applies, which is typically business computers used for fairly routine tasks. There are doubtless hundreds of millions of such computers, but there are also a very large number of computers this doesn’t apply to. I couldn’t do my job on such a system.

Therefore, whitelisting is far from a general solution. The breakdown point seems to be somewhere between video game consoles and Apple’s app store (which has hosted malware).

Given that there are hundreds of millions or more of computers that can’t use your proposed whitelisting solution, and noting that most people do care about malware (at least if they know about it), there’s a market for less effective but more generally useful protection.

Nick P • August 24, 2010 2:07 PM

@ David Thornley

Good points, again. Your strongest point is actually the malware in the app store. The whitelisting solution is based on totally trusting an entity that can be easily tricked into sending malware. Not the brightest thing… It means that anyone who can make a good submission to the Obfuscated C Contest can control a bunch of systems. But are there any malware authors good at obfuscation and convincing presentation of their apps? Uh, yeah… 😉 Whitelisting en masse: FAIL.

Nick P • August 24, 2010 2:18 PM

@ Clive Robinson

I say you’re sometimes brilliant and sometimes mad. The use of AMT for security is mad. AMT shouldn’t even exist on a “secure” computer, imho. It’s a huge heap of functionality that can be described as a backdoor waiting to be opened or a bunch of bugs waiting to be found. Intel can’t implement something as simple as an MMU without bugs. Why should I think AMT is any different? In any secure system I design, AMT is disabled promptly where possible.

Intel vPro already provides all we need to build a TCB, although they could reduce bug count more. INTEGRITY Workstation, LynxSecure, and Turaya Security Kernel all already support the use of vPro to create more secure computers. Nobody is using AMT for this, nor plans to use it, nor should. It should be removed from at least one vPro line because its unnecessary bloat.They should replace it with security acceleration like VIA’s Eden line and Freescale’s POWER lines. There are high quality AES, SHA-256 and RSA cores available from third parties. They could just license and integrate. A TRNG would be nice, too.

Clive Robinson • August 24, 2010 4:15 PM

@ Nick P,

“I say you’re sometimes brilliant and sometimes mad.”

Hey you and me both.

“The use of AMT for security is mad.”

As it currently is, and the way it has been implemented on mother boards I would agree with you.

However some of AMT’s functionality at the low level when coupled to another CPU that functions as the security hypervisor has some advantages as I outlined.

“AMT shouldn’t even exist on a “secure” computer, imho. It’s a huge heap of functionality that can be described as a backdoor waiting to be opened”

Yes as the current refrence design AMT shares an insecure IO channel which is not a good idea.

However you have to consider the duality of some asspects of the technology. The mechanisum that makes it a “backdoor” looks at first like it swings both ways, but it is actually hierarchical and could be made “one way”. That is a secure isolated hypervisor computer could use some aspects of AMT to monitor / inspect a lower hierachical secure computer for malware etc PROVIDED the AMT comms channel was fully isolated from any IO channel in use by the subserviant computer.

As for,

“or a bunch of bugs waiting to be found.”

This is unfortunatly the norm where specmanship and time to market are the design drivers and security is not even in the back seat but hanging on by bleeding fingernails to the back bumper.

As for,

“Intel can’t implement something as simple as an MMU without bugs. Why should I think AMT is any different?”

I would certainly agree that it cannot be trusted in a production design. However I’m looking at developing a research design to evaluate issues with Probablistic Malware detection not evaluate the goodness or badness of the CPU implamentation.

Which is a significant view point difference to your design goals for a practical production design,

“In any secure system I design, AMT is disabled promptly where possible. Intel vPro already provides all we need to build a TCB.”

Actualy no the over complexity of the vPro sugests it can not be sufficiently “bug free” to remain “trusted”.

I don’t like TCB because it boils down in most cases to bolting layer upon layer of complexity on top of each other. And where there is complexity there are unknown edge conditions that give rise to exploitable bugs. The hard part is for the attacker to align the holes the bugs cause in each layer to get at the soft juicy data inside. More importantly if the do find a viable attack then the chances are the layers of complexity will prevent the attack being detected.

Therefor I am looking to strip away the layers of complexity and the waste of resources that result from their use.

If you think about it the complexity is afterall just plain simple “security by obscurity” in the hardware. And as we cann’t get security by obscurity to work in software or just about anywhere else we have tried, why should we fool ourselves into thinking that it can be done in hardware?

Thus I’m looking for a different way to do security which is effectivly way more transparent way less complex and does not leave an attacker with a place to hide. And as it will use resources “smarter” not “faster” it should have advantages in resource limited environments like smart phones etc…

Brandioch Conner • August 24, 2010 5:28 PM

@Nick P
“You’re talking about technological resources to stop things like botnets that simply don’t exist in the mainstream market place, for various (often non-compelling) reasons.”

a. “botnets” do exist.

b. Stopping “botnets” is not my goal. Allowing people to more easily clean and verify their machines in my goal.

b. The technological resources do exist, today, and I am using them.

c. Whether the reasons are “compelling” or not is your opinion.

Here’s an example for you. Bruce worked on Twofish. But Twofish does not provide any encryption for anyone who does not use it. Therefore, by your logic, Twofish is useless. To me, it is useful because I can use it to protect information I want to protect.

Making other people to use Twofish is a legal/social issue, not a technological issue.

I only care about the technological issues.

Brandioch Conner • August 24, 2010 5:37 PM

@David Thornley
“I fail to see how my statement that end users install malware invites a suggestion to look up “Trojan Horse”.”

Wikipedia has a decent definition:
“A Trojan horse, or Trojan, is malware that appears to perform a desirable function for the user prior to run or install but instead facilitates unauthorized access of the user’s computer system.”

And then you continue with:

“Assuming there are no rootkits or even more devious malware, this will work very well when the computer in question only needs a limited number of applications, and is administered by people capable of correctly whitelisting them.”

So the user installs an app that appears to be something the user wants but also contains a rootkit.

That’s a “Trojan horse”. See the above posted Wikipedia definition.

So, what is the upper limit on your statement of “limited number of apps”?

5 apps?
10?
25?
50?
100?
500?
1000?

And why is that the upper limit?

I don’t see any problem with whitelist apps until the amount of data kept in the whitelist exceeds the the amount of storage space available on the system. McAfee is listing signature files for millions of viruses and their files are still under 70MB. A whitelist should be far smaller than that.

So what is the upper limit?

Clive Robinson • August 24, 2010 6:13 PM

@ David Thornly,

As you note Apple amongst others (MS included) have been responsable for distributing malware.

Some times this has been by accident where trying to fix one problem opens another and sometimes by deliberate design by somebody employed directly or indirectly by the organisation concerned.

This is one of the reasons I do not trust signed code as anything more than a “date stamp” on a code revision in the organisations repository. And do not make the mystake of giving it mystical powers of proving code functionality or trustworthiness.

Whitlists are likewise of no more worth than a date stamp, they in no way confer any value of functionality or trustworthiness.

In both cases even if the code had used all means possible to verify there was no known bugs or exploits in the code they would still be of little worth.

This is simply because whilst it is potentialy possible but extrodinarily difficult beyond practical usage to certify for “the known” it is most definatly not possible to certify for the unknown.

I have put this argumant to Brandioch in the past and he has avoided the issue of addressing it.

This may be due to the fact that he understands the concept but does not wish to address it or it might be due to some other belief he has which he choses not to have tested.

Nick P • August 25, 2010 1:09 AM

@ Brandioch Conner

I don’t think you even read my post. It addressed your original claims: whitelisting as the solution to defeat malware; who cares if users do things that get them infected. You’ve also shown great belief that recovery is what we should focus on, when it’s actually prevention by good design. I listed many examples of this that are available for research, for free, or commercially for production machines. I also mentioned that companies aren’t using these risk mitigation technologies, instead employing crap and buying tons of stuff to recover from its problems. Their losses are often greater than the cost of decent preventative measures. Your reply didn’t address anything in that post. Feel free to reply to my post’s actual content rather than your strange interpretations and extrapolations.

Brandioch Conner • August 25, 2010 5:59 AM

@Nick P
“It addressed your original claims: whitelisting as the solution to defeat malware; who cares if users do things that get them infected.”

No. Whitelisting is just one facet of keeping your systems clean of “mal-ware”.

“You’ve also shown great belief that recovery is what we should focus on, when it’s actually prevention by good design.”

No. The whitelisting is the first step of prevention. Recovery needs to be addressed because no matter how good your defenses are, there will be failures.

Since most of the systems out there are some version of Windows, changing the existing design is not an option.

The solution must be retrofitted to those systems without breaking any necessary functionality.

“I listed many … decent preventative measures.”

Again, I do not care what other people are doing (or not doing) if is not effective. So why talk about it?

Bruce can verify that I’m posting from a Chinese IP.

My systems are clean and they’re living in one of the most hostile Internet environments.

I only care about what works and what I can implement today. And how I can improve it for tomorrow.

I don’t care if people say it cannot be done. I’ve already done it.

David Thornley • August 25, 2010 10:04 AM

@Brandioch: My question about looking up “Trojan Horse” was based on the fact that I described them before you suggested looking them up. Perhaps I should stick to simpler language in the future.

The upper limit of a whitelist is how many applications the whitelisters can verify as being malware-free. This depends on the time needed to check the software and the amount of time available. This is typically done by organizations, and is limited to the software considered important for the organization, so the upper limit is frequently determined by what the organization needs.

It is, indeed, a very useful tool in keeping an organization’s PCs clean, but it works well only when the software needed is predictable, the task is not too large, and malware in interpreted languages (Javascript, Office documents, etc.) can be screened somehow. I assume this is the sort of organization you are in, since it works well for you. Your comment about “any necessary functionality” indicates that there are things the computers must be able to do, and a (much larger) range of things they needn’t be able to do.

It doesn’t work well when there’s sudden needs for software, for whatever reason, or if any of the workers compile their own (since if there can be legitimate software not on the whitelist the system breaks down). It doesn’t stop malware if the users are allowed to surf non-whitelisted websites with Javascript on. It doesn’t stop malware from Microsoft Office documents from untrusted sources.

Your system works for your needs, and that’s great. It won’t work for everybody, or even every organization, and that means it isn’t “The” solution. You’ve done it in an environment where it’s possible, and that’s good, but it isn’t possible everywhere.

lineover • August 25, 2010 11:19 AM

The buzzword security becomes important on some management round tables these days. Unfortunately not many understand whats behind it. However here comes my personal forecast: “A global leader in information security, protecting data at rest, data in motion, data in use, software and license management with the broadest range of security solutions in the world” will go public soon again. Once that happened I give it 2-3 months until a take over by someone else. My guess would be Oracle. But could be someone else.

Brandioch Conner • August 25, 2010 5:38 PM

@David Thornley
“My question about looking up “Trojan Horse” was based on the fact that I described them before you suggested looking them up.”

Why bother describing it when you can just use the term for it?

“The upper limit of a whitelist is how many applications the whitelisters can verify as being malware-free.”

To bad that “malware-free” is impossible. Tomorrow you might find out that Microsoft Excel has an NSA backdoor in it.

So your usage of “upper limit” could be millions of apps. I don’t see how that could “limit” usage.

“This is typically done by organizations, and is limited to the software considered important for the organization, so the upper limit is frequently determined by what the organization needs.”

No. That is limited to what the organization determines as “approved” software. Again, no need to show that there isn’t any “mal-ware” in the apps. Just that there is a business case for using that app AND that that app does not exhibit any obvious signs of “mal-ware” activity.

“It doesn’t work well when there’s sudden needs for software, for whatever reason, or if any of the workers compile their own (since if there can be legitimate software not on the whitelist the system breaks down). ”

If your company has people who are compiling applications and running them on production machines … you have bigger problems.

Erokhane • February 23, 2014 2:55 PM

Buying McAfee was a waste of time. Intel and McAfee are extremely different. Security software will always be necessary. Computers operate on data. Cash will always need banks to be really secure. Unless Intel has some ingenious idea to eliminate the need for software based security, I can’t imagine how embedding security features into it’s chips will make any difference to security. The only difference between hardware and software is that hardware is unchangeable. So unless software and data are going to be hardware based, then users will still need software based security.

Now if Intel is simply trying to dominate the security market by preventing competitors of McAfee access to their chips, then Intel might wind up like Apple and Dell. Proprietary security technology will only give Intel an advantage for a short time. Meanwhile AMD, other chip manufacturers, and other security companies will jump at the opportunities and weaknesses created by Intel’s attempt at simultaneously monopolizing the chip and security markets.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.