Symantec/Norton Antivirus Remote Heap/Pool Memory Corruption CVE-2016-2208(bugs.chromium.org)
bugs.chromium.org
Symantec/Norton Antivirus Remote Heap/Pool Memory Corruption CVE-2016-2208
https://bugs.chromium.org/p/project-zero/issues/detail?id=820
54 comments
This is actually a real problem we need public perception changed. If you have proper white-listing in place then AV does nothing but actually decrease the security as these AV programs probably need to be white-listed and thus expose the machines to the kinds of issues as shown here.
Unless the compliance auditors are happy with the software just being installed and don't check whether it actually runs. That would still be a colossal waste of money for the licenses but at least it would not compromise your security.
Unless the compliance auditors are happy with the software just being installed and don't check whether it actually runs. That would still be a colossal waste of money for the licenses but at least it would not compromise your security.
It's a really sad truth that to this date the only effective way to almost fully stop malware is to take away the ability from people to do what they want with their computers.
All operating systems that have some way to allow people to run malware, will get malware. Windows, OSX, GNU, Android all can get infected quite easily. Then there's iOS where you cannot, and instead Apple decides which software you can or cannot run.
The downside is of course that you cannot run any software going against the corporate values of Apple.
If you want the right to shoot yourself in the foot, AV is the necessary evil you must have, unless of course you're sure you'll never visit a website that contains an exploit, old or zeroday, against you browser or its components, and you will never open a office document, PDF or executable that has malware in it. And even then you can get owned.
All operating systems that have some way to allow people to run malware, will get malware. Windows, OSX, GNU, Android all can get infected quite easily. Then there's iOS where you cannot, and instead Apple decides which software you can or cannot run.
The downside is of course that you cannot run any software going against the corporate values of Apple.
If you want the right to shoot yourself in the foot, AV is the necessary evil you must have, unless of course you're sure you'll never visit a website that contains an exploit, old or zeroday, against you browser or its components, and you will never open a office document, PDF or executable that has malware in it. And even then you can get owned.
> If you want the right to shoot yourself in the foot, AV is the necessary evil you must have
No. AVs are actually pretty useless at stopping anything except the most basic attacks (and sometimes, not even that - just look at Cryptolocker).
Use Google Chrome (really! Firefox isn't even playing in the same league security-wise), disable Flash player, only run trusted executables with valid digital signatures.
No. AVs are actually pretty useless at stopping anything except the most basic attacks (and sometimes, not even that - just look at Cryptolocker).
Use Google Chrome (really! Firefox isn't even playing in the same league security-wise), disable Flash player, only run trusted executables with valid digital signatures.
Use Google Chrome (really! Firefox isn't even playing in the same league security-wise)
Can you elaborate just a little on this please?
Can you elaborate just a little on this please?
Firefox still doesn't use process separation between page rendering and the browser chrome. The thing that renders the pages on Chrome is a subprocess per tab (at considerable memory cost) which is also running in a sandbox.
In Firefox all tabs run in the same process and thus inherently can't be sandboxed (because it needs to write to the disk cache and save files the user downloads)
In Firefox all tabs run in the same process and thus inherently can't be sandboxed (because it needs to write to the disk cache and save files the user downloads)
The only tests against real malware out there I've seen are done by AV-Test and AV-Comparatives, and the top products are pretty good at blocking them. Calling them useless sounds more like your hopes than facts, like calling seatbelts useless because people die in car accidents.
Uninstalling Flash, Adobe reader, Office and JRE, and using Chrome with adblock also helps you enormously, but is still a far cry for any user having difficulties with finding the download-button from sourceforge.
Getting a signing cert is easy as just buying one from Honest Achmed's Used Cars and Certificates, so the only real use for signed software with malware protection is to manually maintain your own list of trusted signers.
Uninstalling Flash, Adobe reader, Office and JRE, and using Chrome with adblock also helps you enormously, but is still a far cry for any user having difficulties with finding the download-button from sourceforge.
Getting a signing cert is easy as just buying one from Honest Achmed's Used Cars and Certificates, so the only real use for signed software with malware protection is to manually maintain your own list of trusted signers.
> The only tests against real malware out there I've seen are done by AV-Test and AV-Comparatives, and the top products are pretty good at blocking them.
Of course they do well there – the vendors use those as a primary marketing feature. It's like learning that Oracle does well at a TPC benchmark they'll be printing on glossy brochures.
The question a buyer should be asking is “What percentage of attacks the average Internet user faces are stopped by this product?” and that has been declining steadily since the 90s because virus authors can easily test before releasing a new version and confirm that they've managed to avoid the current signatures. It doesn't matter that your product is great at stopping last year's malware if that's not what exfiltrates or encrypts your data.
> Uninstalling Flash, Adobe reader, Office and JRE, and using Chrome with adblock also helps you enormously, but is still a far cry for any user having difficulties with finding the download-button from sourceforge.
The part that you left out is that using Chrome gets you all of those but ad-blocking. It's true that it's hard for many users to operate securely but millions of them have managed to install Chrome and that's far more effective than any security product on the market.
Of course they do well there – the vendors use those as a primary marketing feature. It's like learning that Oracle does well at a TPC benchmark they'll be printing on glossy brochures.
The question a buyer should be asking is “What percentage of attacks the average Internet user faces are stopped by this product?” and that has been declining steadily since the 90s because virus authors can easily test before releasing a new version and confirm that they've managed to avoid the current signatures. It doesn't matter that your product is great at stopping last year's malware if that's not what exfiltrates or encrypts your data.
> Uninstalling Flash, Adobe reader, Office and JRE, and using Chrome with adblock also helps you enormously, but is still a far cry for any user having difficulties with finding the download-button from sourceforge.
The part that you left out is that using Chrome gets you all of those but ad-blocking. It's true that it's hard for many users to operate securely but millions of them have managed to install Chrome and that's far more effective than any security product on the market.
About those tests, you should know that the testing orgs are using an array a computers with up-to-date AV solutions, and then making them all go to e.g. websites dealing malware right then as soon as they find a new sources of malware attacks.
I honestly cannot imagine a better way to objectively test how well the products fare against attacks against an average Internet user.
Edit: If I was not clear, nobody tests with historical samples anymore. Only live attacks are being used for tests.
I honestly cannot imagine a better way to objectively test how well the products fare against attacks against an average Internet user.
Edit: If I was not clear, nobody tests with historical samples anymore. Only live attacks are being used for tests.
The problem is trying to extrapolate future performance based on performance against a historical sample. The process looks something like this:
1. Malware author releases something new
2. Users start getting compromised
3. Antivirus vendors start getting samples and analyzing them
4. New signatures are released
5. Clients download and install the new signatures
That cycle used to work better but in the Internet era it's a given that malware vendors are taking advantage of the substantial time delays between steps 4 and 5, which are often measured in hours or even days, and will change their code as soon as new signatures are released.
When someone reports results and they specify that the percentages are based on a historical library, that tells you little about what it'll do for you now. When they tell you that results are based on samples collected in the month prior to the test, which is what AV Test and AV Comparatives say they do, that's less stale but since it's starting after the vendors have already completed the entire process it still doesn't tell you how long you'll be exposed between steps 1 and 5 or whether some malware authors are consistently staying ahead of the loop.
This is really coming back to security fundamentals: trying to enumerate all of the bad things on the internet is futile. The better strategy is removing the ability to run programs which aren't on a known-good list but that breaks a lot of legacy practice.
> I honestly cannot imagine a better way to objectively test how well the products fare against attacks against an average Internet user.
The most reliable way to do this would be to simulate randomly surfing around the web, being sure to click on all of the ads, while monitoring for changes to existing programs or new programs, access to files the browser had no reason to open, and unexpected network connections.
1. Malware author releases something new
2. Users start getting compromised
3. Antivirus vendors start getting samples and analyzing them
4. New signatures are released
5. Clients download and install the new signatures
That cycle used to work better but in the Internet era it's a given that malware vendors are taking advantage of the substantial time delays between steps 4 and 5, which are often measured in hours or even days, and will change their code as soon as new signatures are released.
When someone reports results and they specify that the percentages are based on a historical library, that tells you little about what it'll do for you now. When they tell you that results are based on samples collected in the month prior to the test, which is what AV Test and AV Comparatives say they do, that's less stale but since it's starting after the vendors have already completed the entire process it still doesn't tell you how long you'll be exposed between steps 1 and 5 or whether some malware authors are consistently staying ahead of the loop.
This is really coming back to security fundamentals: trying to enumerate all of the bad things on the internet is futile. The better strategy is removing the ability to run programs which aren't on a known-good list but that breaks a lot of legacy practice.
> I honestly cannot imagine a better way to objectively test how well the products fare against attacks against an average Internet user.
The most reliable way to do this would be to simulate randomly surfing around the web, being sure to click on all of the ads, while monitoring for changes to existing programs or new programs, access to files the browser had no reason to open, and unexpected network connections.
[deleted]
There is a middle ground. Have the OS enforce only running, signed executables, but put the user in control of the certificate authority list. Then if you want Apple's style of security, just put their key in the list. If you want more freedom, add you own key and sign away.
of course, then you'll end up with regsvr32.exe which is signed by microsoft and still happily downloads and executes script code from remote servers.
Unfortunately, not even this approach will work. No. To be totally safe, you have to whitelist by digest of the exe and command-line arguments. Which basically means that you have to know the the OS works internally.
Unfortunately, not even this approach will work. No. To be totally safe, you have to whitelist by digest of the exe and command-line arguments. Which basically means that you have to know the the OS works internally.
In general, I think that approach would need one other change to either prevent “core” resources (e.g. firmware, kernel, system binaries) from being modified or having a fail-safe way to reset those files back to a trusted base state. Otherwise it'll just hit the same problem where many users will approve any request described as necessary to run the free game/movies/porn/etc. and lose control of their computer.
This is basically what Apple shipped in OS X 10.11 where you can trust third-party developers but System Integrity Protection (https://support.apple.com/en-us/HT204899) tries to limit the damage that even getting root can cause.
This is basically what Apple shipped in OS X 10.11 where you can trust third-party developers but System Integrity Protection (https://support.apple.com/en-us/HT204899) tries to limit the damage that even getting root can cause.
You touch on a rather huge issue in the industry. So many IT companies out there are hiring one or two (if they're lucky) "Security Professionals" that are responsible from endpoint security, to managing the SIEM to digging deep into every popcorn noise that their IDS/IPS makes. There's a lot of boxes to check and there's nothing like hiring one poor soul to check them all in the name of compliance, while their board (Who reluctantly hired the poor guy or gal) is deeply shrouded inside a false sense of "Hey we are HIPAA compliant for another year!" security.
As a lawyer who deals with contracts, one of my major pet peeves is the stupid warranty that requires a party to use "industry-standard virus detection software". I'm fairly certain that none of the lawyers who insist on that language know anything about IT security.
When I was first getting into IT, I was trying to configure a low-end 'soho' cisco modem. It had a java-app webpage for configuration... which only ran on windows/IE (couldn't be forced to load elsewhere), was missing two-thirds of the device's capabilities, and was just generally awful.
I asked a netadmin friend for some advice, and he said "Oh, that thing is just there to tick boxes - no techie would ever use it. 'Does it have a GUI configurator?' -> box ticked". Meanwhile the techies just configured the modem like any other bit of cisco equipment: via the console.
I asked a netadmin friend for some advice, and he said "Oh, that thing is just there to tick boxes - no techie would ever use it. 'Does it have a GUI configurator?' -> box ticked". Meanwhile the techies just configured the modem like any other bit of cisco equipment: via the console.
I don't think we have any antivirus on our work computers. It works out ok because, after all, we don't have internet either. It's amazing how hard it is to run a malicious executable when you can't get them onto your computer...
(of course I've no doubt there are plenty of people smart enough to write their own but that's not the concern)
(of course I've no doubt there are plenty of people smart enough to write their own but that's not the concern)
Http://www.bromium.com is a new take on security providing full sandboxes for applications.
Having heard of Sandboxie as well, this whitepaper was interesting, see link at https://labs.bromium.com/2013/07/23/application-sandboxes-a-...
See also:
https://news.ycombinator.com/item?id=8257250 (DrawBridge & commentary)
Oh and the follow-up in the comments: (Regarding Sandboxie reconfiguration mitigating some of the attacks)
> I tested with SBIE4 and indeed it is quite different and has security improvements over what we tested in our report. Great job by the author!
> However, our kernel exploits still work flawlessly – no issues there. You need to remember that SBIE3/4 (and other similar app sandboxes) are kernel mode drivers and they will always have some fundamental limitations. Blocking access to specific DLL’s is far from a practical use case as you have no idea where the next patch is going to come (BTW similar capability has been available in HIPS technology for several years and very few people use it)
> Once time permits, we’ll probably update our analysis with the latest SBIE4. However, this is not our core focus, the idea of this research was to simply enumerate the fundamental limitations of application sandboxing tech.
If you've read this far, you might also be interested in other Bromium research: https://labs.bromium.com/category/research/
Of course, folks might be first in line to point out that nothing's perfect, and user-error can get around a lot of security... Nobody would argue sandboxing is an excuse to not patch systems, except with antivirus you might increase your attack surface while trying to detect attacks with something that can't be easily circumvented. Trade-offs. Can you trust sandboxing to prevent damage from malware or do you need some kind of warning that something strange is going on?
See also:
https://news.ycombinator.com/item?id=8257250 (DrawBridge & commentary)
Oh and the follow-up in the comments: (Regarding Sandboxie reconfiguration mitigating some of the attacks)
> I tested with SBIE4 and indeed it is quite different and has security improvements over what we tested in our report. Great job by the author!
> However, our kernel exploits still work flawlessly – no issues there. You need to remember that SBIE3/4 (and other similar app sandboxes) are kernel mode drivers and they will always have some fundamental limitations. Blocking access to specific DLL’s is far from a practical use case as you have no idea where the next patch is going to come (BTW similar capability has been available in HIPS technology for several years and very few people use it)
> Once time permits, we’ll probably update our analysis with the latest SBIE4. However, this is not our core focus, the idea of this research was to simply enumerate the fundamental limitations of application sandboxing tech.
If you've read this far, you might also be interested in other Bromium research: https://labs.bromium.com/category/research/
Of course, folks might be first in line to point out that nothing's perfect, and user-error can get around a lot of security... Nobody would argue sandboxing is an excuse to not patch systems, except with antivirus you might increase your attack surface while trying to detect attacks with something that can't be easily circumvented. Trade-offs. Can you trust sandboxing to prevent damage from malware or do you need some kind of warning that something strange is going on?
Oh my god mailing the report to them crashed their mail server. You can't make this stuff up.
I didn't understand that part at first, but it is hilarious.
They apparently use their own product on their email server, which unpacked the POC by guessing the password of the archive, scanned the uncompressed file and triggered the bug that was being reported. Love it !
They apparently use their own product on their email server, which unpacked the POC by guessing the password of the archive, scanned the uncompressed file and triggered the bug that was being reported. Love it !
> On Linux, Mac and other UNIX platforms, this results in a remote heap overflow as root in the Symantec or Norton process.
Is this a real thing? Hands up, who runs Norton on Linux? Is it because it is used as a central back-end / service to check attachments. But then why does it run as root?
Is this a real thing? Hands up, who runs Norton on Linux? Is it because it is used as a central back-end / service to check attachments. But then why does it run as root?
At least in the card processing space, one of the PCI requirements is "5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers)."
The phrase "commonly affected" is the place to make an argument here, but I'm sure people take the easy option of just running an antivirus.
The phrase "commonly affected" is the place to make an argument here, but I'm sure people take the easy option of just running an antivirus.
Right, and that requirement loses all of its nuance when it lands on someone's checklist as "anti-virus software on PCs and servers".
When my company gets asked why we answer "no" to that question, my canned response is "because anti-virus software would almost certainly be the most exploitable vector on our systems".
When my company gets asked why we answer "no" to that question, my canned response is "because anti-virus software would almost certainly be the most exploitable vector on our systems".
Just run ClamAV
Many times a retailer will install a whitelisting solution as a "compensating control".
[deleted]
Many enterprise environments mandate AV on Linux platforms including workstations.
It's not uncommon to run vendor x's anti-virus on the PC/desktops and vendor y's anti-virus on the mail systems (often not running a Microsoft operating system).
Ok, this is some dark humor:
It looks like the researcher sent a proof of concept zip file to symantec which was pw protected with a common password. Symantec's system then tried the common password, extracted the zip, scanned the POC code inside, which crashed their own system.
From the report: Project Member Comment 1 by [email protected], Yesterday (42 hours ago)
I think Symantec's mail server guessed the password "infected" and crashed (this password is commonly used among antivirus vendors to exchange samples), because they asked if they had missed a report I sent.
They had missed the report, so I sent it again with a randomly generated password.
It looks like the researcher sent a proof of concept zip file to symantec which was pw protected with a common password. Symantec's system then tried the common password, extracted the zip, scanned the POC code inside, which crashed their own system.
From the report: Project Member Comment 1 by [email protected], Yesterday (42 hours ago)
I think Symantec's mail server guessed the password "infected" and crashed (this password is commonly used among antivirus vendors to exchange samples), because they asked if they had missed a report I sent.
They had missed the report, so I sent it again with a randomly generated password.
>
This is a remote code execution vulnerability.
I understand how this vulnerability can be used to corrupt the heap, as it's writing more data than malloc was asked to reserve, so it can overwrite memory allocations from other parts of the program.
I am curious as to how would one create a reliable remote code execution exploit out of this? I guess that one may be able to find a function pointer somewhere to overwrite, and use that to control program flow to your shellcode - but as this is dynamically allocated memory, could it not be adjacent to pretty much anything?
How would an attacker approach making a remote code execution exploit, given these constraints? Is it possible in practice or more theoretical?
(I'm not challenging this classification, just would really like to know how this works!)
I understand how this vulnerability can be used to corrupt the heap, as it's writing more data than malloc was asked to reserve, so it can overwrite memory allocations from other parts of the program.
I am curious as to how would one create a reliable remote code execution exploit out of this? I guess that one may be able to find a function pointer somewhere to overwrite, and use that to control program flow to your shellcode - but as this is dynamically allocated memory, could it not be adjacent to pretty much anything?
How would an attacker approach making a remote code execution exploit, given these constraints? Is it possible in practice or more theoretical?
(I'm not challenging this classification, just would really like to know how this works!)
"scan engine is loaded into the kernel (wtf!!!)"
That rings a bell -- I remember back in the early/mid 2000s, when the AV vendors started to port their products to Mac OS X. The darwin (OSX) kernel/driver mailing lists seemed to get a lot of questions from AV devs, asking how to do things in the kernel that really, really, really should not be in the kernel. It was at that point I resolve to never run any AV software.
That rings a bell -- I remember back in the early/mid 2000s, when the AV vendors started to port their products to Mac OS X. The darwin (OSX) kernel/driver mailing lists seemed to get a lot of questions from AV devs, asking how to do things in the kernel that really, really, really should not be in the kernel. It was at that point I resolve to never run any AV software.
Well, at least they handled it fairly quickly - it was submitted on May 6th and according to
https://www.symantec.com/security_response/securityupdates/d...
a patch was deployed and should be automatically downloaded. I'm running Symantec and LiveUpdate did download some stuff but nowhere it says whether version 20151.1.1.4 is already there or not. Ah well
Operating systems need to offer better protection. I am tired of buying the OS then having to go buy the equivalent of anti-lock breaks, air bags and seat belts from a third party.
This is just a stupid, lazy way of doing business.
This is just a stupid, lazy way of doing business.
What specific protections do you have in mind?
[deleted]
If you've been following Tavis Ormandy's work, you already know this:
I've long argued that the only sustainable security strategy is education.
If you're a developer/engineer/consultant/rockstar/ninja/etc. and never bothered to learn how to write secure software, start here: https://paragonie.com/blog/2015/08/gentle-introduction-appli...
Anti-Virus software is a trash-fire.
I've long argued that the only sustainable security strategy is education.
If you're a developer/engineer/consultant/rockstar/ninja/etc. and never bothered to learn how to write secure software, start here: https://paragonie.com/blog/2015/08/gentle-introduction-appli...
Couldn't agree with you more. Every tool in the world won't help you defend against a user with privileges being phished into doing something inappropriate.
And, even for those of us who are somewhat savvy, having refreshers to remind you things like never, ever, click on a link in an email, navigate through the website instead. Be hyper cautious about opening every attachment, period. Ensure that your system firewall is set to default deny, and think twice about opening up rules when an application demands them - and consider making them temporary rules. (Little snitch is great for that). Make sure the OS is updated routinely....
With that said, operating systems could help us out a little by reducing the almost infinite number of threat surfaces that exist so that we can more easily audit our system. The sheer number of places that an auto-launching/malware/kernel extension can hide in OS X makes it next to impossible for me to figure out whether my system has been compromised - particularly if something is able to hide itself from Little Snitch.
And I won't even go into the insane number of network accesses that most applications want these days...
But yes, the only sustainable security strategy is education.
And, even for those of us who are somewhat savvy, having refreshers to remind you things like never, ever, click on a link in an email, navigate through the website instead. Be hyper cautious about opening every attachment, period. Ensure that your system firewall is set to default deny, and think twice about opening up rules when an application demands them - and consider making them temporary rules. (Little snitch is great for that). Make sure the OS is updated routinely....
With that said, operating systems could help us out a little by reducing the almost infinite number of threat surfaces that exist so that we can more easily audit our system. The sheer number of places that an auto-launching/malware/kernel extension can hide in OS X makes it next to impossible for me to figure out whether my system has been compromised - particularly if something is able to hide itself from Little Snitch.
And I won't even go into the insane number of network accesses that most applications want these days...
But yes, the only sustainable security strategy is education.
>> "You can't buy security, but you can learn it: http://decentsecurity.com/#/introduction/"
I think that's an incorrect standpoint to take when you factor in how technologically agnostic most folks are. I would better think of it as "security is default, but you can disable it if you really, really want it that way."
I think that's an incorrect standpoint to take when you factor in how technologically agnostic most folks are. I would better think of it as "security is default, but you can disable it if you really, really want it that way."
Security isn't the default, though. Specific example: SMTP.
I don't personally use AVs but they're useful for people who cannot be taught security.
There is a good amount of intuition that goes into it. Such vulns are relatively rare compared to the things they run into multiple times a day.
There is a good amount of intuition that goes into it. Such vulns are relatively rare compared to the things they run into multiple times a day.
> I don't personally use AVs but they're useful for people who cannot be taught security.
Attackers agree. Even outside of the context of remotely exploitable ring-0 vulnerabilities that require no user interaction, they provide people with a false sense of security.
> Such vulns are relatively rare compared to the things they run into multiple times a day.
That's because criminals are fat and happy with lower hanging fruit. Why bother exploiting AV software when you can just trick people and the AV software is already ineffective at stopping e.g. ransomware?
Attackers agree. Even outside of the context of remotely exploitable ring-0 vulnerabilities that require no user interaction, they provide people with a false sense of security.
> Such vulns are relatively rare compared to the things they run into multiple times a day.
That's because criminals are fat and happy with lower hanging fruit. Why bother exploiting AV software when you can just trick people and the AV software is already ineffective at stopping e.g. ransomware?
decentsecurity.com is an effort of InfoSec Taylor Swift (@SwiftOnSecurity). If you can deal with the occasional Cortana fanfic & some Linux trolling it's definitely worth a follow.
Can't help but wonder if attackers already knew this. There seems to be quite a few bugs found by taviso in antivirus code in the past few months, which has got to either attract attackers to look more closely at it or possibly break their existing exploits. Either way, it's frightening!
Increasingly, my non-computer savvy family members ask me what kind of anti virus they should use. I used to pick one to tell them since I know they aren't as cautious as I am, but I am not sure I have a good answer for them any more. Has AV software reached the point that a lay user is more vulnerable with it than without it?
Increasingly, my non-computer savvy family members ask me what kind of anti virus they should use. I used to pick one to tell them since I know they aren't as cautious as I am, but I am not sure I have a good answer for them any more. Has AV software reached the point that a lay user is more vulnerable with it than without it?
My current recommendation when I get asked that question is not to bother with any third-party AV and just use Windows 10 with Windows Defender (unless they're on OS X anyway). When I'm asked to set things up, I switch their default browser to Chrome (or Firefox for those who "don't like Google"), add uBlock Origin and use Click-To-Play for plugins (which, surprisingly, isn't much of an inconvenience once you block ads anyway). If someone asks for extra protection, I add OpenDNS Umbrella to the setup ($20/year for 3 devices), which is a nice additional layer of defense. Chromebooks are also a great option if someone's not doing much other than email, web browsing and such.
My other recommendation is to use a tablet for things like online banking. (Yes, even an outdated Android tablet is probably less likely to catch malware that will steal your money than an average computer.)
My other recommendation is to use a tablet for things like online banking. (Yes, even an outdated Android tablet is probably less likely to catch malware that will steal your money than an average computer.)
This is the first time I have heard of OpenDNS Umbrella. I just gave it a try (they have a free trial) and it's really nice--after some simple configuration you pretty much just set your router's DNS to OpenDNS and then your DNS requests are both monitored and lightly protected.
The product is geared towards medium-to-large networks so it's a little hard to find the prosumer $20/yr plan. Here's a link if anyone else is interested: https://www.opendns.com/enterprise-security/threat-enforceme...
The product is geared towards medium-to-large networks so it's a little hard to find the prosumer $20/yr plan. Here's a link if anyone else is interested: https://www.opendns.com/enterprise-security/threat-enforceme...
It's been years since desktop signature-based antivirus provided a significant improvement to security. Every time there's a cryptolocker outbreak, I see people scrambling to make decisions like "we need to replace McAfee with Kaspersky", as though they feel that's their answer.
When you try telling an insurance auditor "we have a whitelisting application, nothing runs unless I've approved it, products like Symantec Endpoint are unnecessary in that environment", you first get a confused look, then you hear "ok, so you're DON'T meet the minimum basic security requirements, let me write that down".
It's gotten to a point that it's actively part of Intel Security's advertising, with a recent partner promotion pushing to "help your clients meet their compliancy requirements". The brochure never even mentioned actually securing anything, just how it ticked various boxes.