OK, great! I'm not a programmer but logically it seams feasible, that a program could tell you what is needed with commonly used apps anyway. Only if someone was willing to gather the information. The other ones probably would need to be setup by the user since there are literally *thousands* of them on the market. It's an intriguing idea, so let's do a little brainstorming to see how this could possibly work.
Logical layout - flow of data
Let's use explorer and flash again even though they are not be the best examples.
Windows Environment (Operations & Functions) - explorer.exe and flash.xxx asks to go out
|
| <- Data Flow (towards...)
|
CPF's companion: (IE is currently running in the sandbox)
Configurations: I was thinking the sandbox portion of the app is inside the firewall. You could think of it like putting a cube inside a cardboard box. The sandbox is the cube and inside that are running applications with their required components in a controlled environment. These associated components could be just the core ones or bare minimum that is required to initialize and run an app. (This would be how someone would know what is required) Then allow the user to add or block anything else that the app may use or something that may want to use an app in the sandbox. This reason is suggested because everyone's level of security is different and this is the only way I could think to accommodate such a wide range. Flash is not a requirement for IE to run. One may not be able to use a 'part' of IE if it is not running but you can still surf without it. (Can you tell I'm not a fan of flash? LOL) So flash could be a user's choice rather than listed as a required component. Explorer.exe is also not required but if it's not allowed then when you click on a hyperlink say from your email client or open a '.mht' file, you won't be able to make a connection. It's needed from the standpoint of what was mentioned but it is a parent app and is not apart of IE. It makes sense not to list it as a core part of the app and let the user add it. Otherwise, there might be too many overlapping programs, which could cause a problem.
Action requested: IE is running and say the user blocks flash and allows explorer. Since the firewall blocks flash before it reaches IE, there isn't a need to restart IE. It is here where I wonder if this idea can even be created. Because I think the way CPF works, it doesn't catch an alert until 'after' the dll joins the internet-based app. In order for this to work, it would need to be caught 'before' it joins, I would imagine anyway. Perhaps there may be a need to have 2 instances of IE running. One on the outside of the sandbox so one could receive the alert and one inside that is protected from any interruption. I'm not sure. This is why I was hoping a programmer would comment whether the idea is even feasible.
|
|<- explorer.exe: Approved Data Flow
|
CPF (normal operations are carried out)
I think this would give you what you want in regards to knowing what to let out or not. You also mentioned having the app deal with malware. Typically, that's wasn't the function of a software firewall when the concept was first created. Although, it has been expanded upon with the introduction of security suites. In a way, with the setup mentioned above and a few other features, it could deal with this to an extent.
For example: Say 'some.dll' (part of a trojan) you never seen before, wants to use iexplorer.exe to go out. Let's also assume that it's a new type that was just released and it's too new for your AV app to catch. The companion could check an internal list of approved components and it would find out that it's not listed. Hold that thought for a moment - going to sidestep.
Going to the firewall portion of the app. In CPF, the 'Turn On', 'Turn Off' and 'Learn Mode' are nice features. These are set to a global scope meaning it applies to all or nothing. Let's say these options are also in the companion but set to an individual scope. In other words, one app might be set to 'Turn On' while another is set to 'Learn Mode' and change their function a little.
The 'Turn On' setting could just approve items on the list, and if the component in question is not there then it could block by default. 'Learn Mode' could check the list for approval and if not listed then prompt the user for action. The purpose of these two is, someone may know what they want to approve or block with one app but may not know (or still learning) about another. The companion would grow as the user grows.
Getting back to the 'some.dll' that is part of a trojan. (I guess an exe file is needed too. I don't think the app could work from just a dll. But for simplicity sake, let's just use the dll) Before it can even reach iexplorer.exe which is currently running in the sandbox, it must get past the companion's firewall first. Just like the previous example. If IE were set to 'Turn On' mode, then the dll would be blocked by default. It wouldn't bother the user; it would just log the attempt. If IE were set to 'Learn Mode', then it would ask the user. Someone who runs a tight setup on their system, likely will block it because it's an unknown. Since the dll didn't get out, no harm is really done and your AV app would eventually take care of it when the update becomes available. This way a system is safe even when one doesn't know something harmful is present. It's an extra layer of security for preventive maintenance. Again, something was safely blocked without an interruption of the application.
Whew, that was a lot. I hope everything made sense. Sometimes the hardest thing about an idea is communicating it clearly with others.
One last thing you mentioned was about user interaction. Once the companion is setup to the user needs, eventually there should be very little interaction depending on how much someone installs new programs.
This is just one method, I'm sure there are several ways to set this up. What do you think kpc? Would that cover it or did I just run my mouth too much? LOL
Author