Microsoft has published a list of key security features [1] and also their security framework [2] for the Lync Server 2013. Those documents show how deeply MS integrated their SDL in the Lync products. It also indicates that Lync provides a solid security base out of the box:

  • Encryption enforced for all communication between Lync clients by default
  • RBAC approach for administration
  • Certificate-based authentication
  • Edge Server within DMZ as a first end point from outside and with no need for joining the domain
  • Good integration into the whole Windows infrastructure

However while Compass Security was reviewing and implementing Lync infrastructures, a few issues surfaced which aren’t optimal from a security point of view.

We have summarized some of the missing security features in Lync. As with our previous post about this topic(Lync – Top 5 Security issues, [3]), this list is not a finished catalog. But it may be helpful for others in an evaluation phase, or during implementation, to identify potential pitfalls.

Security Settings

One of the first things we got stuck with is the way security options are set (either with PowerShell or with the Lync Control Panel). All the security-relevant options are spread through different configuration “cmdlets”, or within different pages in the control panel. It’s like “where the hell is this option again?”.

There is no single place for these options, and it’s therefore difficult to setup a secure installation without detailed and in-depth know-how. Exchange 2007 and 2010 administrative interfaces are able to show the corresponding PowerShell script for each configuration setting, which can be immensely helpful for administrators. Sadly the Lync control does not have this useful feature.

We wish to see a dedicated “Security Settings” tab, and a more concise and well-arranged configuration UI. It should also enable the administrator to view the underlying PowerShell cmdlet’s.

File transfer

The transfer of files directly between Lync users can only be allowed or disabled for all Lync users at the same time (CsConferencingPolicy). A more granular file transfer approach cannot be achieved within Lync.

We would like to have the possibility to set these settings for specific user groups. It should also be possible to restrict (or completely deny) file transfer between internal and federated users.

Additionally, there is a blacklist for file extensions of transmitted files (CsFileTransferFilterConfiguration). However, a whitelist approach would be the preferred choice. For example the “.jar” extension is not in the blacklist by default in Lync 2013, a grave security vulnerability within enterprise environments (because of the high amount of Java vulnerabilities). It’s not difficult to find more extensions which should be blocked (especially if a generic archive tool like WinZip is installed on every workstation, which allows the user to open a myriad of different archive files, each with different file extension).

Furthermore, a dangerous setting is the “EnableFileTransfer” in the “conferencing options”. This setting is a per-organizer setting. Therefore, it is possible for a conference organizer to enable file sharing for conferences created by him, even if file sharing for conferences is disabled. The file transfer restrictions mentioned above can therefore be circumvented by every user which is able to create a conference.

An option should exist for Lync, which disables the ability for conference organizer to enable file sharing.

Some third party tools are able to solve some of the problems mentioned above by implementing more sophisticated filtering of file transfer on the Edge server.

Federation policies

The current implementation of federations assumes that the federated companies completely trust each other, or have at least a similar security policy. It is not really possible to restrict or confine external users. Some policy settings are described in a previous post about the privacy configuration [4].

As different companies may want to easily communicate, but not completely trust each other, we wish for much more granular permission/restriction policy for federated users. For example, it should be possible to only allow IM from internal users to federated users, but deny other communication channels.

Identification of mobile phones and external devices

Currently, every user which provides valid credentials is able to login into Lync. It is not possible to restrict access to certain devices. For example, Lync cannot deny access for insecure Android mobile phones, or only allow iPhones. Therefore, users are able to use Lync on insecure devices, and on as many devices as they want.

It should be possible to restrict access based on the operating system (a feature which already exists, but does not seem to work, CsClientVersionPolicy).

We’d also like to see Lync restricting logins to mobile devices which are managed by the company MDM solution.

Front-End server certificates

The certificates for the TLS-DSK authentication is implemented using the Lync PKI on the Front-End server. A company with an existing PKI can’t use their own certificates.

We wish to be able to use an existing PKI. The process of deactivating users would also fit better within existing company procedures, so that no additional “Lync-certificate-deactivation-process” must be implemented.

Two-factor authentication

The default authentication is based on AD credentials (username and password). It is not possible to enforce a two factor authentication. It was added with the Cumulative Update for Lync 2013 back in July 2013 (e.g. use of Smartcards) [5]. Unfortunately, this update only applies to Lync 2013 Desktop clients.

End-to-End encryption

As already noted in “Lync – Top 5 Security issues” [3], a complete end-to-end encryption is not available. In some scenarios a complete encryption between the endpoints in p2p conversations is a requirement. This is currently not possible with Lync 2013.

Conclusion

Despite a solid security baseline implemented in Lync, there are multiple issues regarding the administration and security needed in an enterprise environment. Lync is designed to easily communicate with different parties and integrates many different media feature like voice, video and IM. For high-sensitive environments this could be considered as too open for a sensitive-communication environment. To conclude this post, the following issues have been discussed: there is no single place for all security settings, file transfer cannot be restricted as needed with standard tools, there is no option to use end-to-end encryption between the clients, and it’s not possible to enforce a second factor for authentication for all devices.

So, we can summarize our wish list for an upcoming release (X-Mas is already over, but a major update is coming in 2014. And the next Lync release is coming too. Maybe.):

  • More obvious and centralized places for the security settings
  • A better file transfer restriction approach
  • A way to implement a second-factor authentication or an integration of 3th party second-factor tools
  • Better possibilities to identify and restrict Lync client devices

References

[1] Key Security Features in Lync Server 2013, http://technet.microsoft.com/en-us/library/dn342829.aspx, last visited 20.02.2014

[2] Security Framework for Lync Server 2013, http://technet.microsoft.com/en-us/library/dn481316.aspx, last visited 20.02.2014

[3] Lync – Top 5 Security Issues, https://blog.compass-security.com/2014/01/lync-top-5-security-issues/, last visited 20.02.2014

[4] Lync – Privacy Configuration, https://blog.compass-security.com/2014/01/lync-privacy-configuration/, last visited 20.02.2014

[5] Planning for and Deploying Two-factor Authentication, http://technet.microsoft.com/en-us/library/dn308563.aspx, last visited 20.02.2014

Thanks to Dobin Rutishauser for research, review and discussions concerning this matter.