Microsoft added Spoof Intelligence for email security earlier this year (January 2018 I think). This was included as a feature of the Office 365 Enterprise E5 plan, as well as a feature of the Advanced Threat Protection add-on for non-E5 customers. Spoof Intelligence provides visibility into who is spoofing your domain and/or domains that are sending email to you, and provides the capability to allow or deny any of these sending patterns. Spoofing means sending as a domain when you aren’t actually part of that domain, and the default behaviour in anti-spam engines is to treat spoofed email as junk or otherwise invalid. But that’s not always true.
In its documentation on Spoof Intelligence, Microsoft lists several situations when spoofing is valid:
When a sender spoofs an email address, they appear to be sending mail on behalf of one or more user accounts within one of your organization’s domains, or an external domain sending to your organization. Surprisingly, there are some legitimate business reasons for spoofing. For example, in these cases, you wouldn’t block the sender from spoofing your domain:
– You have third-party senders who use your domain to send bulk mail to your own employees for company polls.
– You have hired an external company to generate and send out advertising or product updates on your behalf.
– An assistant who regularly needs to send email for another person within your organization.
– An application that is configured to spoof its own organization in order to send internal notifications by email.
External domains frequently send spoofed email, and many of these reasons are legitimate. For example, here are some legitimate cases when external senders send spoofed email:
– The sender is on a discussion mailing list, and the mailing list is relaying the email from the original sender to all the participants on the mailing list.
– An external company is sending email on behalf of another company (for example, an automated report, or a software-as-a-service company).
You need a way to ensure that the mail sent by legitimate spoofers doesn’t get caught up in spam filters in Office 365 or external email systems.
There’s a plethora of technical standards and reputation dealings and authentication magic happening in the background to determine whether a message is spoofed or not, but the simple idea is that Spoof Intelligence provides a simple way of seeing who is spoofing you, and providing you with the ability to mark these spoofs as valid or invalid.
The prevalence of email (addresses, services, checking behaviours) has made it a key vector for hackers, attackers, and others devoted to maleficence. There are many varieties of bad email:
– spam – unwanted email messages, normally carrying a commercial offer. Annoying and productivity draining at best; may carry other nefarious payloads at worse.
– phishing – an email message pretending to be something it is not, with the intent of capturing a user account for subsequent actions. Phishing is a key method of account compromise.
– whaling / CEO fraud / spear-phishing – a highly targeted email message sent to a specific individual (normally high ranking with special financial authorisations) requesting a specific action that sounds highly probable and likely given the (falsified) details in the email.
– privileged account compromise – targeted efforts to get the account credentials for a high-level IT administrator, because once you have the keys to the kingdom, you have the kingdom.
– attachments infected with viruses, ransomware, and malware
– … and many more.
Security vendors provide a range of protections against the many and varied types of attacks:
– anti-spam to filter out unwanted messages, based on certain attributes and qualities.
– reputation services that analyse message characteristics to discern the valid from the invalid.
– signature-based anti-malware services, that compare message and attachment characteristics with known malware signatures.
– denotation chambers to deal with unknown, new, and never-been-seen-before malware variants (zero-day threats). Attachments and other links are executed in a controlled environment and recursively analysed for fingerprints of badness. If nothing is identified, the message and attachment is deemed safe and passed through to the user.
– domain name checking to see whether the signals about message authenticity align with the domain name represented in the sender details.
– domain name lookalike and sound alike checks, to see if the sender is trying to fool you by using a valid domain name with valid reputation but that is pretending to be your domain name or the domain name of a trusted business partner. Such as michaelsampson.net versus michealsampson.net or michae1sampson.net or m1chaelsampson.net or michaelsampsn.net. If you don’t look close enough, you’ll miss the false pretence.
– wider industry standards around email reputation and authentication, to minimise the valid attack surface, and thus force the creation of false signals when everything doesn’t line up.
For every program manager, product manager and software engineer focused on making productivity-enhancing tools, there are at least as many focused on safeguarding that productivity through security tools.
Microsoft announced data residency for data in Microsoft Teams for Canada, with Australia and Japan coming before the end of August as well. However, the details matter. The details such as – this only applies to two groups of customers in 2018:
– brand new customers who are creating a brand new tenant based in the Canadian geo; or
– current customers who have a tenant based in Canada but who have never opened nor touched Microsoft Teams.
In 2019 there will be a migration option for customers based in Canada (their tenant is homed there), and by extension, this will apply for Australia and Japan too. But for all practical purposes right now, this announcement is just a signaling device at this time that a change is coming. It may make a difference for Canadian organisations evaluating Office 365 right now, but everyone already using Office 365 is stuck with the current state for a while yet.
In the table above, I try to pick out the specifics on where your data is located, because … it’s complicated. It depends on how / why / who / what / where. In looking at the above:
– Brand New Customer in Canada geo – yes, you could have all your Microsoft Teams data stored in Canada.
– Existing Customer in Canada geo – your SharePoint and OneDrive storage and Exchange mailboxes will be stored in Canada, but your Teams data is stored in the United States currently. From 2019, you will have the option of migrating it to Canada.
– Existing Customer with Multi-Geo – *if* the SharePoint site for the Team was created in the Canadian geo, and *if* the user sharing a file has their OneDrive also located in the Canadian geo, then your files will be stored in region, but until you migrate in 2019, your conversation and chat data in Teams will be stored out of geo (United States or other).
Data residency is a specialised area. If it’s in the “don’t care” bucket for you, then roll on. If it’s in the “it matters a lot to our organisation for several specific reasons,” then study the details.
Paul Thurrott’s analysis of the soon-to-be-available Windows 10 update – Version 1809 (Redstone 5) – included this snippet that caught my eye:
Storage Sense now integrates with OneDrive and can automatically change any downloaded files to online-only if you haven’t used them in a configurable number of days (in Settings > System > Storage > Storage Sense).
Every vendor struggles with the balance between releasing tools that enable productivity through information availability and protecting information from too much disclosure / availability. What should this person have access to based on their job role and their tasks is a governance question for organisations, that’s enabled by technical capabilities offered by vendors. Data loss prevention stops people from flowing information to other people when it’s sensitive or confidential and the other party doesn’t have access rights. Access control lists on collaborative workspaces, shared folders, and systems of all kinds provide another form of information protection – it lets those who need the content in, and keeps those who don’t have the right to the content out. Role-based access control goes a step further and adds the nuance of who can and cannot take specific actions within a system.
Choosing to sync your OneDrive contents to a local machine is great for productivity – everything is immediately available whether you are connected to the network or not. But the risk is that unauthorised access to your machine – directly by a person or indirectly by a security threat executing and exfiltrating the data on your disk – will enable access to content by people who do not have authorisation. To information that is sensitive, confidential, or in need of special protections. The above forthcoming integration with Storage Sense in Windows 10 will mean that content from OneDrive that is not used often can be removed from local storage, reducing the potential information protection disclosure surface. If it’s not there directly, it can’t be accessed directly … and thus there’s another action required to gain access, which can be evaluated against up-to-the-second security policies.
As mentioned the other day, Microsoft uses two specific products to deal with the what of information protection: Office 365 DLP and Azure Information Protection. There are similarities between the two, but some fundamental differences as well. Let’s focus on Office 365 DLP today.
DLP is all about know and flow. Both are done specifically within the context of the DLP policies you have configured. Know is about the what – the specific sensitive information types or labeled content that exist within an email being written, a document attached to an email being written, or a document being shared from SharePoint or OneDrive.
But the know is only enacted at the point of flow, such as when the user is writing an email that has been addressed to someone not authorised to receive it (e.g., an external recipient), or a document sharing action that would share the document with someone not authorised to view or edit it.
This core idea – know and flow – aligns with the specific protection mandate of Office 365 DLP – to “prevent loss” by stopping an unauthorised someone from gaining access.
Thus DLP policies – as set up in the Security & Compliance Centre – are intended for:
– preventing an internal user from sending content in an email or attached document to a recipient who should not receive it.
– preventing the sharing of a document with someone who should not receive it.
– these actions must be taken within and through Office 365.
DLP will not prevent loss in all situations, unless there are other parts of the Information Protection portfolio in use. For example, if a user downloads a file with sensitive data and then syncs it with Dropbox (or some other cloud sharing service), that content has just disappeared. It has been taken out of the boundary of Office 365, and loss prevention capabilities are blind to what happens. Ditto if it is put onto a USB thumbdrive. There are other solutions in the portfolio – Microsoft Cloud App Security and Windows Information Protection for example – that can address most of these challenges, and Azure Information Protection to a degree as well (in conjunction with those other two). We’ll leave that complexity for another day.
But for now – DLP is all about know and flow.
When thinking about information protection, one of the key questions is what: what specific information should be protected? Some information doesn’t need to be protected at all, such as when it is common knowledge (2+2=4) or easily available (the name of the current leader of a country).
Other information does need to be protected – for a variety of reasons (the why, which we’ll talk about more fully later). Broadly speaking, information that needs to be protected is like that because its inappropriate use or disclosure could cause harm to a person, entity, or organisation. For example, disclosing someone’s credit card number and expiry date to the wrong person could result in financial harm (unauthorised transactions, lost funds, decimated credit rating, etc.) Disclosing someone’s name, address, national ID number and similar data could result in harm through identity theft; an unauthorised actor uses that valid data to masquerade as the other person, receiving benefits that the other party is entitled to or is forced to pay for without receiving the benefit. In an organisational context, disclosing financial planning documents or explanations of the forthcoming business strategy moves to a competitor can result in a weakened market position, reduced market valuation, and in the worst case, outright business failure.
The potential to cause harm is what drives the need to create mitigations through information protection, and in Microsoft’s perspective on information protection, there are two general classes:
- General and generic types of information that are sensitive, and that can be computationally discovered. For example, a credit card number is a credit card number is a credit card number, and if you can work out the identifying characteristics of credit card numbers, you can detect the presence of one or more. Likewise for social security numbers (US), tax numbers (pretty much everywhere), health identification numbers (ditto), and more. Information in this class exists generally, and a specific organisation could (or may have to) protect such information if they collect or handle it.
- Specific types of information that could cause harm to a specific business (or government agency, organisation, non-profit, etc.) if these were to fall into the wrong hands. For example, strategy documents, financial plans, employee lists, expansion ideas, current M&A targets, and more. Information in this class exists in customized forms for specific entities, and depending on the specific business / organisation / other, will need to be set up. There are of course general classes of these types of information across most entities, but the specific realisation of that is up to the specific entity.
Microsoft deals with the above through two specific products in its information protection solutions portfolio: Office 365 data loss prevention (DLP) and Azure Information Protection (AIP). Both products can work with the generic sensitive information types as well as specific types of information that could cause harm. DLP always works automatically (scanning, analysing, thinking), and AIP can work either by user choice (manual labeling of a document or email) or based on automated content analysis. And if something is found that goes against a policy, an automated action can be triggered – such as a user notification, an alert to an administrator, or a block action that prevents the message or document from being sent / saved / shared.
If you thought “collaboration” was a wiggly word with lots of definitions and places it could be used, you should try the phrase “information protection” on for size. Once you start enumerating the types and styles and approaches and consequences and implications and gotchas, you start to build a complex picture of requirements. Which is why Microsoft doesn’t offer an “information protection” product as such, but rather a set of solutions that apply in different situations. I need to get my head around what is actually on offer in Microsoft’s Information Protection Solutions catalog, so let’s have a talk about it. And probably not just today.
The diagram above is a common one used by Microsoft to show the breadth of its solution set. The four blue circles in the middle express the generic commonalities – detect, classify, protect, and monitor. The 11 solutions around the outside are the specific products that are  part of the solution set, and  in adherence with one or more of the four blue circles.
One immediate conclusion based on the breadth of these capabilities is that information protection is complex. There’s a lot to understand when you are dealing with a product set in Office 365 for productivity and collaboration that is as broad and deep as what Microsoft is attempting. To be the company that helps “everyone to achieve more” – a broad and all-encompassing vision if ever there was one – you have to safeguard and protect the means of achieving as much as providing tools to help with the achieving.
A second observation in looking at the diagram is that it’s important to note that not all of these capabilities are in Office 365. Some are – Office 365 Message Encryption, Office 365 Advanced Security Management (now called Office 365 Cloud App Security), and Office 365 DLP – are three obvious inclusions. And of the capabilities that are in Office 365, not all are in all plans; essentially, if you want all the Office 365 capabilities, you’ll need to purchase the E5 license. Lower licensing levels have a diminishing number of capabilities. The rest of the capabilities come from the Enterprise Mobility + Security plan – this is where you get the full version of Microsoft Cloud App Security, Conditional Access (from Azure Active Directory), Azure Information Protection, and more. One way of thinking about it is that you buy Office 365 E5 for productivity and collaboration and Enterprise Mobility + Security E5 for safeguarding that productivity and collaboration. It’s not a fully correct differentiation, but it’s a broadly accurate distinction. And if you buy the Microsoft 365 plan, you get both the Office 365 capabilities and Enterprise Mobility + Security capabilities, along with Windows 10.
So what do the above capabilities actually do? Let’s talk about that another day.
In the General Data Protection Regulation and other data protection regulations around the world, data breaches are a topic of concern. In all cases, the regulators do not want data breaches to happen (because it goes against the data protection mandate), and generally speaking, there is a requirement to notify a given authority when a data breach is detected. But despite the general expectation that data breaches are caused by nefarious external agents acting with malicious intent, there are many other types.
- An employee who accesses personal data records on customers or patients that are outside his or her task domain, or otherwise beyond what they need to access for their job. The ICO in the UK prosecutes people when this happens, such as a hospital worker, a housing worker, and a council worker, among many others profiled on the ICO blog.
- An organisation that should know better didn’t scrub the metadata on its published research, legal advice and reports, thereby disclosing details of employee names when its policy is to not disclose employee names.
- An employee leaves a firm and takes details on customers to a competitor or to their own new firm in the same market space. Again, the ICO prosecutes people for breaches of this nature, such as a recruitment consultant who stole the details of 272 individuals.
- A county council didn’t put appropriate access security on a database containing personal and sensitive information, which meant that members of the public could access the data with a search engine.
Article 3 of the General Data Protection Regulation (GDPR) states:
1. This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.
2. This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:
(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or
(b) the monitoring of their behaviour as far as their behaviour takes place within the Union.
3. This Regulation applies to the processing of personal data by a controller not established in the Union, but in a place where Member State law applies by virtue of public international law.
The key phrase for applicability is “in the Union,” in the physical sense:
– Any organisation based in the Union must comply with GDPR, for all data processes that make use of personal data (employees, customers, supply chain, etc.).
– Any organisation not based in the Union but which offers goods or services to, or monitors the behaviour of, data subjects in the Union, must also comply with GDPR.
– An organisation outside the Union offering goods or services to, or tracking the behaviour of, an individual who is physically in the Union, must comply.
– An organisation outside the Union offering goods or services to, or tracking the behaviour of, an individual who is not physically in the Union, does not have to comply.
– An organisation outside the Union hiring an individual with EU citizenship for a job role outside of the Union, does not have to comply. GDPR is blind to the idea of “EU citizenship;” it is not on this basis that GDPR applies.
– A visitor to the EU, while in the EU, is afforded the same rights of data protection to anyone who lives in the EU, whether dealing with organisations inside the EU (per Article 3(1)) or those outside offering products and services to individuals in the EU, or tracking the behaviour of individuals physically in the EU (per Article 3(2)).
That’s one way to deal with the requirements of GDPR (hat tip, BBC):
A number of high-profile US news websites are temporarily unavailable in Europe after new European Union rules on data protection came into effect.
The Chicago Times and LA Times were among those posting messages saying they were currently unavailable in most European countries.
Lee Enterprises publishes 46 daily newspapers across 21 states.
Its statement read: “We’re sorry. This site is temporarily unavailable. We recognise you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore cannot grant you access at this time.”
Read more: GDPR: US news sites blocked to EU users over data protection rules