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. 

---

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

---

Hi 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

---

@cuttingedgetech wrote:

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

Emphasis above is mine.

 

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. 

---

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

---