3 fix spelling
source | link

If the chip is writeablewritable from within the osOS, the malware can write to it too, so it wouldn't help there.

Also, antimalwareanti-malware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the antimalwareanti-malware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the osOS. If we can write to the chip from the osOS, so can the malware.

In order to make a secure hardware antimalwareanti-malware you first have to change the main task of the program. AntimalwareAnti-malware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of okOK programs. Either youYou'd either have to have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or youyou'd have to have an enormous list of any programprograms that anyone would ever want to run.

To generate that list, the easiest way would be to add every possible program, and remove all the bad ones, which is equivalent to what antimalwareanti-malware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for antimalwareanti-malware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

If the chip is writeable from within the os, the malware can write to it too, so it wouldn't help there.

Also, antimalware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the antimalware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the os. If we can write to the chip from the os, so can the malware.

In order to make a secure hardware antimalware you first have to change the main task of the program. Antimalware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of ok programs. Either you have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you have an enormous list of any program that anyone would ever want to run.

To generate that list the easiest way would be to add every possible program, and remove all the bad ones, which is equivalent to what antimalware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for antimalware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

If the chip is writable from within the OS, the malware can write to it too, so it wouldn't help there.

Also, anti-malware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the anti-malware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the OS. If we can write to the chip from the OS, so can the malware.

In order to make a secure hardware anti-malware you first have to change the main task of the program. Anti-malware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of OK programs. You'd either have to have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you'd have to have an enormous list of any programs that anyone would ever want to run.

To generate that list, the easiest would be to add every possible program, and remove all the bad ones, which is equivalent to what anti-malware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for anti-malware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

2 fix spelling
source | link

If the chip is writeable from within the os, the malware can write to it too, so it wouldn't help there.

Also, antimalware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the antimalware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the os. If we can write to the chip from the os, so can the malware.

In order to make a secure hardware antimalware you first have to change the main task of the program. Antimalware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of ok programs. Either you have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you have an enormous list of any program that anyone would ever want to run.

To generate that list the easiest way would be to add every possible program, and remove all the bad ones, which is equivalent to what antimalware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for antimalware companies trying to sell subscription serivcesservices.

As for the extra privilidgeprivilege level; sometimes you have to escalate prividgeprivilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

If the chip is writeable from within the os, the malware can write to it too, so it wouldn't help there.

Also, antimalware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the antimalware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the os. If we can write to the chip from the os, so can the malware.

In order to make a secure hardware antimalware you first have to change the main task of the program. Antimalware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of ok programs. Either you have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you have an enormous list of any program that anyone would ever want to run.

To generate that list the easiest way would be to add every possible program, and remove all the bad ones, which is equivalent to what antimalware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for antimalware companies trying to sell subscription serivces.

As for the extra privilidge level; sometimes you have to escalate prividge, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

If the chip is writeable from within the os, the malware can write to it too, so it wouldn't help there.

Also, antimalware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the antimalware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the os. If we can write to the chip from the os, so can the malware.

In order to make a secure hardware antimalware you first have to change the main task of the program. Antimalware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of ok programs. Either you have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you have an enormous list of any program that anyone would ever want to run.

To generate that list the easiest way would be to add every possible program, and remove all the bad ones, which is equivalent to what antimalware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for antimalware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

1
source | link

If the chip is writeable from within the os, the malware can write to it too, so it wouldn't help there.

Also, antimalware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the antimalware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the os. If we can write to the chip from the os, so can the malware.

In order to make a secure hardware antimalware you first have to change the main task of the program. Antimalware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of ok programs. Either you have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you have an enormous list of any program that anyone would ever want to run.

To generate that list the easiest way would be to add every possible program, and remove all the bad ones, which is equivalent to what antimalware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for antimalware companies trying to sell subscription serivces.

As for the extra privilidge level; sometimes you have to escalate prividge, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.