1 / 24

Preventing Data Leakage via Email

This project aims to prevent data leakage and address the issue of sending emails to the wrong recipients by developing a system that detects and warns users of potential addressing mistakes. The proposed solution includes a plug-in for email clients, a middleware, and a server, all working together to ensure secure and accurate email communication.

mella
Download Presentation

Preventing Data Leakage via Email

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Preventing DataLeakage via Email

  2. Academic Advisor: Dr. Yuval Elovici Technical Advisor: PolinaZilberman Team Members: Dmitry Kaganov RostislavPinski Eli Shtein Alexander Gorohovski Web site: http://www.cs.bgu.ac.il/~grorhovs/project/Main

  3. Problem Domain • Most people who use e-mail communication can confirm that at least once they have sent an e-mail to the wrong recipient. • Modern business activities rely on extensive e-mail exchange. Email “wrong recipients” mistakes have become widespread. • The damage caused by such mistakes constitutes a disturbing problem for individuals but for organizations such mistakes may also cost a lot of money.

  4. Current Situation • Various solutions to this problem are continuously emerging. • Commercial products, such as Symantec, Websense, and McAfee aim to prevent data leakage via electronic communication channels. • Google provides to its users an application named "Got The Wrong Bob“

  5. Current Situation (cond.) • However, there is still no “silver-bullet” solution. • Many e-mail addressing mistakes are not detected. • In many cases correct recipients are wrongly marked as potential addressing mistake. ?

  6. Proposed Solution – Problem domain Host System core Plug-in Outlook Server Exchange server User Middle-ware Figure 1.1 – System architecture

  7. Proposed Solution – Software context System Core Log files Administrator's GUI Same computer Middle-ware Plug-in Server Data base Figure 1.2 – System Core architecture

  8. Functional requirements – Plug-in

  9. Functional requirements – Middle-ware

  10. Functional requirements – Server

  11. Functional requirements – Administrator’s GUI

  12. Non-Functional requirements • The delay in sending the e-mails should be linear to the size of the e-mail and not longer than half a minute. • The system should be able to detect no less than 94% of the illegal recipients. • The upper bound on false alerts (wrong alerts on legitimate recipients) is 30%. • The data between server and client must be encrypted with SHA1 encryption. • The system must be available and functional at any time.

  13. Non-Functional requirements (cond.) • The communication channel between server and client must be secured with SSL (Secure Sockets Layer). • The system disk space requirement must be linear to the number of e-mails sent\received. • The system should be able to sustain 2,000 client connections concurrently. • The system should be easily adaptable to other e-mail clients.

  14. User Profiles – The actors • The E-mail client – the e-mail client which the user uses to work with his e-mail account. It passes e-mails data to the plug-in, which is a part of our system. • The Exchange server – e-mail server of the organization. It gets all the e-mails sent by people from the organization, all the e-mails sent to people from the organization and delivers them to their target.

  15. User Profiles – The actors (cond.) • The Simple User – a person who uses the system. He can send e-mails, ignore the system’s recommendations, use the system’s recommendations to attach other users to the list of recipients of the e-mail, and mark e-mails as sent / received by mistake. • The Administrator – a person who configures the system. In addition to being a simple user, he is capable of configuring the system according to his desires, deal with groups of classifications, and dealing with sent e-mails that were considered by the system as leaks.

  16. Use Case Diagram Mark e-mail as got / sent by mistake Simple User Simple User Check e-mail validity <<Extends>> Send e-mail Add new user <<Extends>> Set systems’ configurations Administrator Administrator <<Extends>> Deal with mails marked by a question mark <<Extends>> <<Extends>> Log in to the system as a system administrator <<Extends>> Update users’ subject groups <<Extends>> <<Extends>> <<Extends>> E-mail client Remove existing user <<Extends>> <<Extends>> Add new subject group Exchange server Remove existing subject group Log out from the administrator mode

  17. Use Case 1 – Check e-mail validity • Primary actors: E-mail client, Simple user, Exchange server. • Description: The simple user checks the validity of an e-mail. • Trigger: The user clicks the "send" button (at the first time). • Pre-conditions: • 1. The plug-in is installed on the user’s e-mail account. • 2. The "middle-man" is installed on the user's computer. • 3. The server of the system is installed and runs on a server computer • 4. The network is working correctly. • 5. The e-mail is not empty. • 6. The list of the recipients is not empty.

  18. Use Case 1 – Check e-mail validity (cond.) • Post-conditions: • In case all the recipients are valid: • 1. The e-mail was sent to all of them. • 2. The system's database was updated. • 3. All the relevant information was written to the appropriate log files. • In case at least one of the recipients is invalid: • 1. The user gets on his monitor a list of users which the system advices to add to the recipients list (optionally). • 2. The user gets on his monitor a list of users which the system advices not to send them the e-mail.

  19. Purposed Solution – The Theoretical Model Link communication analysis • Every two users that exchanged emails in the past define a link, and all emails exchanged between these two users are associated with the link. • The classification of an e-mail with content c sent from s to r is performed as follows: the e-mail is compared with the link defined by the users s and r. If the received similarity score is lower than the link's threshold similarity score, then sending the e-mail is considered a potential leak. E-mail toclassify, e.g.query <s,r,c> Link's threshold Similarity score

  20. Group communication analysis • Assume Alice and Bob belong to agroup that communicates topic T, and Bob sends an email with content T to Alice. Alice won't be considered a wrong recipient, even if Alice and Bob have never exchanged communication with content T before. Orange circles represent the emails taken into account when classifying an email sent from Bob to Alice.

  21. Cascading the models Yes No No No Yes Yes • Apparently, cascading the group-based and link-based classifiers will take advantage of the “strong” points of both classifiers, and eliminate their “weak” points.

  22. And so the data continued to be safe and lived happily ever after…

More Related