integrity checking is the process of comparing the current state of stored data and/or programs to a previously recorded state in order to detect any changes (and so it sometimes called change detection)...
generally the state information that gets used in the comparison is in the form of a hash of some kind and ideally the baseline state that the current state is compared to was generated when their was nothing wrong with the system...
the reasoning behind this technique is that for anything bad to happen on a system something on that system must change, so then detecting when something bad has happened simply requires detecting changes that shouldn't have happened...
integrity checking is generally considered one of the strongest anti-malware controls, since it has the potential to detect and locate all persistent malware intrusions along with any additional persistent changes to the system that malware could have made... unfortunately it is a detective, rather than preventative control - it can only detect when prevention has failed and so is only good after the fact... it also places a fair bit of burden on the user to be able to tell good changes from bad ones...
back to index
2 comments:
Integrity checking has more problems than the fact that it detects problems only after they occur and leaves to the user to decide whether they are problems. In some cases (e.g., slow infectors) it is impossible in principle to say whether the change occurred because of a virus or not - because the virus infects only when there is a change. For more information, see my paper on this subject:
http://www.people.frisk-software.com/~bontchev/papers/attacks.html
holy cow, that was fast... i hadn't even finished the post that prompted me to make this one...
i'm aware of the problem of slow infectors, actually... i kinda think the part about users not being able to decide if the change is good or bad covers that case (if it's impossible to decide as you say, then it stands to reason that users probably won't be able to decide)...
that being said, you should be able to identify a change by a slow infector if you know what the outcome of the change was supposed to be (ie. the hash of the updated file doesn't match the one published on the update site)...
Post a Comment