Electronic communication and collaboration services[1] such as Outlook.com, Skype, Gmail, Slack, and OneDrive carry valuable private and confidential communications that need protection. But these same services also provide a means for attackers to steal information or seize control of users’ computers for nefarious purposes, via viruses, worms, spam, phishing attacks, and other forms of malware.
Preventing the theft of user information and the dissemination of malware is a core feature of electronic communication and collaboration services. This requires significant processing of users’ communications and data both in-transit and after delivery. This processing can and should be done without compromising the user’s privacy or the confidentiality of their communications[2].
Message processing data flow:
To protect against malware distributed via electronic communications and collaboration systems such as email servers[3], the content follows a conceptually simple flow.
Starting with “A” the message is received by the recipient’s email service. The message’s envelope, as well as the message contents and any attachments, are passed on to the anti-malware portion of the email service (“B”) which determines whether or not the message is malware. Based on what the anti-malware service determines, the message is delivered to the user as appropriate (“C”). Some messages are determined to be malware with near certainty and are never delivered to the user. Instead they are deleted as quickly as possible[4]. Some messages are likely to be spam, however the service is not always certain. So the message is delivered to the user’s mailbox but into their spam/junk-mail folder. The remaining valid messages are delivered to the user’s inbox. The service can never determine with absolute certainty whether or not a message is malicious; it is always a probabilistic assessment. If the service is wrong either way; i.e. the user is exposed to malware or the user indicates that a message originally thought to be spam is not, the message may be added to a database of messages (“E”) used to train the next version of the anti-malware logic (“F”), thus permitting the system to “learn” over time and become more effective.
Clearly this entire process entails considerable processing of the messages. The types of processing are diverse and done in two key phases: message processing (“A” – “D”) and model building (“E” – “F”).
Anti-malware is particularly important for in-transit messages because attacks most typically enter the service through communications being transmitted. It is, however, also performed against already received and processed messages. As new attacks are identified – usually after the attack has been launched and some infected content has evaded the filters and been delivered to users – the anti-malware service is updated to defend against those attacks, and the service is rerun against recently delivered message to retroactively remove instances of said attack.
Processing message:
The types of processing done on messages to determine whether or not they are malicious include simple rules (e.g. messages without senders are likely not valid), reputations systems (messages from a certain set of IP addresses or senders are likely not valid, such as lists managed by the Spamhaus project[5]), digital thumbprints (comparing the thumbprint of the message or attachment to the thumbprints of known bad messages), honey pots (email addresses with no user and thus mailboxes that could never get any valid messages – anything delivered to them is spam or malware), and complex machine-learned models which process the contents of the message or the attachment[6]. As new forms of attack are encountered, new forms of defense must be quickly developed to keep users safe.
This requires processing of the message envelope, body, and attachment. For example:
Message envelopes indicate not only the message recipient but also the supposed sender, and the server path which the message followed to reach the recipient. This is critical, not only to determine the recipient (needed to ensure the message is delivered to the intended recipients), but also to determine how probable it is that the sender is who they claim to be. It is common for attackers to “spoof” a sender, i.e. pretend they are a certain sender even though they are not. Knowing the path taken by the message can help determine if it has been sent by a spoof sender. For example, if a message originates from a trusted sending service which verifies the identity of the sender, then passes through a series of trusted intermediate services to the destination, the probability that the sender has been spoofed is much lower.
Message bodies are among the most critical elements of the message which need to be processed to determine if the message is likely spam or a phishing attack. For example, text about “great deals on pharmaceuticals” is often indicative of spam. Without processing the body of the message, it is impossible to determine this. Attackers know that defenders watch out for such phrases, so they often try to hide them as text within an image. To the reader this looks similar, but defenders must run the images through optical character recognition algorithms to convert the images into text that can then be compared against a set of suspicious phrases. For example:
Another example of message body analysis is comparing the text of hyper-links to the URL. If a hyperlink’s text says “Click here to reset your Facebook password” but the URL points to “http://12345.contoso.com“, it is likely a phishing attack because Facebook password reset links should never be any URL other a correct Facebook one. Because most users do not check the URL before clicking on the hyperlink, it is important to protect them from such attacks. Without processing the message body, this is impossible.
It is equally important to analyze attachments; otherwise attackers use them to deliver malicious payloads or contents to users. Attachments can be executables that open a user’s computer to attacker control. They can also be phishing attacks with the mismatched hyperlink text and URL scenario we described above embedded into the attachment. Any attack in the body of a message can appear in an attachment, and attachments can include additional forms of attack.
Model building:
Model building is the portion of machine learning in which the logic that does the evaluation is updated. It is the “learning” part of the machine learning; where the evaluation algorithm is updated based on new data so that it produces the desired output, not only based on data and results it has previous seen and been trained on, but also based on any new data or results.
The entire computer science sub-discipline of machine learning is the science of learning algorithms, and of this training phase, so a full treatise is beyond the scope of this paper. Generally speaking however, learning algorithms for detecting malware can be developed that respect the privacy of recipients because what is necessary is an understanding of the attack and the pattern of the attack, not the victims of that attack.
Privacy: data protection and confidentiality implications
Protecting the personal data of both sender and recipients, and communications confidentiality, during message processing (“A” – “D” above) can be done without diminishing the efficacy of the anti-malware service because that service acts as a stateless function. The service process the message and creates new metadata indicating whether or not the message should be delivered, without retaining any knowledge of the contents of the message and without exposing the message to anyone except the intended recipients. The recipient’s communication service processes and accesses the content on behalf of the recipient; and it is the recipient’s expectation to be protected against spam and malicious communications.. Failing to process every user’s every message would expose the entire service, and all its users, to known infections, which would be irresponsible.
Protecting personal data and confidentiality during the model building phase (“E” – “F” above) is done by a selection of algorithms and approaches that preserve privacy and confidentiality, those in which personal data is not retained or exposed (for example, selection of privacy preserving machine learning feature vectors), by restricting the use of the communication to building anti-malware capabilities[7], or by building user-specific models which solely benefit that user. The first two techniques have been used historically, but the third is becoming increasingly common as users’ expectations of what qualifies as nuisance communications (i.e. spam) become more individualized[8].
Using communication data for model building in anti-malware capabilities is done without explicit user consent. Malware is an ongoing struggle between attackers and the people providing the communications safety service, with attackers trying to find ways to get messages past the safety service. As new attacks emerge the safety service must respond quickly[9], using as much information as is available (which often necessitates sharing information with the anti-malware elements of other services). Attackers are increasingly using machine learning to create and launch attacks[10], requiring defenders to respond in kind with increasingly advanced machine learning-based defenses. One way to do this is to automate the creation of new versions of the anti-malware model so the service quickly inoculates all users against new attacks. The effectiveness of anti-malware depends on knowing about, and inoculating all users against, these attacks. This data can be used without exposing personal data or compromising confidentiality. All users of a service, and the entire service itself, are at risk if we fail to constantly process content in order to detect new forms of infection for every user. Similar to failing to inoculate a few members of a large population against an infectious disease, failing to process all users against these attacks would be irresponsible and would ultimately put the entire population at risk.
For anti-malware it important to note that the sender is generally malicious, and unlikely to grant consent to build better defenses against their attack. Requiring consent from all parties will make it impossible for services to provide a safe, secure, and nuisance-free communications and collaboration environment for all.
[1] It is difficult to differentiate between communication and collaboration, or between messages and other collaboration artifacts. Consider a document jointly authored by many people, each of whom leaves comments in the document to express ideas and input. Those same comments could be transmitted as email, chats, or through voice rather than comments in a document. Rather than treat them as separate, we recognize collaboration and communication as linked and refer to them interchangeably.
[2] Privacy, protection of personal data and confidentiality are frequently treated as synonymous, but we draw a distinction. For the purposes of this paper we treat data protection as the act of protecting knowledge of who a piece of data is about, and confidentiality as protecting that information. For example, consider a piece of data that indicates Bob is interested in buying a car. Data protection can be achieved by removing any knowledge that the data is about Bob; knowing simply that someone is interested in buying a car protects Bob’s privacy. Protecting confidentiality is preventing Bob’s data from being exposed to anyone but him. In this specific instance, Bob may only be concerned with protecting his personal data. However, if the information related to Microsoft’s interest in buying LinkedIn, Microsoft would be very interested in protecting the confidentiality of that data.
[3] Henceforth in this paper we will refer to this as an email service, but it is understood that similar problems and solutions apply to other communication and collaboration services.
[4] A staggering 77.8% of all messages sent to an email service are spam, with 90.4% of them being identified as such with sufficient certainty to prevent them ever being delivered to users.
[7] Services like Office365 that provide subscription-funded productivity services to users are incentivized to preserve the confidentiality of user data; the user is the customer, not the product.
[8] To my daughter, communications about new Lego toys are not a nuisance, they are interesting and desirable. However to me they are an imposition.
[9] Today, a typical spam campaign lasts under an hour. Yet in that time it gets through often enough to make it worthwhile to the attacker.
Electronic communication and collaboration services[1] such as Outlook.com, Skype, Gmail, Slack, and OneDrive carry valuable private and confidential communications that need protection. But these same services also provide a means for attackers to steal information or seize control of users’ computers for nefarious purposes, via viruses, worms, spam, phishing attacks, and other forms of malware.
Preventing the theft of user information and the dissemination of malware is a core feature of electronic communication and collaboration services. This requires significant processing of users’ communications and data both in-transit and after delivery. This processing can and should be done without compromising the user’s privacy or the confidentiality of their communications[2].
Message processing data flow:
To protect against malware distributed via electronic communications and collaboration systems such as email servers[3], the content follows a conceptually simple flow.
Starting with “A” the message is received by the recipient’s email service. The message’s envelope, as well as the message contents and any attachments, are passed on to the anti-malware portion of the email service (“B”) which determines whether or not the message is malware. Based on what the anti-malware service determines, the message is delivered to the user as appropriate (“C”). Some messages are determined to be malware with near certainty and are never delivered to the user. Instead they are deleted as quickly as possible[4]. Some messages are likely to be spam, however the service is not always certain. So the message is delivered to the user’s mailbox but into their spam/junk-mail folder. The remaining valid messages are delivered to the user’s inbox. The service can never determine with absolute certainty whether or not a message is malicious; it is always a probabilistic assessment. If the service is wrong either way; i.e. the user is exposed to malware or the user indicates that a message originally thought to be spam is not, the message may be added to a database of messages (“E”) used to train the next version of the anti-malware logic (“F”), thus permitting the system to “learn” over time and become more effective.
Clearly this entire process entails considerable processing of the messages. The types of processing are diverse and done in two key phases: message processing (“A” – “D”) and model building (“E” – “F”).
Anti-malware is particularly important for in-transit messages because attacks most typically enter the service through communications being transmitted. It is, however, also performed against already received and processed messages. As new attacks are identified – usually after the attack has been launched and some infected content has evaded the filters and been delivered to users – the anti-malware service is updated to defend against those attacks, and the service is rerun against recently delivered message to retroactively remove instances of said attack.
Processing message:
The types of processing done on messages to determine whether or not they are malicious include simple rules (e.g. messages without senders are likely not valid), reputations systems (messages from a certain set of IP addresses or senders are likely not valid, such as lists managed by the Spamhaus project[5]), digital thumbprints (comparing the thumbprint of the message or attachment to the thumbprints of known bad messages), honey pots (email addresses with no user and thus mailboxes that could never get any valid messages – anything delivered to them is spam or malware), and complex machine-learned models which process the contents of the message or the attachment[6]. As new forms of attack are encountered, new forms of defense must be quickly developed to keep users safe.
This requires processing of the message envelope, body, and attachment. For example:
Message envelopes indicate not only the message recipient but also the supposed sender, and the server path which the message followed to reach the recipient. This is critical, not only to determine the recipient (needed to ensure the message is delivered to the intended recipients), but also to determine how probable it is that the sender is who they claim to be. It is common for attackers to “spoof” a sender, i.e. pretend they are a certain sender even though they are not. Knowing the path taken by the message can help determine if it has been sent by a spoof sender. For example, if a message originates from a trusted sending service which verifies the identity of the sender, then passes through a series of trusted intermediate services to the destination, the probability that the sender has been spoofed is much lower.
Message bodies are among the most critical elements of the message which need to be processed to determine if the message is likely spam or a phishing attack. For example, text about “great deals on pharmaceuticals” is often indicative of spam. Without processing the body of the message, it is impossible to determine this. Attackers know that defenders watch out for such phrases, so they often try to hide them as text within an image. To the reader this looks similar, but defenders must run the images through optical character recognition algorithms to convert the images into text that can then be compared against a set of suspicious phrases. For example:
Another example of message body analysis is comparing the text of hyper-links to the URL. If a hyperlink’s text says “Click here to reset your Facebook password” but the URL points to “http://12345.contoso.com“, it is likely a phishing attack because Facebook password reset links should never be any URL other a correct Facebook one. Because most users do not check the URL before clicking on the hyperlink, it is important to protect them from such attacks. Without processing the message body, this is impossible.
It is equally important to analyze attachments; otherwise attackers use them to deliver malicious payloads or contents to users. Attachments can be executables that open a user’s computer to attacker control. They can also be phishing attacks with the mismatched hyperlink text and URL scenario we described above embedded into the attachment. Any attack in the body of a message can appear in an attachment, and attachments can include additional forms of attack.
Model building:
Model building is the portion of machine learning in which the logic that does the evaluation is updated. It is the “learning” part of the machine learning; where the evaluation algorithm is updated based on new data so that it produces the desired output, not only based on data and results it has previous seen and been trained on, but also based on any new data or results.
The entire computer science sub-discipline of machine learning is the science of learning algorithms, and of this training phase, so a full treatise is beyond the scope of this paper. Generally speaking however, learning algorithms for detecting malware can be developed that respect the privacy of recipients because what is necessary is an understanding of the attack and the pattern of the attack, not the victims of that attack.
Privacy: data protection and confidentiality implications
Protecting the personal data of both sender and recipients, and communications confidentiality, during message processing (“A” – “D” above) can be done without diminishing the efficacy of the anti-malware service because that service acts as a stateless function. The service process the message and creates new metadata indicating whether or not the message should be delivered, without retaining any knowledge of the contents of the message and without exposing the message to anyone except the intended recipients. The recipient’s communication service processes and accesses the content on behalf of the recipient; and it is the recipient’s expectation to be protected against spam and malicious communications.. Failing to process every user’s every message would expose the entire service, and all its users, to known infections, which would be irresponsible.
Protecting personal data and confidentiality during the model building phase (“E” – “F” above) is done by a selection of algorithms and approaches that preserve privacy and confidentiality, those in which personal data is not retained or exposed (for example, selection of privacy preserving machine learning feature vectors), by restricting the use of the communication to building anti-malware capabilities[7], or by building user-specific models which solely benefit that user. The first two techniques have been used historically, but the third is becoming increasingly common as users’ expectations of what qualifies as nuisance communications (i.e. spam) become more individualized[8].
Using communication data for model building in anti-malware capabilities is done without explicit user consent. Malware is an ongoing struggle between attackers and the people providing the communications safety service, with attackers trying to find ways to get messages past the safety service. As new attacks emerge the safety service must respond quickly[9], using as much information as is available (which often necessitates sharing information with the anti-malware elements of other services). Attackers are increasingly using machine learning to create and launch attacks[10], requiring defenders to respond in kind with increasingly advanced machine learning-based defenses. One way to do this is to automate the creation of new versions of the anti-malware model so the service quickly inoculates all users against new attacks. The effectiveness of anti-malware depends on knowing about, and inoculating all users against, these attacks. This data can be used without exposing personal data or compromising confidentiality. All users of a service, and the entire service itself, are at risk if we fail to constantly process content in order to detect new forms of infection for every user. Similar to failing to inoculate a few members of a large population against an infectious disease, failing to process all users against these attacks would be irresponsible and would ultimately put the entire population at risk.
For anti-malware it important to note that the sender is generally malicious, and unlikely to grant consent to build better defenses against their attack. Requiring consent from all parties will make it impossible for services to provide a safe, secure, and nuisance-free communications and collaboration environment for all.
[1] It is difficult to differentiate between communication and collaboration, or between messages and other collaboration artifacts. Consider a document jointly authored by many people, each of whom leaves comments in the document to express ideas and input. Those same comments could be transmitted as email, chats, or through voice rather than comments in a document. Rather than treat them as separate, we recognize collaboration and communication as linked and refer to them interchangeably.
[2] Privacy, protection of personal data and confidentiality are frequently treated as synonymous, but we draw a distinction. For the purposes of this paper we treat data protection as the act of protecting knowledge of who a piece of data is about, and confidentiality as protecting that information. For example, consider a piece of data that indicates Bob is interested in buying a car. Data protection can be achieved by removing any knowledge that the data is about Bob; knowing simply that someone is interested in buying a car protects Bob’s privacy. Protecting confidentiality is preventing Bob’s data from being exposed to anyone but him. In this specific instance, Bob may only be concerned with protecting his personal data. However, if the information related to Microsoft’s interest in buying LinkedIn, Microsoft would be very interested in protecting the confidentiality of that data.
[3] Henceforth in this paper we will refer to this as an email service, but it is understood that similar problems and solutions apply to other communication and collaboration services.
[4] A staggering 77.8% of all messages sent to an email service are spam, with 90.4% of them being identified as such with sufficient certainty to prevent them ever being delivered to users.
[7] Services like Office365 that provide subscription-funded productivity services to users are incentivized to preserve the confidentiality of user data; the user is the customer, not the product.
[8] To my daughter, communications about new Lego toys are not a nuisance, they are interesting and desirable. However to me they are an imposition.
[9] Today, a typical spam campaign lasts under an hour. Yet in that time it gets through often enough to make it worthwhile to the attacker.
The following is provided from Microsoft Security and Compliance blogs at TechCommunity:
Electronic communication and collaboration services[1] such as Outlook.com, Skype, Gmail, Slack, and OneDrive carry valuable private and confidential communications that need protection. But these same services also provide a means for attackers to steal information or seize control of users’ computers for nefarious purposes, via viruses, worms, spam, phishing attacks, and other forms of malware.
Preventing the theft of user information and the dissemination of malware is a core feature of electronic communication and collaboration services. This requires significant processing of users’ communications and data both in-transit and after delivery. This processing can and should be done without compromising the user’s privacy or the confidentiality of their communications[2].
Message processing data flow:
To protect against malware distributed via electronic communications and collaboration systems such as email servers[3], the content follows a conceptually simple flow.
Starting with “A” the message is received by the recipient’s email service. The message’s envelope, as well as the message contents and any attachments, are passed on to the anti-malware portion of the email service (“B”) which determines whether or not the message is malware. Based on what the anti-malware service determines, the message is delivered to the user as appropriate (“C”). Some messages are determined to be malware with near certainty and are never delivered to the user. Instead they are deleted as quickly as possible[4]. Some messages are likely to be spam, however the service is not always certain. So the message is delivered to the user’s mailbox but into their spam/junk-mail folder. The remaining valid messages are delivered to the user’s inbox. The service can never determine with absolute certainty whether or not a message is malicious; it is always a probabilistic assessment. If the service is wrong either way; i.e. the user is exposed to malware or the user indicates that a message originally thought to be spam is not, the message may be added to a database of messages (“E”) used to train the next version of the anti-malware logic (“F”), thus permitting the system to “learn” over time and become more effective.
Clearly this entire process entails considerable processing of the messages. The types of processing are diverse and done in two key phases: message processing (“A” – “D”) and model building (“E” – “F”).
Anti-malware is particularly important for in-transit messages because attacks most typically enter the service through communications being transmitted. It is, however, also performed against already received and processed messages. As new attacks are identified – usually after the attack has been launched and some infected content has evaded the filters and been delivered to users – the anti-malware service is updated to defend against those attacks, and the service is rerun against recently delivered message to retroactively remove instances of said attack.
Processing message:
The types of processing done on messages to determine whether or not they are malicious include simple rules (e.g. messages without senders are likely not valid), reputations systems (messages from a certain set of IP addresses or senders are likely not valid, such as lists managed by the Spamhaus project[5]), digital thumbprints (comparing the thumbprint of the message or attachment to the thumbprints of known bad messages), honey pots (email addresses with no user and thus mailboxes that could never get any valid messages – anything delivered to them is spam or malware), and complex machine-learned models which process the contents of the message or the attachment[6]. As new forms of attack are encountered, new forms of defense must be quickly developed to keep users safe.
This requires processing of the message envelope, body, and attachment. For example:
Message envelopes indicate not only the message recipient but also the supposed sender, and the server path which the message followed to reach the recipient. This is critical, not only to determine the recipient (needed to ensure the message is delivered to the intended recipients), but also to determine how probable it is that the sender is who they claim to be. It is common for attackers to “spoof” a sender, i.e. pretend they are a certain sender even though they are not. Knowing the path taken by the message can help determine if it has been sent by a spoof sender. For example, if a message originates from a trusted sending service which verifies the identity of the sender, then passes through a series of trusted intermediate services to the destination, the probability that the sender has been spoofed is much lower.
Message bodies are among the most critical elements of the message which need to be processed to determine if the message is likely spam or a phishing attack. For example, text about “great deals on pharmaceuticals” is often indicative of spam. Without processing the body of the message, it is impossible to determine this. Attackers know that defenders watch out for such phrases, so they often try to hide them as text within an image. To the reader this looks similar, but defenders must run the images through optical character recognition algorithms to convert the images into text that can then be compared against a set of suspicious phrases. For example:
Another example of message body analysis is comparing the text of hyper-links to the URL. If a hyperlink’s text says “Click here to reset your Facebook password” but the URL points to “http://12345.contoso.com“, it is likely a phishing attack because Facebook password reset links should never be any URL other a correct Facebook one. Because most users do not check the URL before clicking on the hyperlink, it is important to protect them from such attacks. Without processing the message body, this is impossible.
It is equally important to analyze attachments; otherwise attackers use them to deliver malicious payloads or contents to users. Attachments can be executables that open a user’s computer to attacker control. They can also be phishing attacks with the mismatched hyperlink text and URL scenario we described above embedded into the attachment. Any attack in the body of a message can appear in an attachment, and attachments can include additional forms of attack.
Model building:
Model building is the portion of machine learning in which the logic that does the evaluation is updated. It is the “learning” part of the machine learning; where the evaluation algorithm is updated based on new data so that it produces the desired output, not only based on data and results it has previous seen and been trained on, but also based on any new data or results.
The entire computer science sub-discipline of machine learning is the science of learning algorithms, and of this training phase, so a full treatise is beyond the scope of this paper. Generally speaking however, learning algorithms for detecting malware can be developed that respect the privacy of recipients because what is necessary is an understanding of the attack and the pattern of the attack, not the victims of that attack.
Privacy: data protection and confidentiality implications
Protecting the personal data of both sender and recipients, and communications confidentiality, during message processing (“A” – “D” above) can be done without diminishing the efficacy of the anti-malware service because that service acts as a stateless function. The service process the message and creates new metadata indicating whether or not the message should be delivered, without retaining any knowledge of the contents of the message and without exposing the message to anyone except the intended recipients. The recipient’s communication service processes and accesses the content on behalf of the recipient; and it is the recipient’s expectation to be protected against spam and malicious communications.. Failing to process every user’s every message would expose the entire service, and all its users, to known infections, which would be irresponsible.
Protecting personal data and confidentiality during the model building phase (“E” – “F” above) is done by a selection of algorithms and approaches that preserve privacy and confidentiality, those in which personal data is not retained or exposed (for example, selection of privacy preserving machine learning feature vectors), by restricting the use of the communication to building anti-malware capabilities[7], or by building user-specific models which solely benefit that user. The first two techniques have been used historically, but the third is becoming increasingly common as users’ expectations of what qualifies as nuisance communications (i.e. spam) become more individualized[8].
Using communication data for model building in anti-malware capabilities is done without explicit user consent. Malware is an ongoing struggle between attackers and the people providing the communications safety service, with attackers trying to find ways to get messages past the safety service. As new attacks emerge the safety service must respond quickly[9], using as much information as is available (which often necessitates sharing information with the anti-malware elements of other services). Attackers are increasingly using machine learning to create and launch attacks[10], requiring defenders to respond in kind with increasingly advanced machine learning-based defenses. One way to do this is to automate the creation of new versions of the anti-malware model so the service quickly inoculates all users against new attacks. The effectiveness of anti-malware depends on knowing about, and inoculating all users against, these attacks. This data can be used without exposing personal data or compromising confidentiality. All users of a service, and the entire service itself, are at risk if we fail to constantly process content in order to detect new forms of infection for every user. Similar to failing to inoculate a few members of a large population against an infectious disease, failing to process all users against these attacks would be irresponsible and would ultimately put the entire population at risk.
For anti-malware it important to note that the sender is generally malicious, and unlikely to grant consent to build better defenses against their attack. Requiring consent from all parties will make it impossible for services to provide a safe, secure, and nuisance-free communications and collaboration environment for all.
[1] It is difficult to differentiate between communication and collaboration, or between messages and other collaboration artifacts. Consider a document jointly authored by many people, each of whom leaves comments in the document to express ideas and input. Those same comments could be transmitted as email, chats, or through voice rather than comments in a document. Rather than treat them as separate, we recognize collaboration and communication as linked and refer to them interchangeably.
[2] Privacy, protection of personal data and confidentiality are frequently treated as synonymous, but we draw a distinction. For the purposes of this paper we treat data protection as the act of protecting knowledge of who a piece of data is about, and confidentiality as protecting that information. For example, consider a piece of data that indicates Bob is interested in buying a car. Data protection can be achieved by removing any knowledge that the data is about Bob; knowing simply that someone is interested in buying a car protects Bob’s privacy. Protecting confidentiality is preventing Bob’s data from being exposed to anyone but him. In this specific instance, Bob may only be concerned with protecting his personal data. However, if the information related to Microsoft’s interest in buying LinkedIn, Microsoft would be very interested in protecting the confidentiality of that data.
[3] Henceforth in this paper we will refer to this as an email service, but it is understood that similar problems and solutions apply to other communication and collaboration services.
[4] A staggering 77.8% of all messages sent to an email service are spam, with 90.4% of them being identified as such with sufficient certainty to prevent them ever being delivered to users.
[7] Services like Office365 that provide subscription-funded productivity services to users are incentivized to preserve the confidentiality of user data; the user is the customer, not the product.
[8] To my daughter, communications about new Lego toys are not a nuisance, they are interesting and desirable. However to me they are an imposition.
[9] Today, a typical spam campaign lasts under an hour. Yet in that time it gets through often enough to make it worthwhile to the attacker.
Last September, we announced new capabilities in Office 365 Message Encryption that enable users to seamlessly collaborate on protected emails with anyone. This release included Do Not Forward an out-of-the-box policy that encrypts emails and Office attachments, and restricts the content and email from being forwarded, printed or copied.
Today, we are happy to share that we are releasing another out-of-the-box policy called encrypt only. With the encrypt-only policy, users can send encrypted email to any recipient, whether they are inside or outside the organization, and the protection follows the lifecycle of the email. That means recipients can copy, print and forward the email, and encryption will not be removed. This new policy provides more flexibility in the type of protection that can be applied to your sensitive emails.
This is valuable for organizations that want persistent encryption, but do not want to add additional restrictions. For example, a doctor looking to protect an email containing sensitive personal information, can apply the encrypt-only policy, and the patient receiving the email can easily consume the protected message regardless of their email provider, and forward that email to another trusted party.
With this new, flexible policy, users and admins can apply different levels of protection to best fit their data protection needs.
Read more to understand what the encrypt-only policy looks like and how to apply the policy.
How the encrypt-only policy works
The encrypt-only policy is an out-of-the box policy that can be used without additional configuration, and as the name suggests, only applies encryption to the email. You can apply the policy through end-user controls in Outlook or through automatic admin managed controls in the Exchange admin center. Users can apply this policy to individual emails through end-user controls in Outlook, and Admins can apply this policy automatically to any email that matches the set criteria through admin-managed controls in the Exchange admin center.
Customers that have enabled the new Office 365 Message Encryption capabilities will see the encrypt-only policy first through Outlook on the web and in the Exchange admin center under mail flow rules. Updates to Outlook for Windows and Outlook for Mac are planned for the coming months.
How to send an email with the encrypt-only policy in Outlook on the web
Users can apply protection with the encrypt-only policy by clicking on the protect button and changing the permissions to just encrypt. While the other options encrypt the message, the encrypt option will apply the encrypt-only policy to the message, therefore enabling recipients to forward, copy and print the message.
Applying this option will offer added flexibility for recipients to share the email with other trusted parties while encryption continues to persist and throughout the lifecycle of the email.
In Outlook on the web, users can click on the protect button to change the permissions of the email. Once a user clicks on protect, the users can click on encrypt, to only encrypt the email.Once the encrypt-only policy is applied, the user will see a notification that encryption has been applied.
How to apply the encrypt-only policy through Exchange mail flow rules
As an administrator, you can apply the encrypt-only policy automatically to emails that meet certain conditions by creating a mail flow rule. When you do this, email affected by the encrypt-only policy is encrypted in transport by Office 365.
You as an administrator can create new mail flow rule to automatically apply the encrypt-only policy to emails.
How to read encrypt-only email using Outlook on the web and Outlook mobile
Office 365 recipients can easily read and reply to emails that have been applied with the encrypt-only policy using Outlook on the web and Outlook mobile directly from the client.
Users can read the encrypted message natively directly in Outlook on the web and Outlook mobile.
The inline reading experience for Outlook desktop (Windows and Mac) will be available in the coming months. In the meantime, Office 365 users using Outlook desktop will see the encrypted mail as an html mail with an rpmsg_v2 attachment.
How to read encrypt-only emails for non-Office 365 users (on-prem, Gmail, and Outlook.com users)
Non-Office 365 users, receive an html mail with an rpmsg_v4 attachment. Once they click Read Message they are redirected to the Office 365 Message Encryption portal where they can reply, forward, print, or take other allowed actions. More information can be found in this article.
Get started!
The new encrypt-only policy rolls out starting today as part of Office 365 Message Encryption.
Office 365 Message Encryption is offered in Office 365 E3 and E5, or as an add-on -you can find the full list of where Office 365 Message Encryption is offered here.
Please let us know what you think here or give us your feedback on uservoice!
Last September, we announced new capabilities in Office 365 Message Encryption that enable users to seamlessly collaborate on protected emails with anyone. This release included Do Not Forward an out-of-the-box policy that encrypts emails and Office attachments, and restricts the content and email from being forwarded, printed or copied.
Today, we are happy to share that we are releasing another out-of-the-box policy called encrypt only. With the encrypt-only policy, users can send encrypted email to any recipient, whether they are inside or outside the organization, and the protection follows the lifecycle of the email. That means recipients can copy, print and forward the email, and encryption will not be removed. This new policy provides more flexibility in the type of protection that can be applied to your sensitive emails.
This is valuable for organizations that want persistent encryption, but do not want to add additional restrictions. For example, a doctor looking to protect an email containing sensitive personal information, can apply the encrypt-only policy, and the patient receiving the email can easily consume the protected message regardless of their email provider, and forward that email to another trusted party.
With this new, flexible policy, users and admins can apply different levels of protection to best fit their data protection needs.
Read more to understand what the encrypt-only policy looks like and how to apply the policy.
How the encrypt-only policy works
The encrypt-only policy is an out-of-the box policy that can be used without additional configuration, and as the name suggests, only applies encryption to the email. You can apply the policy through end-user controls in Outlook or through automatic admin managed controls in the Exchange admin center. Users can apply this policy to individual emails through end-user controls in Outlook, and Admins can apply this policy automatically to any email that matches the set criteria through admin-managed controls in the Exchange admin center.
Customers that have enabled the new Office 365 Message Encryption capabilities will see the encrypt-only policy first through Outlook on the web and in the Exchange admin center under mail flow rules. Updates to Outlook for Windows and Outlook for Mac are planned for the coming months.
How to send an email with the encrypt-only policy in Outlook on the web
Users can apply protection with the encrypt-only policy by clicking on the protect button and changing the permissions to just encrypt. While the other options encrypt the message, the encrypt option will apply the encrypt-only policy to the message, therefore enabling recipients to forward, copy and print the message.
Applying this option will offer added flexibility for recipients to share the email with other trusted parties while encryption continues to persist and throughout the lifecycle of the email.
In Outlook on the web, users can click on the protect button to change the permissions of the email. Once a user clicks on protect, the users can click on encrypt, to only encrypt the email.Once the encrypt-only policy is applied, the user will see a notification that encryption has been applied.
How to apply the encrypt-only policy through Exchange mail flow rules
As an administrator, you can apply the encrypt-only policy automatically to emails that meet certain conditions by creating a mail flow rule. When you do this, email affected by the encrypt-only policy is encrypted in transport by Office 365.
You as an administrator can create new mail flow rule to automatically apply the encrypt-only policy to emails.
How to read encrypt-only email using Outlook on the web and Outlook mobile
Office 365 recipients can easily read and reply to emails that have been applied with the encrypt-only policy using Outlook on the web and Outlook mobile directly from the client.
Users can read the encrypted message natively directly in Outlook on the web and Outlook mobile.
The inline reading experience for Outlook desktop (Windows and Mac) will be available in the coming months. In the meantime, Office 365 users using Outlook desktop will see the encrypted mail as an html mail with an rpmsg_v2 attachment.
How to read encrypt-only emails for non-Office 365 users (on-prem, Gmail, and Outlook.com users)
Non-Office 365 users, receive an html mail with an rpmsg_v4 attachment. Once they click Read Message they are redirected to the Office 365 Message Encryption portal where they can reply, forward, print, or take other allowed actions. More information can be found in this article.
Get started!
The new encrypt-only policy rolls out starting today as part of Office 365 Message Encryption.
Office 365 Message Encryption is offered in Office 365 E3 and E5, or as an add-on -you can find the full list of where Office 365 Message Encryption is offered here.
Please let us know what you think here or give us your feedback on uservoice!
Last September, we announced new capabilities in Office 365 Message Encryption that enable users to seamlessly collaborate on protected emails with anyone. This release included Do Not Forward an out-of-the-box policy that encrypts emails and Office attachments, and restricts the content and email from being forwarded, printed or copied.
Today, we are happy to share that we are releasing another out-of-the-box policy called encrypt only. With the encrypt-only policy, users can send encrypted email to any recipient, whether they are inside or outside the organization, and the protection follows the lifecycle of the email. That means recipients can copy, print and forward the email, and encryption will not be removed. This new policy provides more flexibility in the type of protection that can be applied to your sensitive emails.
This is valuable for organizations that want persistent encryption, but do not want to add additional restrictions. For example, a doctor looking to protect an email containing sensitive personal information, can apply the encrypt-only policy, and the patient receiving the email can easily consume the protected message regardless of their email provider, and forward that email to another trusted party.
With this new, flexible policy, users and admins can apply different levels of protection to best fit their data protection needs.
Read more to understand what the encrypt-only policy looks like and how to apply the policy.
How the encrypt-only policy works
The encrypt-only policy is an out-of-the box policy that can be used without additional configuration, and as the name suggests, only applies encryption to the email. You can apply the policy through end-user controls in Outlook or through automatic admin managed controls in the Exchange admin center. Users can apply this policy to individual emails through end-user controls in Outlook, and Admins can apply this policy automatically to any email that matches the set criteria through admin-managed controls in the Exchange admin center.
Customers that have enabled the new Office 365 Message Encryption capabilities will see the encrypt-only policy first through Outlook on the web and in the Exchange admin center under mail flow rules. Updates to Outlook for Windows and Outlook for Mac are planned for the coming months.
How to send an email with the encrypt-only policy in Outlook on the web
Users can apply protection with the encrypt-only policy by clicking on the protect button and changing the permissions to just encrypt. While the other options encrypt the message, the encrypt option will apply the encrypt-only policy to the message, therefore enabling recipients to forward, copy and print the message.
Applying this option will offer added flexibility for recipients to share the email with other trusted parties while encryption continues to persist and throughout the lifecycle of the email.
In Outlook on the web, users can click on the protect button to change the permissions of the email. Once a user clicks on protect, the users can click on encrypt, to only encrypt the email.Once the encrypt-only policy is applied, the user will see a notification that encryption has been applied.
How to apply the encrypt-only policy through Exchange mail flow rules
As an administrator, you can apply the encrypt-only policy automatically to emails that meet certain conditions by creating a mail flow rule. When you do this, email affected by the encrypt-only policy is encrypted in transport by Office 365.
You as an administrator can create new mail flow rule to automatically apply the encrypt-only policy to emails.
How to read encrypt-only email using Outlook on the web and Outlook mobile
Office 365 recipients can easily read and reply to emails that have been applied with the encrypt-only policy using Outlook on the web and Outlook mobile directly from the client.
Users can read the encrypted message natively directly in Outlook on the web and Outlook mobile.
The inline reading experience for Outlook desktop (Windows and Mac) will be available in the coming months. In the meantime, Office 365 users using Outlook desktop will see the encrypted mail as an html mail with an rpmsg_v2 attachment.
How to read encrypt-only emails for non-Office 365 users (on-prem, Gmail, and Outlook.com users)
Non-Office 365 users, receive an html mail with an rpmsg_v4 attachment. Once they click Read Message they are redirected to the Office 365 Message Encryption portal where they can reply, forward, print, or take other allowed actions. More information can be found in this article.
Get started!
The new encrypt-only policy rolls out starting today as part of Office 365 Message Encryption.
Office 365 Message Encryption is offered in Office 365 E3 and E5, or as an add-on -you can find the full list of where Office 365 Message Encryption is offered here.
Please let us know what you think here or give us your feedback on uservoice!
Last September, we announced new capabilities in Office 365 Message Encryption that enable users to seamlessly collaborate on protected emails with anyone. This release included Do Not Forward an out-of-the-box policy that encrypts emails and Office attachments, and restricts the content and email from being forwarded, printed or copied.
Today, we are happy to share that we are releasing another out-of-the-box policy called encrypt only. With the encrypt-only policy, users can send encrypted email to any recipient, whether they are inside or outside the organization, and the protection follows the lifecycle of the email. That means recipients can copy, print and forward the email, and encryption will not be removed. This new policy provides more flexibility in the type of protection that can be applied to your sensitive emails.
This is valuable for organizations that want persistent encryption, but do not want to add additional restrictions. For example, a doctor looking to protect an email containing sensitive personal information, can apply the encrypt-only policy, and the patient receiving the email can easily consume the protected message regardless of their email provider, and forward that email to another trusted party.
With this new, flexible policy, users and admins can apply different levels of protection to best fit their data protection needs.
Read more to understand what the encrypt-only policy looks like and how to apply the policy.
How the encrypt-only policy works
The encrypt-only policy is an out-of-the box policy that can be used without additional configuration, and as the name suggests, only applies encryption to the email. You can apply the policy through end-user controls in Outlook or through automatic admin managed controls in the Exchange admin center. Users can apply this policy to individual emails through end-user controls in Outlook, and Admins can apply this policy automatically to any email that matches the set criteria through admin-managed controls in the Exchange admin center.
Customers that have enabled the new Office 365 Message Encryption capabilities will see the encrypt-only policy first through Outlook on the web and in the Exchange admin center under mail flow rules. Updates to Outlook for Windows and Outlook for Mac are planned for the coming months.
How to send an email with the encrypt-only policy in Outlook on the web
Users can apply protection with the encrypt-only policy by clicking on the protect button and changing the permissions to just encrypt. While the other options encrypt the message, the encrypt option will apply the encrypt-only policy to the message, therefore enabling recipients to forward, copy and print the message.
Applying this option will offer added flexibility for recipients to share the email with other trusted parties while encryption continues to persist and throughout the lifecycle of the email.
In Outlook on the web, users can click on the protect button to change the permissions of the email. Once a user clicks on protect, the users can click on encrypt, to only encrypt the email.Once the encrypt-only policy is applied, the user will see a notification that encryption has been applied.
How to apply the encrypt-only policy through Exchange mail flow rules
As an administrator, you can apply the encrypt-only policy automatically to emails that meet certain conditions by creating a mail flow rule. When you do this, email affected by the encrypt-only policy is encrypted in transport by Office 365.
You as an administrator can create new mail flow rule to automatically apply the encrypt-only policy to emails.
How to read encrypt-only email using Outlook on the web and Outlook mobile
Office 365 recipients can easily read and reply to emails that have been applied with the encrypt-only policy using Outlook on the web and Outlook mobile directly from the client.
Users can read the encrypted message natively directly in Outlook on the web and Outlook mobile.
The inline reading experience for Outlook desktop (Windows and Mac) will be available in the coming months. In the meantime, Office 365 users using Outlook desktop will see the encrypted mail as an html mail with an rpmsg_v2 attachment.
How to read encrypt-only emails for non-Office 365 users (on-prem, Gmail, and Outlook.com users)
Non-Office 365 users, receive an html mail with an rpmsg_v4 attachment. Once they click Read Message they are redirected to the Office 365 Message Encryption portal where they can reply, forward, print, or take other allowed actions. More information can be found in this article.
Get started!
The new encrypt-only policy rolls out starting today as part of Office 365 Message Encryption.
Office 365 Message Encryption is offered in Office 365 E3 and E5, or as an add-on -you can find the full list of where Office 365 Message Encryption is offered here.
Please let us know what you think here or give us your feedback on uservoice!
The following is provided from Microsoft Security and Compliance blogs at TechCommunity:
Last September, we announced new capabilities in Office 365 Message Encryption that enable users to seamlessly collaborate on protected emails with anyone. This release included Do Not Forward an out-of-the-box policy that encrypts emails and Office attachments, and restricts the content and email from being forwarded, printed or copied.
Today, we are happy to share that we are releasing another out-of-the-box policy called encrypt only. With the encrypt-only policy, users can send encrypted email to any recipient, whether they are inside or outside the organization, and the protection follows the lifecycle of the email. That means recipients can copy, print and forward the email, and encryption will not be removed. This new policy provides more flexibility in the type of protection that can be applied to your sensitive emails.
This is valuable for organizations that want persistent encryption, but do not want to add additional restrictions. For example, a doctor looking to protect an email containing sensitive personal information, can apply the encrypt-only policy, and the patient receiving the email can easily consume the protected message regardless of their email provider, and forward that email to another trusted party.
With this new, flexible policy, users and admins can apply different levels of protection to best fit their data protection needs.
Read more to understand what the encrypt-only policy looks like and how to apply the policy.
How the encrypt-only policy works
The encrypt-only policy is an out-of-the box policy that can be used without additional configuration, and as the name suggests, only applies encryption to the email. You can apply the policy through end-user controls in Outlook or through automatic admin managed controls in the Exchange admin center. Users can apply this policy to individual emails through end-user controls in Outlook, and Admins can apply this policy automatically to any email that matches the set criteria through admin-managed controls in the Exchange admin center.
Customers that have enabled the new Office 365 Message Encryption capabilities will see the encrypt-only policy first through Outlook on the web and in the Exchange admin center under mail flow rules. Updates to Outlook for Windows and Outlook for Mac are planned for the coming months.
How to send an email with the encrypt-only policy in Outlook on the web
Users can apply protection with the encrypt-only policy by clicking on the protect button and changing the permissions to just encrypt. While the other options encrypt the message, the encrypt option will apply the encrypt-only policy to the message, therefore enabling recipients to forward, copy and print the message.
Applying this option will offer added flexibility for recipients to share the email with other trusted parties while encryption continues to persist and throughout the lifecycle of the email.
In Outlook on the web, users can click on the protect button to change the permissions of the email. Once a user clicks on protect, the users can click on encrypt, to only encrypt the email.Once the encrypt-only policy is applied, the user will see a notification that encryption has been applied.
How to apply the encrypt-only policy through Exchange mail flow rules
As an administrator, you can apply the encrypt-only policy automatically to emails that meet certain conditions by creating a mail flow rule. When you do this, email affected by the encrypt-only policy is encrypted in transport by Office 365.
You as an administrator can create new mail flow rule to automatically apply the encrypt-only policy to emails.
How to read encrypt-only email using Outlook on the web and Outlook mobile
Office 365 recipients can easily read and reply to emails that have been applied with the encrypt-only policy using Outlook on the web and Outlook mobile directly from the client.
Users can read the encrypted message natively directly in Outlook on the web and Outlook mobile.
The inline reading experience for Outlook desktop (Windows and Mac) will be available in the coming months. In the meantime, Office 365 users using Outlook desktop will see the encrypted mail as an html mail with an rpmsg_v2 attachment.
How to read encrypt-only emails for non-Office 365 users (on-prem, Gmail, and Outlook.com users)
Non-Office 365 users, receive an html mail with an rpmsg_v4 attachment. Once they click Read Message they are redirected to the Office 365 Message Encryption portal where they can reply, forward, print, or take other allowed actions. More information can be found in this article.
Get started!
The new encrypt-only policy rolls out starting today as part of Office 365 Message Encryption.
Office 365 Message Encryption is offered in Office 365 E3 and E5, or as an add-on -you can find the full list of where Office 365 Message Encryption is offered here.
Please let us know what you think here or give us your feedback on uservoice!
The above was provided from Microsoft Security and Compliance blogs at TechCommunity
One of the challenges concerning those implementing Service Delivery with Office365, is building proof that Office365 complies with regulatory standards and legislation. Service Assurance in Office365 is a primary goal, and if it vital that you understand how Office365 protects your data, especially since Office365 concerns email access, team communication, collaboration, content storage and specifically content viewed and edited in a browser. Service Delivery includes Service assurance, which is an organisational primary goal, and is directly aligned to the C/I/A triad (Confidentiality, Integrity and Availability), being key aspects of information security.
Office365 contains a Service Assurance area which allows Administrators to setup and provide resources to carry out risk assessments and audits, and includes a wealth of reports covering security, and the relevant legislation and standards that Office365 adheres to. I wrote an article for TechNet Blogs which gives a great overview on how to use Office365 Service Assurance (within the Security and Compliance section) here, go check it out!
Personal data (also referred to as PII – Personal Identifiable Information) identifies an individual. In that personal data, a name by itself is not enough to identify an individual, however, a name including the address would. For example, when you are called by an operator in a call centre, you will often be asked for your name, address and date of birth. That is an example of personal data. What they do with your personal information goes into data processing, that is, to store, sort, workflow (further processing) and retain till archive (disposal) that data. The controller of that data (that is, the owner of that call centre) is responsible for ensuring that data is stored securely on their system.
However, no matter how secure the system is, or in fact, any data processing system is, social engineering attacks is a key threat vector. The weakest part of an system is the people, since they are the easiest to deceive and manipulate. One of the weakest aspects is through impersonation attacks. Impersonation attacks are where someone plays the role of someone who is likely to be trusted (whose personal information was obtained through data processing). In other words, one of the ways to get enough personal information of an individual to impersonate is through getting their personal information in the first place, and, to a large degree, ‘data processing’ is where that information can be obtained.
Through the data processing, there are three key elements:
The Subject, who owns the data.
The Controller, who is responsible determining how the data is processed.
The Processor, who is responsible for the data processing of the subject data.
This can be represented in virtually any process, let’s take a basic SharePoint example:
The Subject uploads data into a SharePoint site.
The Controller manages the site where the data is uploaded and determines how the data is processed (also known as a data owner on the site)
The Processor holds that data from the point where it has been uploaded, to the point where the data is disposed of (this is generally some technical processes in the repository where the content has been uploaded, e.g. storage, workflow, disposition, security).
There are some assumptions to the above example in terms of the management of Personal information:
The Subject assumes that the data being uploaded is securely managed (it can be security classified, can be readily accessed, and remain intact).
The Controller assumes they are accountable to that data being serviced by making sure the processor is sufficiently set to securely that content and marked with an identifier of the subject. A basic example in SharePoint is that data uploaded gets marked with the name of the individual uploading the data, the time when that occurred and history of working with that data is recorded.
The Processor assumes that it is designed in such a way that personal information is secure; that any alterations, changes, modifications, workflow is known to the subject.
A conundrum is the sheer collaboration aspect; that is, who has access to that data, and, unfortunately, that some controllers misunderstanding that security is somehow, the product. It is not. Any system can be bypassed using social engineering if that data is compromised. The personal information of the Subject can be accessed by anyone who has the view access to that data. For example, in the case of SharePoint Online, when a Subjects name is clicked in a repository, a list of other documentation recently uploaded / accessed is visible, along with a link to getting more information through Delve. Additionally, on the Delve screen is a further link to the Subjects’ OneDrive, and from there visibility of the Subjects’ team. In terms of technology this example works slightly different in SharePoint On-Premise, however, the outcome is the same.
The challenge is that irrespective of the tools used to provide the nature of storage, availability, integrity of data that there needs to be some thinking in managing the security of the data as well as personal information. Lets’ look at some of the requirements on those three elements:
From the Subject, there needs to be understanding of how much information they enter about themselves using Delve (About Me, Projects, Skills and Expertise, Schools and Education, Interests and Hobbies) as this affects PII.
From the Controller, they need to provide awareness to the subject that the data they provide is secure, and the level of accessibility to that data, and where that data is located.
From Processing, the design of repositories needs to include the management of storage of data, classification, workflow relevant to how personal information is passed. For example, the use of a form to capture information relevant to content uploaded may require the subject to ensure personal information, maybe even beyond what is already supplied in Delve. If this is the case, the Controller should make the subject aware of the kind of information gathered, and what the Processing element will do with that data, and how long that data will exist in the repository. Another example is where the data uploaded includes Personal Information and through machine learning metadata is extracted and posted as viewable column data in a repository. And this does stop at metadata. The very design of code used to carry out further processing through workflow should be scrutinised since the level of Personal Information recorded needs to meet legislative laws; in particular, the Data Protection Act 1998 UK law covers this including sensitive personal information to which you should have the Subjects consent beforehand to process.
Summary.
Managing Personal information is a crucial aspect data security; the key aspect to understanding how to prevent breaches of personal data through impersonation or masquerading.
This short article is designed to get you thinking of the actual service delivery in managing personal information not just for SharePoint (either Online or On-Premise); even beyond to endpoints connected to it; and then even beyond into the roadmap surrounding Office365. In a data processing system, the fundamental requirement is to secure the content through its lifecycle. The challenge is ensuring that the features of the tools involved are fully understood when it comes to the storage of personal information, and that security awareness, policies, and training is provided to subjects and data controllers. Legislation is important to understand in this area and a good checklist to start from is here.
The key element, the Subject, can be made more aware of storing personal information in content they upload. A good article for working say through a Word document and removing personal identifiable information is here.
A distinct point to make is that Microsoft cloud applications are by their very nature tools used to upload and transmit information by customers through their relevant tenants. For example, whilst Azure services covers tools for system maintenance, infrastructure, security, record retention, information management, system development, there are data processing activities which the tenants manage. They must ensure that they are responsible for ensuring that information stored or transmitted through the services is securely managed, in that they at the very least should have carried out a security risk assessment against any data processing / controlling surrounding managing personal Information. The key thing to remember, is that security is not a product – the responsibility of securing data through its processing lies with the Controller of that data – the tenant owner, the SharePoint site owner, and therefore the organisation responsible for providing those sites.
One of the most useful documents in my view in planning implementations of Office365 is understanding data encryption and data backup and the standards applied. Microsoft have provided audit reports covering their cloud stack (Dynamics CRM, Office365, Yammer and Azure). These SOC and ISO reports include testing and trust principles in these areas:
Data Transmission and Encryption
Security Development Lifecycle
Data Replication and Data Backup
To access these reports, you will need to access the Security and Compliance area in your Office365 tenant.
As said, these cover the Microsoft Cloud Stack, however, the two key documents for Office365 are:
Office 365 ISO 27001-ISO 27018-ISO 27017 – this is an audit document confirming whether Office365 fulfils the standards and criteria against ISO 27001, 27018 and 27017.
Key points:
PII is included in Office365 because it is run over Public Cloud for multi-tenant customers.
Cloud Security is included in Office365 because it is defined as a SaaS (Software as a Service)
All encryption adheres to TLS requirements and hashing (specific)
Office 365 SOC 2 AT 101 Audit Report 2016 – this is an audit document looking at the controls relevant to Security, Availability, Confidentiality and Processing Integrity.
Key points:
Details on the services concerning planning, performance, SLAs, hiring process (including background checks of staff) are provided.
Control Monitoring, Access and Identify Management, Data Transmission (encryption between Microsoft, Client and data centres) are described.
Project requirements through to Final Approval concerning the SDLC process is described
Availability, Data Replication and Backup is covered.
Summary
The above SOC and ISO are extremely useful in aiding any risk assessment that you should take to confirm the service assurance of Office365 going forward. Risk assessments are not a ‘one shot’ task. They should be carried out on an annual basis. The Office365 service is a rich offering of Infrastructure, Software, People, Procedures and Data. Each requires security controls and confirmation that they meet standards which can be dovetailed into your organisation. The audits go into great detail concerning the controls (especially things like Data in Transit / Rest – SSL / TLS). A lot of questions is asked by customers concerning security controls – the video below is a good method of getting you to understand (and your clients) how Microsoft ensures proactive protection, and you should definitely check out the Microsoft Trust Centre for great information concerning encryption.
A major challenge in businesses is a misconception, that data is 100% secure concerning any part of its data processing within that business. This data processing concerns the content management lifecycle; from creation, to storage, to distribution, to workflow and eventually archive of that data. The misconception? “Security Breach? Its not going to happen to us” mentality. It is vital that there is an understanding of Information security and Information Assurance in content management security. As an information security professional (or Architect covering security), you should be prepared for any aspect of secure breach can happen that can affect the confidentiality, availability, and integrity of the data. Any service delivery disruption caused by a security breach is harmful to the profitability, and has far reach consequences which could include liability, status and much more.
Cyber security is about data loss prevention, detection and response. Service delivery includes ensuring the protection and managing the integrity of content through its lifecycle. This is cross platform, and cross industry, so in relation to whether you are using SharePoint on / off premise, or SharePoint is at the centre of an estate of multiple technologies, cyber security concerns all of these. These requirements directly relate to a technology current and future state – according to Gartner (and covered in my last keynote):
By 2016 Biometric sensors will be featured in 40% of smartphones shipped to end users.
By 2017 one-third of consumers in emerging markets will have never owned a windows device.
By 2018 more than 50% of users will use a tablet or smartphone first for all online activities.
By 2020 40% of enterprises will specify Wi-Fi as the default connection for non-mobile devices.
With the match of evolving technologies related to the above points, such as Internet of Things (IOT), Content Analytics, Hybrid Cloud Computing, Big Data, In Memory Database Management and more about to become widespread; how to provide integrity, protection, and governance to data becomes more important. We all work with data, utilising physical and digital technology in our daily lives. We use countless methods to create and use data, and assume that the accessed data has security maintained. In providing measures, providers of secure access to data provide measures to ensure legitimate access. Consequences resulting from unauthorised access to data could include:
Time, effort and monetary resources to correct.
Damage, deletion and compromise.
Damage to reputation.
From a global perspective there are security challenges in the ‘digital developed’ versus ‘digital developing’ world. For the developed world, users’ access information through a digital framework; internet services provisioned over high level Wi-Fi and 3G/4G networks. But, in the developing world, there some 950 million people still without the means to connect to these networks. Security provision is not a one-fits-all. Additional global challenges are ‘Freedom of Speech’, ‘Country A Trust Country B Trusts Country C’ and the ‘Political Will’.
From a company perspective, the primary objective is to ensure the management of security; enforcing breach policies and governance is vitally important to ensure their data integrity. The challenge is that the company workplace is changing, and so is the physical infrastructure. Whilst physical and digital technology has become increasingly sophisticated, like dongles, passwords, data encryption, the task is convincing staff – from senior manages to entry level employees that they need to become more security accountable, becomes harder due to their emotions about security and privacy.
From a personal perspective, security intertwines with privacy. Advances in technology threatens privacy, reducing the amount of control over data. Privacy affects technology use. The challenge is the space in which this takes place in the digital world, which is completely online through the use of the internet, which never corrects and never forgets.
In summary, humans adopt any cyber security imperative. Technology is neutral. This means work must be done in the governance, training, and management of data to protect integrity and at the same time provide detection and contingency against loss. Opportunities include:
Proactive security reporting
Automated content filtering
Protection of content via search engines
Child Protection, for example, Extremist content removal
Security Automation – for example, E-mail Scanning
Service delivery includes the protection and the integrity of content created. Like security, compliance is cross platform, cross industry. It does not matter whether you are simply using SharePoint, or using multiple platforms to service content into SharePoint.
Compliance concerns:
Monitoring, isolation, automated operations, secure network and encrypted data.
Security best practice, and the customer controls.
DPL, audit and retention, eDiscovery and Data spillage.
Standards such as ISO 27001, FISMA, HIPAA BAA, EU Model Clauses, and the CSA.
Note – this article is geared to looking at SharePoint on-premise. Office 365 is pretty much covered on encryption technologies. There is a wealth of information concerning this and more the Microsoft Office 365 article on this link: Data Encryption Technologies in Office 365. Also, there is also a huge amount of information available in its Trust Centre. There is a specific section concerning compliance on this link:Continuous Compliance in Office 365
Encryption is a solution against Data Breaches
Data Breaches are not simply relegated to external infringement of data by those who should not have access. This is an ongoing problem, and regulators are ramping up audits and confirming standards to ensure companies are taking heed. Some data breaches can occur for any of the following reasons:
Data copied and taken off premises
Downloading information then emailing the data unprotected to external parties
Saving content to a folder which is publicly available online
Provisioning of production data in test or development systems
Protecting against data breaches therefore must consider the data at the location where it is saved. Encryption of the data is without doubt the highest level of protection the data can get to prevent that data being subject to a data breach. However, the human culture of how they handle security matters is also extremely important.
SharePoint Data Security
When data ends up in SharePoint, the content is stored in SQL (at rest), except in the case of RBS (Remote Blob Storage). The data in SQL is ‘unstructured’, meaning, that it is not ‘easy’ to simply dive in and set security on specific bits of data. The data is also ‘unknown’, meaning that it is not also ‘easy’ to identify what data relates to what area and in what context – and even if you could, securing that would be a difficult in the extreme.
SharePoint, ‘Out-Of-The-Box’, provides access controls only to protect the data based on the role of the user. These access controls include:
Permissions access to the data
Auditing controls, stamping of data, lock down.
However, there are data encryption components provided ‘Out of the Box’ for SharePoint. Data could be read in a number of ways (described below). And again, confusion reigns from people trying to get to grips with the options. Some people even confuse authentication with encryption. I have even heard a client state that surely provisioning SSL will provide encryption. That client had to be informed that SSL only secures the network connection to the link where the data can be accessed (that is, Data in Transit, NOT Data at Rest). It does not protect the data from being ‘read’ at its source. Anyone unsure of this should check out this article Do you need SSL?
Compounded is the challenge humans the culture they apply to security – it is not simply a ‘one hat fits all’. From people I have spoken to and worked with on this topic, it is generally stated that users are simply not taking enough security measures to protect the data. Yes, one could very easily apply role permissions to ensure that individuals cannot read, write, or even upload. Provision of auditing tools to alert individuals of unwanted access is possible. Locking down of data so that the data cannot be modified or downloaded is possible. However, those solutions is not on the same plain as the protection (encryption) of the data where it is stored. For example, if a disk holding data was subject to attack / access from those who should not be able to read the data at source, then surely that is an out of compliance and classed as security risk. Indeed, taking a SQL SharePoint content database off a disk, and then applying that content database into another web application in another farm is relatively easy. Even if that operation takes place unless under strict and controlled circumstances (note that in some cases a challenge to implement, especially when working with multiple technical teams like a separated team for SQL, Windows, SharePoint, etc.) the mere fact that the data is in a read-able form when transmitted could be still construed as a data compliance issue.
The solution is looking at the data within SQL; that requires ‘security hardening’ and encryption solve these challenges.
Implementing encryption for Data at Rest starring SQL
As pointed out, SharePoint data resides in SQL. That is the point where encryption should be brought into play. Microsoft recognised this way back with the implementation of SQL 2008 and provided two technologies to protect ‘data at rest’ meeting various compliance standards. Thankfully, the architecture is in place to provide, since SQL provides the ability to have the data encrypted, using the following technologies:
Switching on encryption is not just a ‘fire and forget’ action. A number of tasks must be completed beforehand in order to deliver the service:
The environment must be modelled first; for example, identifying the number of users, size of documents, underlying infrastructure, specific technical roles and skill set.
Disaster Recovery environment and enabled technologies. Check the infrastructure applied to the SharePoint farm concerning DR. Check whether RBS is in use which will impact on how encryption is to be applied – note that TDE does not apply to content in a file stream because that content is not encrypted in SQL so additional encryption methods would have to be applied.
Key management – who is responsible for managing the key – is it the SharePoint team? The SQL team? The Security team?
Advise your corporate security team including any stakeholders of the impact of encryption. There is a technical as well as business impact. The technical side is a degradation of overall performance. From investigations I’ve been advised this could be up to 2% overall. On the business side is an impact on support, particularly from SQL and Security, since they have an extra accountability to the management of the encryption. Note also, that you should test this thoroughly in a isolated test environment and against DR and run DR tests.
Apply Encryption at Rest for SQL, and for this, TDE must be implemented. Remember, TDE is used to prevent the restoration or attachment of databases into another SQL instance. This means that a master key needs setup, the database requires configuration, and the encryption password (stored in the certificate) must be backed up. Then, all must be tested (i.e. backup, restore – which should fail – then restore again along with the key – which should work).
Ensure connections to SQL are encrypted. This means protection from those attempting to use tools to get at the data. This means forcing encryption settings to enabled for the SQL server and applying the certificate.
Prevent other machines accessing the SQL instance (i.e. attempting to connect a different farm, or a machine outside of the ‘allowed server authentication list’ to a SQL instance being protected), you would setup isolation rules by configuring the firewall on the relevant servers themselves.
Note – doing this by yourself in a company with multiple teams looking after the infrastructure is unwise. You should seek aid from your SQL teams, as well as advice from Server teams.
To get detailed information on how to technically deliver encryption for SQL as well as isolation, step by step, check out the excellent article on this link:
A key aspect of Data Compliance is the protection of data. Companies use data compliance to protect data, provide policies, processes and systems, and this stretches to governments and individuals. This is cross platform, and cross technology.
In Sharepoint, in order to meet data compliancy challenges and provide solutions through service delivery, there must be understanding that there is encryption tools available to data where that data resides. Encryption is the keyword here, since through this article I have explained how data can be securely stored and protected from unwarranted access.
SQL provides encryption and key management tools so that the data becomes unreadable to anyone except those who should have access to that data, using key management to automatically convert data back to its original, readable form. There are additional opportunities available to harden the SQL platform so that there is isolation and authenticated access.
The implementation of encryption though, whilst relatively easy from a technical viewpoint, provides many challenges to overcome in implementation. Security awareness, and identifying shortfalls in the surrounding infrastructure is vital, along with the marrying up of the roadmap of SharePoint. Implementing future technologies down the line will have an impact on encryption, so ensuring that you continually review encryption usage and change management is necessary.
A key aspect of implementing SharePoint in an organisation is relevant to security of content. The success of SharePoint in an organisation is due not only to how comfortable users are with using their current technology with SharePoint, it is also down to ensuring that the users are comfortable knowing the data they manage on their SharePoint sites are secure…
Support service development for SharePoint is crucial to ensure sustained SharePoint Governance and User Adoption. I had the situation where in building a SharePoint support service that a customer needed the provision of support to be handled differently for a newly delivered SharePoint solution, and also needed that to be documented and agreed by the SharePoint sponsor. The reason for this is that they needed the support service to be measured against the supply of support to that solution, which was critical to the department and the organization.
The Cloud Security Alliance published the Cloud Control Matrix, to support consumers in the evaluation of cloud services and to identify questions prudent to have answered before moving to cloud services. In response to this publication, Microsoft has created this document to outline how we meet the suggested principals and mapped them to the International Standards Organization (ISO) 27001:2005 and ISO 27002. With this standardized response we would like to empower customers with in-depth information to evaluate different offerings in the market place today.
No, security is not all about a Dalek yelling ‘Exterminate’ if you don’t follow rules concerning access to information 🙂 Access to information can be controlled at many different levels within Sharepoint. The question of where best to implement control of user access is answered only with an understanding of available options and requirements. As part of training those who need to manage security on the sites, even if they themselves do not set the security permissions, it is a very important that you communicate a policy concerning when and where to apply site security.
Last week, I attended a great Microsoft session concerning Compliance and Data Protection across the Office products, focusing on Archiving, Retention / Hold, Discovery and Data Loss Protection concerning compliance in 2013 products. I mentioned that I have clients who are interested in Office 365 but need some comfort concerning compliance, and queried if there was further information available. Was informed that there was a document available that described this which I must share with you all.
This document covers topics such as Office 365 Built in Security, like monitoring, isolation, automated operations, secure network and encrypted data. It describes security best practice, and the customer controls. It talks about how compliance is enabled through DPL, audit and retention, eDiscovery and Data spillage. It also describes the standards of compliance met, like ISO 27001, FISMA, HIPAA BAA, EU Model Clauses, and the CSA (Cloud Security Alliance).
If you are embarking on SharePoint migration to Office 365, or having a hybrid operation with on-premise SharePoint and Office 365, I would recommend reading this paper, as it will give you valuable information proving to the customer that Office 365 includes security features, protects data and provides administrators with the ability to configure, integrate and manage security.
To give you a taster, here’s the intro:
The ability for organizations to control and customize security features in cloud-based productivity services, such as email, calendars, content management, collaboration, and unified communications, is becoming an essential requirement for virtually every company. Today, IT teams are being required to deliver access to productivity services and associated documents and data from more devices, platforms, and places than ever before. While user benefits are undeniable, broader access makes security management more challenging. Each endpoint represents a potential attack surface and another point of management for security professionals. At the same time, organizations face ever-evolving threats from around the world and must manage the risk created by their own users accidentally losing or compromising sensitive data. For these reasons, organizations require a cloud service that has both (a) built-in robust security features and (b) a wide variety of customizable security features that organizations can tune to meet their individual requirements. Organizations expanding remote access while maintaining security best practices may find it difficult and expensive to add this combination of security functionality if they deploy productivity services solely on-premises.
I was a guest speaker on a general SharePoint Security Webcast today, which was great fun. On the agenda was security of SharePoint relating to mobile devices. Unfortunately, the session did not manage to get into that topic, and I was so keen to talk about it. To counter, I’ve provided an article written today which talks about how personal devices as part of Consumerization have impacted SharePoint, some features available to mobile users, what implications are there in terms of security and finally a look at what Support needs to address.
