Does WSA Essentials only scan on access with its cloud database? Under what circumstances will WSA scan a file or executable with its cloud database? I'm assuming WSA Essentials Identity Protection uses something similar to a behavior blocker from within the browser & also limits connections for a particular page, but WSA does not scan HTTP, HTTPS, FTP, SMTP, or POP3 protocols with its cloud database. Am i correct in my understanding of how WSA works. WSA does not scan HTTP, HTTPS, FTP, SMTP, or POP with its cloud AV. Is this correct? I'm trying to learn the fine mechanics of how WSA works so I can make an educated decission on which security products would best compliment WSA for my particular needs. I work with sensitive data, and need to make sure i'm covering all posible entry points that could be exploited. It would be great if I could obtain some detailed documentation or be advised by someone that is very knowledgable on the fine mechanics of WSA.
Thank You in advance!!
cutting_edgetech
Solved
What protocols does WSA Essentials scan?
Best answer by Kit
Much QA work to do on Mondays, but I've been asked to step in here and answer.
So the first thing that's critical is to define a certain set of stuff...
All of those protocols you list are, literally, just that: Transport protocols. All they do is move data from one place to another. The reason this is important to know is very simple: For a threat to do anything, it needs to make it onto the CPU. It literally needs to get into memory and have the execution pointer target it. Just getting onto the system via a transport protocol won't actually compromise the system. For example, I could send a threat at a computer by sending a UDP stream to its IP, but the computer would completely ignore it.
So, HTTP as a transport protocol for example would need to download the file, and then successfully execute it. Whether this involves tricking the user into running it or trying to use a Java exploit or Flash bug to run it, the execution is still the important part.
That means that looking at any protocol is completely unnecessary in the event that the CPU execution pointer itself is shielded. Everything you named is literally just a way to try to get file onto the computer, and running it has to happen afterwards. Since the running part is the critical part, and since that is checked when it tries to start to happen, it's blocked if it's a threat.
Then also, any file that is written is scanned. As well, any process that ends up with a code change of untrusted library injected into it will be monitored and scanned, so anything that completely fails to hit the disk will still be checked. And finally, the network scanning works on an endpoint basis, which is protocol-agnostic. Network connections are accounted for regardless of whether it is HTTP, SMTP, or even something like DNS Tunnelling.
That being said, the CONTENTS of network connections with the exception of HTTP are not inspected specifically because that puts an undue load on the system and slows things down for no good reason. Since the code has to get onto the system and run in order to do anything bad, and since we check it when it hits the file system or when it tries to run, checking it at the edge of the network would be redundant. Thus, one can say that we worry about all protocols and yet worry about none, because the way you appear to be thinking of it we don't look at, but we do look at it in a more thorough manner on both sides of the protocols themselves.
The main thing I'd recommend as the best supplement to safety is patching. Keep -all- software up to date and don't include unneeded network software on the system. Java, Flash Player, and Adobe Reader are major intrusion sources, as are things like Skype. Any unpatched program with a network facing or that can be invoked by a process with network facing is a security risk.
Hopefully that answers your question, but if I was not clear at any point or you have further questions, let me know.
View originalSo the first thing that's critical is to define a certain set of stuff...
All of those protocols you list are, literally, just that: Transport protocols. All they do is move data from one place to another. The reason this is important to know is very simple: For a threat to do anything, it needs to make it onto the CPU. It literally needs to get into memory and have the execution pointer target it. Just getting onto the system via a transport protocol won't actually compromise the system. For example, I could send a threat at a computer by sending a UDP stream to its IP, but the computer would completely ignore it.
So, HTTP as a transport protocol for example would need to download the file, and then successfully execute it. Whether this involves tricking the user into running it or trying to use a Java exploit or Flash bug to run it, the execution is still the important part.
That means that looking at any protocol is completely unnecessary in the event that the CPU execution pointer itself is shielded. Everything you named is literally just a way to try to get file onto the computer, and running it has to happen afterwards. Since the running part is the critical part, and since that is checked when it tries to start to happen, it's blocked if it's a threat.
Then also, any file that is written is scanned. As well, any process that ends up with a code change of untrusted library injected into it will be monitored and scanned, so anything that completely fails to hit the disk will still be checked. And finally, the network scanning works on an endpoint basis, which is protocol-agnostic. Network connections are accounted for regardless of whether it is HTTP, SMTP, or even something like DNS Tunnelling.
That being said, the CONTENTS of network connections with the exception of HTTP are not inspected specifically because that puts an undue load on the system and slows things down for no good reason. Since the code has to get onto the system and run in order to do anything bad, and since we check it when it hits the file system or when it tries to run, checking it at the edge of the network would be redundant. Thus, one can say that we worry about all protocols and yet worry about none, because the way you appear to be thinking of it we don't look at, but we do look at it in a more thorough manner on both sides of the protocols themselves.
The main thing I'd recommend as the best supplement to safety is patching. Keep -all- software up to date and don't include unneeded network software on the system. Java, Flash Player, and Adobe Reader are major intrusion sources, as are things like Skype. Any unpatched program with a network facing or that can be invoked by a process with network facing is a security risk.
Hopefully that answers your question, but if I was not clear at any point or you have further questions, let me know.
I should have clarified ealier that I do not need to know how the cloud itself works.I' already have a sound understanding of the cloud. I just need to know the protocols scanned locally. I hope that makes my question a little simplier. Sorry for being confussing.
Much QA work to do on Mondays, but I've been asked to step in here and answer.
So the first thing that's critical is to define a certain set of stuff...
All of those protocols you list are, literally, just that: Transport protocols. All they do is move data from one place to another. The reason this is important to know is very simple: For a threat to do anything, it needs to make it onto the CPU. It literally needs to get into memory and have the execution pointer target it. Just getting onto the system via a transport protocol won't actually compromise the system. For example, I could send a threat at a computer by sending a UDP stream to its IP, but the computer would completely ignore it.
So, HTTP as a transport protocol for example would need to download the file, and then successfully execute it. Whether this involves tricking the user into running it or trying to use a Java exploit or Flash bug to run it, the execution is still the important part.
That means that looking at any protocol is completely unnecessary in the event that the CPU execution pointer itself is shielded. Everything you named is literally just a way to try to get file onto the computer, and running it has to happen afterwards. Since the running part is the critical part, and since that is checked when it tries to start to happen, it's blocked if it's a threat.
Then also, any file that is written is scanned. As well, any process that ends up with a code change of untrusted library injected into it will be monitored and scanned, so anything that completely fails to hit the disk will still be checked. And finally, the network scanning works on an endpoint basis, which is protocol-agnostic. Network connections are accounted for regardless of whether it is HTTP, SMTP, or even something like DNS Tunnelling.
That being said, the CONTENTS of network connections with the exception of HTTP are not inspected specifically because that puts an undue load on the system and slows things down for no good reason. Since the code has to get onto the system and run in order to do anything bad, and since we check it when it hits the file system or when it tries to run, checking it at the edge of the network would be redundant. Thus, one can say that we worry about all protocols and yet worry about none, because the way you appear to be thinking of it we don't look at, but we do look at it in a more thorough manner on both sides of the protocols themselves.
The main thing I'd recommend as the best supplement to safety is patching. Keep -all- software up to date and don't include unneeded network software on the system. Java, Flash Player, and Adobe Reader are major intrusion sources, as are things like Skype. Any unpatched program with a network facing or that can be invoked by a process with network facing is a security risk.
Hopefully that answers your question, but if I was not clear at any point or you have further questions, let me know.
So the first thing that's critical is to define a certain set of stuff...
All of those protocols you list are, literally, just that: Transport protocols. All they do is move data from one place to another. The reason this is important to know is very simple: For a threat to do anything, it needs to make it onto the CPU. It literally needs to get into memory and have the execution pointer target it. Just getting onto the system via a transport protocol won't actually compromise the system. For example, I could send a threat at a computer by sending a UDP stream to its IP, but the computer would completely ignore it.
So, HTTP as a transport protocol for example would need to download the file, and then successfully execute it. Whether this involves tricking the user into running it or trying to use a Java exploit or Flash bug to run it, the execution is still the important part.
That means that looking at any protocol is completely unnecessary in the event that the CPU execution pointer itself is shielded. Everything you named is literally just a way to try to get file onto the computer, and running it has to happen afterwards. Since the running part is the critical part, and since that is checked when it tries to start to happen, it's blocked if it's a threat.
Then also, any file that is written is scanned. As well, any process that ends up with a code change of untrusted library injected into it will be monitored and scanned, so anything that completely fails to hit the disk will still be checked. And finally, the network scanning works on an endpoint basis, which is protocol-agnostic. Network connections are accounted for regardless of whether it is HTTP, SMTP, or even something like DNS Tunnelling.
That being said, the CONTENTS of network connections with the exception of HTTP are not inspected specifically because that puts an undue load on the system and slows things down for no good reason. Since the code has to get onto the system and run in order to do anything bad, and since we check it when it hits the file system or when it tries to run, checking it at the edge of the network would be redundant. Thus, one can say that we worry about all protocols and yet worry about none, because the way you appear to be thinking of it we don't look at, but we do look at it in a more thorough manner on both sides of the protocols themselves.
The main thing I'd recommend as the best supplement to safety is patching. Keep -all- software up to date and don't include unneeded network software on the system. Java, Flash Player, and Adobe Reader are major intrusion sources, as are things like Skype. Any unpatched program with a network facing or that can be invoked by a process with network facing is a security risk.
Hopefully that answers your question, but if I was not clear at any point or you have further questions, let me know.
Kit - Prior Webroot Quality Assurance / Prior Webroot Escalation Engineer
1 person likes this
Thank You Wkit! My appoligies for taking up your time for QA! I'm well aware that a threat can cause no damage until it is run in the memory or written to the disk. I understand the protocols I mentioned above are only entry points to transport data to the system.. Its my own belief that when possible the threat should always be blocked before it has a chance to run in the memory or be written to the disk. I also understand that the method used by WSA has been designed to have the least amount of overhead on system performance, and to achieve compatibility with other AV's. So I believe what you have informed me is that executable are only checked upon execution, and if they exhibit malicious behavior then they are blocked from executing. The threat is then deleted or quarantined depending on the user''s configuration. I thought this was the way in which WSA operated, but I wanted to make sure I understood correctly. If i'm misunderstanding then just point out my misconceptions in another post, but I believe you have answered my questions for the most part. I would like to learn more about identity shield though.
Thank You,
cuttingedgetech
Thank You,
cuttingedgetech
+56Hi cutting_edgetech,
Nice to see you here from Wilders and Welcome! Here is some reading on Identity Shield I hope you find your answers in the meantime as Kit is a busy guy but happy to help! ;)
http://www.webrootanywhere.com/sah_Identity_Protection.asp?n=About_Identity_protection
Cheers,
TH
Nice to see you here from Wilders and Welcome! Here is some reading on Identity Shield I hope you find your answers in the meantime as Kit is a busy guy but happy to help! ;)
http://www.webrootanywhere.com/sah_Identity_Protection.asp?n=About_Identity_protection
Cheers,
TH
@cuttingedgetech wrote:Emphasis above is mine.
Thank You Wkit! My appoligies for taking up your time for QA! I'm well aware that a threat can cause no damage until it is run in the memory or written to the disk. I understand the protocols I mentioned above are only entry points to transport data to the system.. Its my own belief that when possible the threat should always be blocked before it has a chance to run in the memory or be written to the disk. I also understand that the method used by WSA has been designed to have the least amount of overhead on system performance, and to achieve compatibility with other AV's. So I believe what you have informed me is that executable are only checked upon execution, and if they exhibit malicious behavior then they are blocked from executing. The threat is then deleted or quarantined depending on the user''s configuration. I thought this was the way in which WSA operated, but I wanted to make sure I understood correctly. If i'm misunderstanding then just point out my misconceptions in another post, but I believe you have answered my questions for the most part. I would like to learn more about identity shield though.
Thank You,
cuttingedgetech
They are checked when they are written to the disk as well.
Performing deep packet inspection has a severe impact on network performance, by the way. A good example is a competing security program* that performs deep packet inspection in the sense that it (attempts to) looks at the contents of all incoming HTTP and insecure POP3. Please note: As soon as TLS is involved, whether it be HTTPS or secure POP or anything similar, no security program can "legitimately" look at the contents.
Anyway, I performed testing across a gigabit network connection with a decent system on the client end. With no security installed, downloading and saving 20 GB of various-sized files, mostly legitimate with a tiny sprinkling of threats, from a LAN webserver clocked in at about an average of 450mb/s. Downloads were performed with up to five in parallel via HTTP.
With WSA, the CPU load increased by 6% on average and download speed was still 450mb/s, while it triggered on the threats when they were downloaded and removed them, while legitimate transfers were not interrupted.
With the other security software, the download speed dropped to a lovely 22mb/s and the process that was performing the downloads was killed when it wrote its first threat, destroying the remaining downloads. While 32mb/s is still a decent rate as most people have substantially less than that on their internet pipe, I, for example, have a 100mb/s internet pipe, so the deep packet inspection would have substantial impact on my network performance.
It really is a trade-off. It's possible to check everything, everywhere, all the time, and try to keep even the possibility of a threat from coming close to the HDD because it's caught at the network layer, but that has a severe performance hit. WSA was designed specifically to work at the singular choke point for the overall protection, but it will still take a look at things in front of that choke point when they are saved. With deep packet inspection, the end result is "You don't get infected". With WSA, the end result is "You don't get infected". The difference is that WSA's protection allows your computer and network to run faster. Something can come across the network and be saved to the drive before it is caught**, however that doesn't matter really because until it executes, it's inert.
* We're not in the business of slamming the competition, so the other security software shall remain unnamed.
** Since we do perform endpoint inspection of network connections, there's still a good chance for it to be stopped before getting to the drive.
Edit: Spell Checking.
Kit - Prior Webroot Quality Assurance / Prior Webroot Escalation Engineer
1 person likes this
Thanks for the welcome TripleHelix! I'm happy to be here! Thank you for the link for Identity Protection. I'm getting ready to read it now
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.