# Defacement Detection with Passive Adversaries
## 2 Defacement Response
### Defacement Detection: Problem Definition  
From a practical point of view, defacement detection should raise an alarm and activate the reaction phase when a Web Site or an Application interface is \"not what it is supposed to be\". As such, it is an ill-defined problem, as there is no way to formalize a definition of what the page is supposed to look like. One could define accepted content based on a previously accepted reference page, or on some application image that has been separately stored (see, e.g., [10], and most of the commercial monitoring services [12]). However, the web site's pages will change often, and modification processes are normally outsourced to suppliers and system integrators, involving some complex CMS and corresponding authorizations to third parties. Hence, detection based on a separately maintained reference content, with an equality check, is practically impossible to implement and deploy in an enterprise context. At the same time, this very system could be attacked and made ineffective [14]: a hacker could take control of both the Web Site and of the CMS, or the client machines where users insert content changes could be compromised. Finally, active proxies could be targeted. We would then like to define a possibly defaced application as a system producing information that does not respond to one or both of the following criteria:  
* Matching a set of predetermined rules, e.g.,:
* including/excluding a set of keywords/images
* responding to semantic consistency [12]
* responding to a given graphical/content schema
* Response to some similarity criterion:
* it should be similar to a set of previously published or otherwise accepted content, and/or
* it should be different from known unwanted content, or from content samples that have been labeled as out of context. Whether this possibly defaced application actually is a defacement incident can only be assessed by human intervention. This could be labeled as a form of Turing test, and one could argue that no totally automated system can detect defacements without errors. In a relatively recent defacement incident, an international airport Web Site was changed, and departures were substituted with unlikely tropical destinations - indeed a difficult one for an automated defacement detection system. As a consequence, a reasonable detection/reaction approach for enterprise solutions can be heuristic and based on previously accepted content:  
* a current page version is downloaded using undeclared IP sources, hidden client types and randomized navigation patterns, so as to avoid so-called _differential defacement_[14], where an adversary tries to detect monitoring before defacement is enacted;
* a matching degree w.r.t. the above-mentioned predetermined rules is computed;
* a similarity value w.r.t. accepted and, possibly, unwanted pages is computed;
* an overall heuristic \"defacement degree\" is obtained;* if this number is above a given threshold, a SOC service is alerted, with possible human intervention. The threshold should be set based on available SOC budget, and on risk level considerations (e.g., in the context of ISO-27001 or other standards and regulations). The best automated detection system will yield low error rates: a small percentage of \"false positives\" (reducing SOC effort), and a very high percentage of alerts being fired when a real defacement has occurred (reducing risk). The ill-defined defacement detection problem can now be understood:
**Defacement**: the unauthorized change of a Web Site or a Web Application front-end, that introduces significant modifications, with important negative impacts for the reputation and the operations of the owner organization
**Defacement detection:**: the act of promptly realizing a defacement has occurred, followed by the generation of an alarm and a severity score  
A definition of what a \"significant\" modification should be depends on risk management choices, often based on business impact and regulatory context.