The subject of Unified Communications (UC) isn’t really all that new. But due the ongoing professionalization of these solutions, the systems have gotten a boost in popularity within company environments. Combining real time communications methods, these systems offer new possibilities and adds efficiency.
Microsoft Lync is a commercial solution that is gaining more and more ground. Therefore, Lync is being used as an example to show the security concerns that come with UC.
Before Lync or any other UC Framework is being looked at in detail, you’ve got to ask yourself some basic questions.
UC-Services combine mechanisms of communications. Typically, they’re the following:
These mechanisms all come with their unique functionalities that first play a role when a UC-product is being evaluated. At the latest these functionalities become important is when it comes to conceptualizing, integrating and configuring the system.
More than one of these functionalities can become relevant to security. Among others, these are:
From a security conscious standpoint, it is smart to work with systems that are as minimalistically designed as possible. By doing this, you can minimize the possible attack surface.
If a functionality is desired due to company-needs, it should be evaluated and the implementation should be structured. In any case, there should be a minimum of guaranteed security.
Lync manages and hosts several server components across the entire UC construct. The various servers take on different roles. These roles provide various functionalities.
This modularity should result in high flexibility on more than just one level, which should be evidenced in the zoning concept. The following table gives a concise overview over these server roles.
|Standard Edition Server||The Standard Edition Server can be deployed in smaller environments to supply the environment with the core functionalities of Lync in an uncomplicated way.|
|Front End and Back End Server||In a Lync Server Enterprise Edition Deployment the front end and back end servers are required. The front end server supplies the core mechanisms (such as authentication, presence information and the list of contacts). The back end server supplies the database on a MS SQL basis.|
|Edge Server||The Edge Server poses as the intersection between external communication. These can be offsite-access, connections to partnered organizations (Federations) or public services such as Windows Live, Google Talk or XMPP.|
|Mediation Server||The Mediation Server is responsible for the conversion to Voice and Dial-In intersections. This includes the public phone network (PTSN), IP-PBX and SIP (Sesssion Initiation Protocol).|
|Directors||Directors are dedicated authentication systems that should force a disconnect of core-components|
|Persistent Chat Server||The Persistent Chat Front End Server supplies the environment with persistent chat rooms (similar to IRC). The Persistent Chat Back End Server saves the information concerning communication and chat rooms. Using the optional Persistent Chat Compliance Back End Server the data can be stored in a reliable and comprehensible way.|
During the transition from Lync 2010 to Lync 2013 some server roles have been removed or have changed. This has a significant influence on how Lync-environments have to be conceptionalized, integrated and maintained. These changed roles are:
|Lync 2010||Lync 2013|
|Archiving Server||optional feature of every Front End Server|
|Monitoring Server||optional feature of every Front End Server|
|A/V Conferencing Server||Part of the Front End Server|
|Group Chat||Persistent Chat Server|
|Director (required)||Director (optional)|
The architecture of a solution is dependent on the deployed product. Lync uses Topology Types. Microsoft offers the so-called Planning Tool that offers a Wizard which will compile the structure based on individual needs using only a few mouse clicks.
Due to the various server roles Lync shapes up according to different architectural constellations. Central questions that have a significant influence on the topology are:
Lync offers additional compatibility with other mechanisms. For example, Exchange Unified Messaging (UM) and Outlook Web Access / Outlook Web App cab be tied into a Lync architecture. These intersections have to be taken into consideration when drawing up the topology of the environment.
Accordingly, the Lync infrastructure can turn out to be rather complex when deployed in a bigger company that wants to use all of the functionalities that Lync can provide. The following graphic illustrates such a construct. Usually, Lync constructs can utilize already existing zonings, assuming they’re up to the time’s standards.
A basic rule of applied information security says that the reduction of complexity usually means a gain in security. Therefore, it is advisable to build an environment that is as simple as possible. Unnecessary components, functionalities and intersections should be avoided. Ideally, they’re never built in or even installed on the system.
If they’re present despite these precautions – due to them being core components or installed as a preparation for future deployment – they should be at least deactivated or protected by means of configuration settings.
The biggest exposure is seen when Federations allow access to partner organizations, for example. Communication using an Edge Server must be secured explicitly in that case. This includes configuration settings that deactivate Partner Discovery and prevent _NTLM-Lockouts:.
Certificates play an important role in the world of Lync due to the fact that they assure a confidential communication between the central communication partners. This includes:
This means that there should be conscious effort furthering the roll-out of trusted certificates (Lync tries to simplify this by using a Wizard).
Even though the mechanisms to go with this have been known for years, companies still have difficulties tackling this challenge successfully. Should these be the case, then Lync can be seen as a chance to implement an additional process that could be of benefit to already existing and future projects.
Because UC-solutions are usually implemented in order to replace existing means of communication, they have to meet considerable requirements concerning availability. Should one component glitch, the entire communication might be disrupted. This can have grave consequences for the productivity of a company, not just internally, but also externally. That’s why it is of the utmost importance that the focus lies on the availability of the solution right from the get-go.
There are various options to achieve a high availability. Their implementation is dependent on the product used, the technologies it’s based on and the concept it uses.
Lync, for example, plans for Pool Pairing to be implemented. This can be done for both Front End and Back End Pools. A pairing like this leads to a regularly occurring check of the availability of the communication. Should it not be available for a predetermined amount of time, another pool is being used. To implement this, the single servers have to be configured accordingly. This can be done using very few command lines. Of course, a DNS-Loadbalancer can be used to distribute the server load in general.
The Back End uses SQL-servers. Using these, Database Mirroring can lead to high availability. However, this functionality is only offered in MS SQL server 2012 and is apparently not going to be included in future versions. Lync 2013 requires MS SQL Server 2008 R2 in order to be able to use SQL Mirroring.
Lync assumes that there can be a bypass for analog devices. Should the network connection or the internet connection fail, the switch to an analog line is a direct one, which maintains availability of basic services such as telephony and faxing.
Logging and monitoring are two central aspects to provide a business with transparency and comprehensibility during operations. Therefore, this must be planned early on and never neglected even after deployment.
In Lync 2010, logging was a rather decentralized ordeal. The Logging Tool had to be activated on every server in every Pool. Logging across multiple Pools was a rather big task. In Lync 2013, a centralised method is being implemented. The Logging Agent is launched on the servers in the Pools and log data is sent to the Logging Controller.
The archiving of messages can be done by either tying Microsoft Exchange into the infrastructure or by using a dedicated archiving server (Lync 2010) or an archiving database (Lync 2013)
Unified Communications (UC) is something that is of great importance in today’s world. And it’s very interesting from both a security and an operations standpoint. Using Lync as an example, it has been proven, that there are many factors that have to be considered.
To master the complexity that comes with a UC-solution is of the utmost importance, seeing as a secure solution is only possible if it is carefully planned, utilized and monitored. Focus should be put on the removal of unneeded features and the mastery of the existing functionality. This way, a solid level of security can be achieved.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here