Skype for Business security challenges – part 3

This is the third part of the topic: ‘enhancing Skype for Business environments’. In case you miss, check part 1 and part 2 to get the full picture.

On the previous topic post I focused on the ‘challenges’ on exposing user accounts and service from unauthorized access or DDOS. But now let’s see the scenario with authorized users using the collaboration features.

As mentioned before SfB is a tool that enables collaboration between people: any device, anytime and anywhere. And with federation you just extend all these capabilities with people across the world (specially with open federation).

meeting-collaboration

But the ‘openness’ of the features can sometimes expose more information than people want to unintentionally share, or worse: intentionally!

 

Let’s use a reverse example: in a traditional meeting room you share information with a specific group of people. If it’s confidential you want to make sure that the information keeps private (closed room), that only the right participants are present, no open doors and all whiteboards, slides erased before leaving the meeting.

It should be the same on a SfB Meeting, right? But from my experience, who checks if the meeting URL is private and no available for guest access? Did you select ‘End Meeting’ when it finished? Did you remove all the shared content that was uploaded?

Another unintentional situation: How many of you sent a username and password using a chat session ? I did 🙂 (and regret it sometimes)

Federation is a great capability of SfB (I loved it, really!), but it can also go against you. Others can see your presence, ‘chat-noying’ and, on extreme cases, it can show more than you think.

Let’s use the picture of a federated test contact that I have on my SfB. This is what you can see from you contact when he changes the privacy level:

ContactCard-privacy

(1) external contacts

(2) Colleagues

Workgroup

Friends and family

Presence

X

X

X

X

SIP

X

X

X

X

Email

X

X

X

X

Title

X

X

X

X

Company

X

X

X

X

Department

X

X

X

X

Office

X

X

X

Work phone

X

X

X

Mobile

X

X

X

Time zone

X

X

Home Phone (3)

X

Other Phone (3)

X

(1) default when adding federated contacts

(2) default for internal company contacts

(3) values set manually by the user on the SfB client

‘So what?’ some people ask
What if the customer finds out that you are an outsourcer, when you mentioned that you work on the main contractor? What if someone based on an email looks on the recipients and locates one the VIP? Why contact you for urgent matters if they can ‘escalate’?

The most extreme example is in fact a risk: Would you allow collaborators on a bank to share their desktop with outside participants and give remote control. The quickest corporate espionage is based on a rogue employee exposing sensitive data to competitors. SfB and other similar tools can be a good tool.

I can hear the readers thinking: this guy is paranoid !!
Answer: I’m not 😉  My out-of-the-box thinking always covers security aspects of the projects that I participate

SfB provides to SysAdmins several features to control and limit on how people collaborate, but in some situations it lacks of granularity. Let’s see some examples:

  • You can limit the modalities (can share desktop, application, remote control, use audio/video) on a per user basis. BUT… not per group of users
  • Remember the extreme case of undesired desktop/application sharing? You can block with policy. BUT… what if the end-user support is outsourced and you want your users to share the desktop with them ? or with any ‘company group’ domain partner?
  • You can in fact block your contact card and presence, by setting that only users on your contact list. BUT… it will do it for all external and internal contacts

Other examples of situations that you can think when administrate SfB:

  • Limit federated contacts to reach VIP’s or specific departments
  • Block showing internal presence status to all external users.
  • Prevent an internal user to share an application but allow external user to share with that user.
  • Scan file transfer for virus/malware

And then you get your Legal department with security concerns and compliance policies:

“We need to prevent disclosure of confidential data (ex: block or alert in case confidential project code names, share customer data that violates GDPR rules)”

This 3rd part was also the last one on enumerating the challenges. The next one(s) would be on how to mitigate them.

One thought on “Skype for Business security challenges – part 3

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.