Sandbox vs HIPS

Semantics have absolutely nothing to do with it. Just because a product blacklists something other than code, doesn't mean it's not using a blacklisting approach. Simple as that.

 

Still after the behavior is blocked or the code is cut the information generated by the actions taken is usually ensued by a listing of the executable checksums with a transmission to home base for inclusion into a list for general distributions.

This is pretty standard protocols for the vast majority of anti malware capable to intercept unknown bugs. End result is the same in most cases.

 

Hmm this is somewhat misleading...

Yes, as others have mentioned blacklisting does not mean just AV signatures. You can blacklist behavior as well as specific strings. It does not mean that the likes of TF isn't doing blacklisting of behavior.

I guess what the above is trying to say is that there is a difference between a HIPS having a blacklist that recognises certain specific processes/files as bad and is in their database with a name, and one that uses some intelligent algorithm based on observing behavior...

I think a smart hips would blacklisting behavior (allow is default), while a dumb one would be whitelisting behavior (deny is default).

So far all this is mostly standard.

A more interesting question is whether sandboxing of the sandboxie and defensewall type is white listing or black listing... http://anti-virus-rants.blogspot.com/2007/07/three-preventative-paradigms.htmlSome [/url] would say it is neither...

But then again the argument that it allows all behavior except certain behavior would make it blacklist.... I don't...

 

Well you are mistaken, whether something is whitelist or blacklist does not depend on how much it watches, but on how it handles what is filtered...

For example a dumb hips would query/block any attempt to set a registry key *EXCEPT* ones that are explictly allowed. This is whitelisting for sure, because the default is block except known good.

The smart hips would be the reverse it would generally allow any attempt to set a registry key *UNLESS* some other condition was met , so by default it allowes except for "known" bad.

With the former, the software tries to answer "is it good? if yes (condition, white listed process = yes), allow, if no block". With the later it asks "is it bad? (condition, meets a certain profile = yes), if yes, block, if no allow.

I don't know why people are so confused...

 

Neither. They are based on "isolate everything what is potentially dangerous from the rest of the system". So, sandboxing is a sandboxing, not blacklisting or whitelisting.

Kurt was a little bit wrong- there are four types of a HIPS solutions, he missed a classical HIPS that are based on "anomalies detection" paradigm.

 

I think you are confusing HIPS with the virtualisation of specific user environment during a sand boxed sessions. Meaning a secondary protected user space is created and used to fool programs into thinking it is the "Real" Environment and as such control and track all system modifications performed by executables confined to this virtual space.... I cant think of any listing required here other than the system components included in the protected virtual work space...

 

Virtualization is just one of the isolation mechanisms of the sandbox HIPS. Other one is based on a policy-based restrictions.

 

Possibly there is no "right or wrong" answer... You can define and carve things up anyway you want, as long as you are consistent within your rules...

 

Yes, sure.

 

Of course, this only makes sense as one cant "Protect" the virtual or real environment without policy-based restrictions enforced within the kernel, in fact in Windows I think it is the only method available outside of within specific program environments which are self defined within specific tolerated parameters. This is what I meant by "I cant think of any listing required here other than the system components included in the protected virtual work space..." being protected by specific policies.

However my comment was in direct relation to how lists W/B are used by AV's or process control utilities to monitor executables behaviors as well as HIPS in comparison to Sandbox visualizations method. Personally I see a rather clear distinction between the two.

 

which is blacklisting... generally speaking, anomalies are bad... you may need to encounter more than one before you raise an alarm, but it's still a list of bad things you normally want to avoid...

edited to add:
unless you're talking about anomalies in the sense of something never seen before by software that learns what's normal by watching day-to-day behaviour for a specific period of time and adding all that behaviour to a whitelist which it later uses when the learning period is over... then it's whitelisting (obviously)...

 

Interesting topic... My friend has told me that Feb edition of Maximum PC is testing "next gen applications that can defeat the new wave of evil super bugs". In the article he's told me that a range of HIPS and Sandbox technologies were tested. I've not managed to see the article but the results were as follows:

APPROVED:

ThreatFire
DriveSentry
BufferZone Pro

NOT APPROVED:

ZoneAlarms Forcefield
Norton Antibot

I think there may be more on the list but it's was passed via an IM. My view is that if the underlying technology is strong then both technologies are a good barrier to threats.

~interact

 

I don't see any "ranges" for the sandboxes. The only "non-beta" sandbox here is BufferZone. No SandboxIE, DefenseWall, GesWall, SafeSpace?

 

evil super bugs ? You mean evil super threats or malwares, but I'm sure that super bugs in these next gen applications will allow these super threats on my system.

Only 5 softwares tested ? Poor test, if you ask me. Must be a commercial test.

 

EA,

Re-read my post; "I think there may be more on the list....." there may be even something from Faronics in the test which will keep you happy.

~interact

 

I never thought so many people will start to eloborate the pholosophy behind the terms: black and white listing. I will like to keep it simple, rather than having a PhD in art of software categorization/ nomencalture.

And yes, pls don,t black list me for these remarks!

 

Actually with most of us, you are on our whitelist.

 

Oh really?..... Thanks!

 

Hi Kurt!

Sorry, missed your post- definitely I need get more sleep.

In fact, anomalies detectors are both blacklisting (for the behaviours you have "deny" rule) and whitelisting (for the behaviours you have "allow" rules) + additional "ask user" subsystem if some potential dangerous behaviour is not within both of the lists. That is why usually I position classical HIPS into the separate category.

 

no worries... i would have missed this entire thread if not for referral traffic...

if it uses both blacklisting and whitelisting i just say that... nothing wrong with combining techniques (in fact there's a lot to gain from it)...

 

I'm also a big fan of hybrids as they usually contain the best features of all methods concerned. Besides why re-invent the wheel, always best simply to make it more efficient...

 

@Ilya Rabinovich

I don't think it would giving away the farm (secrets) here, but you have done a great job with DF at uncovering and addressing areas of the O/S that always needs looking after.

Isn't that somewhat of a task to go over so many facets of the Windows O/S internal instructional codes that relay so many signals (interactions), with it's files, permissions and such? I mean i lurk Rootkit forums for example and occasionally land on even student sites where their projects are to discover even new methods of subverting at user/kernel level, and man theres a HUGE list of lines of code they work on just to divert just enough attention in order to obstruct or otherwise invade undocumented sections of Windows.

This has to be just as much a task for the security developer to address as it seems it is for the experimenter to uncover/cover areas which where their end is to target available vectors by malware intrusions.

 

I dont know. HIPS overall may, or do, provide better protection then a AV, but because of user error still can be just as unforgiving as a AV in these cases. Sandboxing to me is the only sure bet, not perfect bet, but sure bet for the average user to stay secure without having to have a 5th grade education.

 

Windows NT OS family is very complex from the point of view of different possible attack vectors and completely undocumented functions and data packets. To program any reliable security software, you need know a lot of them plus be a good reversing skills to make you software working with undocumented structures and data packets.

 

Yes I agree, this thread is very boring and actually I´m surprised that no one has mentioned the fact that most of the posts are way off topic, they should be moved IMO.

On topic:

You would think that, since sandboxes are designed specifically for restricting apps, they would do a better jobs than HIPS, and of course they already do it straight out of the box while with HIPS you will have to make the rules yourself. But it all comes down to the areas/behavior that they are monitoring, see this topic:

https://www.wilderssecurity.com/showthread.php?t=197356