Conveniently insecure: the tradeoff between security and convenience
Working in cyber security can sometimes land you as the “no” guy in the organization, so much so that I’ve even generated my own internal avatar to have a cartoon-style impression of myself, saying “no” to rogue IT.
We are often torn between the functionality and efficiency of a product and it’s integration, and the potential implications of said integration. The ultimate goal of information security is to manage risk. Therefore, one cannot ensure effective security without first considering the risk and trust that lie beyond the functionality.
To integrate or not to integrate? That is the question…
At hand, is a simple example for integrating a platform used for meetings. To enable those meetings, the platform needs to access an individual’s contact list. This makes sense because how else would it be able to allow you to smoothly pick a recipient to arrange said meeting? As such, doesn’t it make sense the platform needs access to the calendar in order to pick up if you are both busy?
This integration could of course also be made by generating a meeting and allowing you to select the recipient and time, but then the integration back to the platform would be missing.
Seems reasonable.
Now, what would this mean, in practice?
The proposed integration would enable the third-party organization to read the contact lists of employees, impacting data protection and compliance. This would then help visualize who is in contact with what organizations and what roles, making it easier for a hacker to pinpoint members of staff to launch their attack (phishing etc.). It can then export (to a limited degree) personal data, without any real justification for the export. Still not a disaster…
The integration would also be able to read calendar items. Those items contain who you have a meeting with, when and where. It also contains read-permissions for all attachments and to meeting links. The latter means that essentially, any meetings for which a link invite is in place containing confidential attachments and notes can be accessed, be it board meetings, meetings with advisors, analysts or even private meetings with union representatives, HR or any other items, are exposed unless marked as private – allowing cybercriminals to hijack virtual meetings and launch BEC Attacks. This seemingly rather innocent function, reading of calendar items, is hence the greater of the risks.
Graph API and access restrictions
To better understand the risk, we need to understand what access is granted when integrating the platform with the Office environment. The permissions are based on the Microsoft Graph API, and reviewing the permissions, this means the following:
| Calendars.ReadWrite | Read and write calendars in all mailboxes | Allows the app to create, read, update, and delete events of all calendars without a signed-in user. | Yes |
Looking into the graph API and what can be accessed via this (source https://docs.microsoft.com/en-us/graph/api/calendar-list-events?view=graph-rest-1.0&tabs=http) we can pinpoint some of the highlights.
"hasAttachments": false,
"subject": "All APIs Testing",
"bodyPreview": "Microsoft Teams meeting",
"webLink": "https://outlook.office365.com/owa/?itemid=[snip]%2BAAAAAAENAADv [snip]wdU3ADBy%2BAABH5Vj3AAA%3D&exvsurl=1&path=/calendar/item",
"onlineMeetingUrl": null,
"isOnlineMeeting": true,
"onlineMeetingProvider": "teamsForBusiness",
"responseStatus": {
"response": "organizer",
"time": "0001-01-01T00:00:00Z"
},
"attendees": [
{
"type": "required",
"status": {
"response": "none",
"time": "0001-01-01T00:00:00Z"
},
"emailAddress": {
"name": "admin@M365B877719.onmicrosoft.com",
"address": "admin@M365B877719.onmicrosoft.com"
}
}
],
"organizer": {
"emailAddress": {
"name": "Samantha Booth",
"address": "samanthab@adatum.onmicrosoft.com"
}
},
"onlineMeeting": {
"joinUrl": "https://teams.microsoft.com/l/meetup-join/19%3ameeting_YTU5OGEwOTct[snip]e%22%7d"
}
}
Now, of course there are the attachments, those are associated with the calendar read permissions. Essentially, the fact that calendar read permissions also carry the read permissions for attachments means that any invite to a board meeting containing a board presentation as well as a large set of other scenarios. This may not be desirable and casts unwanted eyes on your confidential information and data. Here is a detailed walkthrough of how permissions are required to call this API from Microsoft:
https://docs.microsoft.com/en-us/graph/api/event-list-attachments?view=graph-rest-1.0&tabs=http
Calling this in Microsoft’s graph is relatively straight forward
GET https://graph.microsoft.com/v1.0/me/events/{id}/attachments
Here is an example of the response. Note: The response object shown here might be shortened for readability.
|
HTTP/1.1 200 OK Content-type: application/json{ |
Now, how would one make this integration less intrusive and secure? There is a different permissions set.
|
“freeBusyRead” “write” |
In essence, this means that it would be possible to request permissions to see the status of calendars without knowing what is in those meetings, but just seeing if there is something there. If we do not want the system generating and sending a meeting invite, we could in theory grant it a delegate-write permission (only the sender) or write-permission (created in both calendars).
Of course, it will be more efficient for the solution if it can track response statuses and keep that integrated into the other platforms view, but the cost in the format of the risk associated is very hard to justify compared to the potential benefits.
Decisions, decisions
Understanding the implications of relatively “benign” looking permissions granted to a third-party will mean that more trust in the third-party is placed that meets the eye at first glance. Requesting the access is no further away than clicking on an application in a cellphone, but instead of exposing information on just the device, in Office365 we expose the entire organization – however doing so requires administrator consent.
This also forms a perfect ground for misunderstandings and getting perceived as “The No-man” and number 1 blocker in the organization, unless we can verbalize the risk in a manner that is graspable and obtainable to those who do not spend their entire days with a ‘glass half empty’ approach of the likely hazardously old milk, like myself.
This does not mean that there is a ‘no’ to every integration, but it does mean that we must recall that allowing calendar integrations for meeting booking services or other systems comes with risk. Similarly, using a cold calling service that offers to correlate your contacts in the system against a known list in their system, for example disclosing the identity of each individual and each organization you have been emailing with.
I always want to be the first to know of any new/potential integrations so I can fully assess the risks to the business first. It's also important to consider the security implications because of mergers and or acquisitions where new software may be introduced into your infrastructure unknowingly. Having processes in place such as robust risk assessment and scoring will flag the immediate risks. Applying the correct security controls required against any potential cyber threats and human mishap (like the example in this blog) allow us to sleep better at night!
In short, think twice, approve once, explain every time.
