Parsh

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Parsh

  • Rank
    New Member

Profile Information

  • Gender
    Male
  • Location
    : 7 Islands of Bombay

Recent Profile Visitors

583 profile views
  1. Maybe "until" is better suited in place of "unless" in the first line. Your point is totally valid and the set of malware using the same certificate will be blocked. Those cyber-criminals will have to lighten their pockets to continue .. What I am focusing is about the window between 'some or many users falling pray to malware signed with legit certificates' and 'Emsisoft team blacklisting the certificate to prevent further infections'. That sure sounds paranoid. I'm sure you all would have discussed about the pros and cons about it and eventually let an option down due to user confusion. But the alert thresholds need not be the same for the signed and the unsigned files, should they be? There can be some threshold (or such standards can be developed and continuously evaluated), dissimilar to the threshold for unsigned/semi-trusted/untrusted files, for different types of actions taken by the signed files that most likely indicate a malicious nature and present an alert to those "paranoid mode" users. Kaspersky System Watcher evaluates any potentially malicious actions by adding a score for each such action and reduces score for any following safe action sequence..thus forming a threat score. The process is considered malicious when a certain threshold is reached. This one is known to produce quite less FPs even with the "trust digitally signed files" disabled - just an example (I'm aware that handling might differ from Emsisoft, but they can be a mid-way). Very famous and critical apps that are known to be trusted, that can result in instabilities if blocked while issuing an alert, can be whitelisted in BB, however the others can be partially monitored - all this to reduce possible instabilities and this will include research you know that, researching problems is the way for solving such known hindrances instead of dropping the good options. The devs ofcourse know things better, I'm a normal user recently switched to Emsisoft and am concerned about some points. So please do not take this in a wrong way. What's the point of a strong BB in the case some signed malware can trash my system/encrypt my valuables before you blacklist the certificate manually? Such occurrences cannot be said to be rare, can these be? The other users will sure be protected after the blacklisting. To continue, famous apps presented with an alert will most likely be an FP while an unknown/non-famous app (though trusted due to the signed nature) being alerted about raises suspicion for sure. Again, do realise that we're talking about the paranoid users only and with an added assumption that the alerts for such digitally signed files can be optimized from your side. The paranoid mode can have a warning for the better. In short, the paranoid mode could be improved. The rest and most of users should have no issues by being oblivious to/staying away from this mode. The above points can be pondered over or re-evaulated, or the concept can directly be trashed again without possible strategy-based improvements.
  2. Thank you Arthur and Elise for your answers. The use of (kindof) collective intelligence is fascinating. I ended up sensing the same concern. Sure the intricate details of BB etc. are better kept contained. However regarding the certificate issue, it boils down to this: Users are mostly not protected from malware carrying a valid/legitimate certificate unless the certificate is manually blacklisted (like the Philadelphia or the Global-Imposter seen recently), be it the same day or later (not all malware get reported). Until the manual blacklisting, any loss of system stability and data caused by such malware is indirectly allowed and the Behavior Blocker, that is integrated to be the strength of the product against unknown and zero-day threats, is rendered ineffective due to limited or no monitoring of such malware. Call it a tradeoff between protection and ensuring minimal FPs. All this when a simple option (you know) could possibly prevent havoc atleast for the users who're aware about how to use it. The default can be kept to "Trust valid signed files". I hate comparing, but there are a few vendors that provide this option. Since some options like - enabling or disabling "Automatically allow programs with good reputations" (disabling which can result in increased FPs/user decisions needed) are provided ... why cannot an option be included to enable/disable trusting such signed files? It's then up to the user like in case of some other already available options as discussed above. Thank you for reading through the suggestion.
  3. From what I get, an app carrying a digital signature 'trusted by Emsisoft' are fully trusted. What difference will Firewall (or EIS version) make in the crafting of rules? @GT500 can you provide your answer over here? I would like to know about this scenario. 3 queries to breakdown: Does the Emsisoft client check if the certificate is valid+verified and then consider it 'trusted' (again, only in case the certificate is trusted by Emsisoft data) OR only the validity of the certificate trusted by Emsisoft is enough? If there is a malicious file sporting a certificate trusted according to Emsisoft (probably stolen), and the certificate is valid and verified, the malware will run without any monitoring unless the certificate gets blacklisted? Somewhat contrasting the 2nd point, I find that processes of quite some 'Trusted' programs are monitored, partially or fully. Can you explain on what basis is this determined (whether to monitor fully, partially, or not)? Thank you!