Prevx1: Choosing between it and Process Guard

Hi george75,

That's correct. Essentially, whenever the Prevx1 agent sees a process violate an area of the system being watched, it raises an event and queues it for sending to the central DB. Whether the event actually gets sent depends on whether the agent has already sent that event before. I cover this in more detail below. It is this reporting that allows us to build up the picture of the behaviour of a process. Most of our heuristic decisions are performed in the central database and are based on these events, their frequency and speed of propagation etc.

Yes. It allows us to see whether an event is occurring when certain security products are in place, active, out-of-date etc. It allows us to see when we are blocking files that other AV's aren't and vice-versa.

Correct. This is the view the agent had "at the time of the event". It is based on the latest set of local determinations that the agent had at that time.

The determination is that last received from the central DB in reponse to any event that was sent about a given process. Take this stream of events for thoeretical example. Event1 is the process being created - Agent sends unknown, DB returns Unknown. Event2 is process being Run - agent sends Unknown (allowed by user), DB returns Unknown. Event3 is process copying itself to the system restore area - agent sends Unknown (allowed by user), DB returns Unknown. Event 4 is process adding itself as a RunKey pointing to restore area copy - agent sends Unknown (allowed by user), DB returns Bad. On receipt of Bad, agent terminates process and adds file to Holding Cell. So, as you can see the central DB response depends on the events it has received for a given process.

Each request to the central DB includes your license key and a unique number created on installation. This allows us to group data according to license key for use in family and corporate account management screens, and ensures that only licensed agents receive correct central DB responses. Once the license key has been validated this data is ignored by the rest of the database. The actual event data is not tied to the license key or unique machine ID. This means that we don't have any way of knowing which machine(s) an event has been seen on, we only know that for event Z, process X has behaviour Y and has been seen on N systems.

Each process has a PX5 unqiue identifier. It is a unique identifier, not a signature in the AV sense. So when, for example, explorer.exe executes notepad.exe, the "event" is a combination of the PX5 of the actor (explorer.exe), the behaviour (EXEC) and the PX5 of the victim (notepad.exe). Our heuristics are based on the behaviour of a PX5. Normally the actor PX5 is the process that the behaviour is seen in, but there are exceptions. In the case of MSIEXEC.EXE, the active .MSI file is used. In the case of RUNDLL32.EXE, the running DLL's PX5 is used. etc. In essence, we work our "what is actually doing this" rather than "which process do we see this in".

The agent generates a PX5 for each process/file referred to in an event. The actual algorithm used depends on the nature of the file and allows us to build up relationship pictures of different files; for example, we know when two programs share the same executable code.

Both.

Your rules are local to your agent and are not shared with the central DB. The agent remembers which events have been sent to the central DB so that it can reduce the number of events sent. It would be crazy to send an HTTP out event for your browser every-time, so its only sent once.

All events are sent to the central DB and remembered locally if its the first time they have been seen. This way if an app that we thought was good suddenly started bahaviing maliciously, we would know about the new behaviour straight away and the central DB can review its determination again.

Yes, This allows us to distinguish between programs that start and stop as apposed to those that continue to run in the background. Its also used inside the agent to control the end on installation tracking and for cache tidy-up on process termination.

Ok. I understand your confusion. The agent keeps a local copy of every event that it has ever sent (its stored in paws.cache). This allows the agent to know if it has ever sent this event before. If it hasn't, it sends it to the DB and stores the fact that it has sent it to the DB. If it has sent it before, it checks the time that it last received a determination for both the actor and victim PX5 in the event. If either of those times are more than a day ago, the event is sent to the central DB (to allow the determination to be refreshed if it has changed). So, the decision as to whether to send an event to the DB is made by the agent, not the DB itself.

The central DB is essentially acting like a web server. As each request comes in is increments the count for that event, looks up the current determination for the actor and victim and returns it to the agent. When it increments the count for the event, that action may automatically change the determination for the actor and/or victim, so the response to the agent is the determination after the event has been handled.

The event storage and processing does not hold any personally identifiable information. We have no way of knowing which agent sent the event in.

That is correct, though we do examine currently running processes on start-up to ensure we terminate anything that got on when we weren't running; e.g. early in the boot cycle, or if the user had closed down Prevx1 for any reason.

We have the mechanism for two reasons: First, it allows us to pass a PX5 and its determination to ALL agents when they connect to the server to pass in any event; we may do this if a fast propagating worm came out (for example). Secondly, it allows us to respond to an event with a block of PX5's and their determinations. Let's say for example, that you're building a new PC and you are about to install OpenOffice. We could wait for all the events to be raised by your agent for the OpenOffice components, this may mean you receiving execution queries for each component the first time they run. Alternatively, when your agent contacts the central DB for a determination for the OpenOffice installer, we could respond with a Good status and at the same time provide your agent with a list of all the known PX5s that form part of that installation; i.e. it allows us to pre-place determinations for a well-known product.

These "extra" PX5s and determinations are sent in reponse to an agent request. They could be a broadcast event to ALL agents, or they could be an installer-package relating to the event that has been requested. We don't maintain a list of which PX5s have been seen by a particular agent in the central DB, that list is mainained locally on the agent, so it knowns when something is new (to your PC). All communication is agent initiated, we have no way of contacting agents.

The PX5 is a unique number for a specific program. The number generated for it on your agent is identical to the number generated for it on my agent. This is not therefore personally identifyable information. We hold a copy of the PX5s for all the processes detected on your system during the scan on your system - there is no such collection on the central DB. The central DB only holds the existance of a program with that PX5, and an aggregation of all the events that we have seen that PX5 perform as an actor or be performed on as a victim.
Clearly each event contains the path/filename of each particular PX5 on your system. However, we deliberately take steps to remove personally identifyable information from those paths. For example, take the Internet Explorer cache. This is typically stored under c:\documents and settings\username\local settings\temporary internet files\content.ie5\8hexdigits\. When we send an event relating to a file under this area, we normalize this path to be %cache%\content.ie5\?? ?? ?? ??\. In this way, we remove the personally identifyable information (your user ID) and have a single common path for all installations.

Correct.

Not if we can help it. See the bit above about path normalization. We want the central database to be as small as possible, with as few filenames and path names as possible. We are interested in gathering the behaviour of PX5s (programs usually) so as to determine whether they are good or bad.

This is noted on the website that sits infront of our central DB. It examines the license key passed in each event request, checks to see if it is a corporate or family license, and if so records the PX5 if it is unknown or Bad in a seperate DB. If the license key is a trial license or an individual license it doesn't record anything. Only owners of family or corporate licenses can see this data, and they can only see their own data. Once an unknown PX5 changes to Good, it is removed from this view. In the corporate/family admin site, we also let you define your own profiles and change their modes; beyond our standard ABC, Pro and Export.

No. We aren't keeping an inventory of the websites visited. From our perspective a website URL is just another PX5. It just happens that its file is a page (beginning PG: ) and its path is a web host and path. The reason we see the website at all is because the Prevx1 agent substitutes the URL for the browser in the event. We will only ever see a web-site address if that address either caused a buffer overflow in your browser (reverse exploit attack) or because it caused an executable file download - be it openly or through a drive-by-download.
If a URL is currently Unknown it will be listed in the family/corporate view of unknown PX5s for their license owners to see. For individual license holders and trial license holders no data is stored.

We've actually managed to automate a great-deal, but in essence you are correct. The big difference between traditional AV and what Prexv1 does in its Community IPS (as we like to call it) is that you can make decisions using community data without needing to actually obtain a piece of malware and test it on a bence. Prevx1 agents are all effectively bench-testing every process they ever see.

We believe that in general the Prevx1 community will be better protected against emerging malware threats than those with traditional AV. Depending on the structure of a PX5 recieved even the first agent to see it may be told that PX5 is Bad. For example, say you have a mutating virus that changes its size, version details, filenames, folders but each instance contains a common piece of executable code. Now if the Prevx1 central DB has (say) 100 instances of PX5s with this common code and they are all marked Bad. The central DB can automatically mark the 101'th instance as Bad purely because it shares the same code.

You are correct that with Prevx1 you have a tradeoff. Details of the programs you have, their locations, filenames etc do get passed to the Prevx1 central database - though they are not tied back to you. Prexv1 is by its very nature a community collectively sharing information about what both good and bad programs do. The benefit you get from joining the community is immediate protection from the point that the central DB holds a Bad determination for a PX5. You don't have to remember to update your AV or wait for them to produce a signature. The moment that you receive a Bad file, be it through email, P2P, web or any other means, it will be blocked as soon as it attempts to execute.

Even if you are the very first person to see a new threat, you will be asked whether or not you wish to run it. You may say no at this stage and it wont be allowed to run, but the central DB is now aware of the new file. If lots of users suddenly start seeing the same new file, the central DB could decide to make it Bad purely from its rate or propagation. Commercial program updtaes (even windows update) don't propagate as fast as a worm after all.

Hope this helps,

Ghiser1

 

Is Prevx1 R light?

Is Prevx1 R light? Wich one is lighter, Prevx1 or PG?

 

Dear ghiser1:

Thank you for such a detailed response. I am sorry for my delay in responding to it.

I think that your reply gives ample information to any security expert to enable him or her to make an informed judgement as to the security and privacy issues in Prevx1. For that I am grateful. I also see that the local agent is initiating the request to the central data base on the basis of the PX5's combined into events, so that there is no necessity for Prevx to keep detailed information on user programs and surfing activity on its central data base (with the exception of family and corporate accounts), which was my initial fear.

I have two further comments to make: First, it is indeed a matter of a trade-off between the security benefits of your centralized database and its HIPS heurstics, over against the risks that might accrue from uploading all that data to your central data base. Each security analyst will make his own judgement on that. I myself am uneasy, but I don't have anything objective to report as a basis for that unease.

Second, it seems to me that you might consider shifting the mini-databases for the family and corporate licenses from your central servers to the local administrator account (family users) or local security chief account/computer (corporate users). I don't see on the face of it that Prevx has a technical need to keep those databases on its central servers. This is something, it seems to me, that a security chief at a potential corporate user might wish to discuss with you.

In any event, I thank you: it is seldom that we find such a responsible reply anywhere, much less on an Internet forum.

With best wishes--

george75

ps: In regard to the previous post that raises the question as to which is lighter, Prevx1 or Process Guard, my guess is that Process Guard would be lighter, just simply because Prevx1 does a lot of things. But that is my crude opinion.

 

Re: Is Prevx1 R light?

i would consider PG lighter but of course it has fewer features.

 

Ghiser1,

(I'm really glad this discussion came up...)

How does the Prevx1 feature set compare to ProcessGuard. Does it run in kernel mode? Will it protect from the following (and, if so, how):

- Code Modification
- Process Termination
- Rootkits
- Global Hooks
- Password Stealers
- Keystroke Loggers
- Disabling Windows File Protection

Spiff5000

 

Anybody running Prevx-R with NOD - Outpost - Process Guard? any problems?

I thought I'd give it a go on the basis it could be just right for my dad.

It didn't run very well on my system - long periods where it just sucked all of the CPU - both the agent and the console app

 

Starfish_001

Without being an expert, I think that your problem is running Process Guard and Prevx simultaneously.

george75

 

Thanks yes you might be right - although NOD tend to clash more on my system

I might try on another system at the weekend

Did you give up PG or PREVX?

 

I'm running Prevx1 and NOD32 without any issues.. of course every system is different, but I haven't seen any others with problems between the two.

To answer your previous question, Prevx1 does include protection for all the same things (and a whole lot more), however it's approached differently. Mainly it's preconfigured for strong security without interfering with normal operations, and won't alert for any known programs. These are also continually being improved and built upon. One of the main differences is that you have malware analysts continually watching trends and marking the malware for detection. Since some of the protection features are server-side, the effect is basically that they can add features in real-time as they are discovered, and you have several layers of protection features.

 

Thanks - I'll another go at the week end in a strip down FD snapshot

 

I have tested Prevx1 and I do not like the approach of the app, personally I like to know what´s going on on my system. The only way to do to that is to notify me about activities of all software installed, even the trusted ones. Also, it flagged certain files as malware while they were not, not a good thing. I also do not like the whole community thing, same thing with CyberHawk, so Prevx1 is not for me.

 

Not sure what you mean, Rasheed.. In Pro mode it will alert you to most actions by only unknown programs, Expert mode will alert you to actions by known or unknown programs, and then you also have the notification option to show you anything by any process as it happens (it's shown me some stuff I would never have known about otherwise, such as programs that call home). Then if you want to know just how one process acts, you can set the Program Monitor to show you just what that one process is doing. None of those fit your requirement for letting you know what's going on on your system? I don't think I know of any other app that will give you that much, unless you want to run Filemon and Regmon (by SysInternals) full time..

 

PG , Prevx , NOD , and Outpost here . NOOOOO PROBLEM

 

Thanks for the info Notok, I have to admit that it did not test this app thoroughly it was more sort of a "first impression test", I did the same thing with WinPooch, CyberHawk and DefenseWall for the record. But first impressions are important, I also did not like the fact that it had to do a scan at startup. Of course I can understand why such a product wants to do this, but why not let me choose if I want to or not?

But anyway, I did see that you could change the mode, and Prevx1 covers quite a lot, that´s very nice. Perhaps you can give me a few screenshots of alerts that you will get if certain activities are performed on your system? Btw, you mentioned about apps phoning home, a good firewall will also intercept this if I´m correct. But to stay on topic, I might consider buying this app if it works the way I want it to work, and it does seem to cover a whole lot more than PG.

 

Yep had Online Armour on system that seems to interfere.

PG , Prevx , NOD , and Outpost now work fine