Information Technology Reference
In-Depth Information
be provided as a corrective action. Clearly, this may raise the “annoyance” level of
the system forcing users to validate their email transmissions from time to time. The
issue is of course complex requiring a careful design to balance between the level of
security and protection an enterprise or enclave desires, the cost of repair of damage
to errant email events, with the potential annoyance internal users may experience to
prevent that damage.
We plan to study such issues in our future work after deploying MET in different
environments.
5
Tradeoffs: Security, Privacy and Efficiency
For wide deployment of an MET/EMT system, users and providers must carefully
study a number of tradeoffs regarding security and privacy of the user, and the value
and cost of the protection mechanism such a system may provide.
The MET system can be configured to extract features from the contents of emails
without revealing private information (e.g., aggregate statistics such as size, number
of attachments, distribution of letters in the body, or even the number of occurrences
of certain hot listed “dirty words”.). Identity information may be hashed using a one
way hash.
EMT's analysis may be entirely performed by hashing the identity of email ac-
counts and thus hiding personally identifiable information while still providing the
core functionality of MET. However, a large service provider may incur additional
expense of its email services if fielding an MET system to protect their customers.
The current set of models computed by EMT are a first cut using techniques that are
as light weight to implement and as informative as possible. More advanced modeling
techniques will likely incur additional cost. The cost may be offloaded from the pro-
vider's servers by pushing much of the computation and profiling mechanisms to the
user's client machine further protecting the user's privacy. This would offload ex-
pense, while also limiting the information the email service provider may see (al-
though of course they may still have the means of doing so).
Even so, ultimately the privacy of users must be considered, and is a matter of trust
between the email service provider and the user (perhaps ultimately governed by law
and regulation). The same trust relationship exists between banks and credit card
users, and telecommunication companies and their customers, and such trust has
benefited both parties; credit card fraud, for example, limits the liability and financial
damage to both parties due to fraud. We believe a similar trust relationship between
email providers and users will also benefit both parties.
As for security considerations, if EMT's analyses are performed at a user's client
machine, the profile data of the user would be subject to attack on the client, allowing
clever virus writers to thwart many of the core protection mechanisms EMT and MET
provide. For example, if a clever virus writer attacks the EMT user profile data on the
client platform (which is quite easy for some platforms), the virus may propagate
itself in a manner that is entirely consistent with the user's normal behavior, thus,
interestingly, hijacking or spoofing the user's behavior, rather than spoofing the user's
identity. EMT and MET would therefore accomplish nothing. This would therefore
argue for service providers to provide the needed resources in their email service to
