Wrap-up: Hack-Lab 2017#2

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements. This hack-lab took place in our office in Bern.



The following topics, tools and technology has been discussed during this Hack-Lab:

  1. Threat Modeling and Security Concept session
  2. CMS Assessment
  3. JWT4B development
  4. GnuRadio door bell analysis
  5. Windows Share Enumeration Tool
  6. Exploit.courses testing and training


Topic #1 -Threat Modeling and Security Concept session

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his knowledge about threat modeling and security concept creation and analysis with colleagues.

Information Security fundamentals:

  • Security Foundations – CIA
  • Security Design Principles
  • Threat Modeling and Standards

Security Concepts:

  • Ownership and Data Classification
  • Architecture and Network Topology
  • Web Security Controls
  • Operational Security

Topic #2 – CMS Assessment

Using different available security and hardening scanners, we try to asses the security of three CMS: Drupal, Joomla, WordPress.

The goal is to find new vulnerabilities and possible test cases. We refresh and update our Compass Knowledge and improve our tool-set for CMS security assessments.


  • Drupal
  • WordPress
  • Joomla
  • Web Scanners written in Python

Topic #3 – JWT4B development

We create a Burp plugin which helps the analyst testing apps which uses JSON Web Tokens (jwt.io).

The first step, which we performed in the previous hacklab, was to create a basic prototype, which enables Burp to visualize the tokens. During this hacklab we increased the functionality, implemented signature checking and interception functionalities.

Here a screenshot of the signature-checking functionality. The correct key was provided by the tester, which enables him to modify the JWT token comfortably:


  • Java
  • JJWT (library)
  • JWT

Topic #4 – GnuRadio door bell analysis

We analyzed a wireless door bell with the help of GnuRadio and HackRF One. We captured the ASK modulated signal, and stored it as digital bitstream in a file. Afterwards we could successfully replay the stored bitstream, making the door bell ring. The next step will include to further analyze the bitstream. 


  • GNU Radio
  • HackRF One SDR
  • Kali Linux

Topic #5 – Windows Share Enumeration tool development

If a pentest is performed in a large environment, it is possible that hundreds of accessible Windows shares are available in the network. The goal is to create a tool, which supports us during our penetration tests. Our tool should display the following information for every share in the network:

  • IP Address
  • Hostname
  • Share Name
  • 20 top level files and directories
  • ACLs for the top level files and directories

We managed to implement this tool by combining  Linux Samba tools (smbclient, smbcalcs) in an advanced shellscript.


  • Windows, filesharing, network share
  • ACL, Permissions
  • masscan
  • samba / smbclient / smbcacls
  • Linux, Shell, Scripting

Topic #6 – Exploit.courses testing and training

Dobin Rutishauser teaches the “Exploiting & Defense” part of the Application- and Software-Security module at the Bern University of Applied Sciences (Berner Fachhochschule). For this assignment he created a website which provides writeups and challenges to be solved by the students. It also hosts dedicated per-user Linux container, accessible via JavaScript terminal. The Hack-Lab was used to check the website for usability problems, resistance against local DoS attacks, security problems and also basic functionality checks. We also performed a review of some of the writeups, where the team members solved several of the challenges. This includes the ARM buffer overflow challenge, and an extended version of the shellcode development challenge.

The team could identify several small bugs, some small mistakes in the writeups, and gave valuable usability improvement feedback.


  • qemu, LXC / LXD
  • x86, x64 and ARM
  • gdb, readelf and python
  • AngularJS and go

Wrap-up: Hack-Lab 2017#1

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements.



The following topics, tools and technology has been discussed during this Hack-Lab:

  1. SharePoint Security
  2. Bypassing Android 7.0 HTTPS Apps Certificates Restriction
  3. JWT4B
  4. CodeInspect
  5. Smart Meter
  6. DNS Tunnel Debugging


Topic #1 – SharePoint Security Lab and Knowledge Sharing

SharePoint is a very popular browser-based collaboration and content management platform. Due to its high complexity, proprietary technology and confusing terminology it is often perceived as a black-box that IT and security professionals do not feel very comfortable with.

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his research work with colleagues. They challenged his findings and shared their thoughts on pros & cons of security relevant settings. The outcome of this Hack-Lab session will be shared in a series of blog posts within the next couple of weeks.

The research in our very own hands-on SharePoint lab allows us to gain an in-depth understanding of any type of SharePoint environment, be it a purely internal collaboration web application, a platform to share information with external partners or a publishing site hosting the company website. To build or assess a secure SharePoint environment one needs to understand the importance of governance, logical and physical architecture, network topology, active directory considerations, authentication and authorization, segregation of classified data, hardening and most importantly web security relevant settings to make sure the built-in protection measures are effective. Like other modern Microsoft products, an out-of-the-box SharePoint installation can be considered secure. However, there are so many weirdly named settings which heavily depend on each other that misconfiguration is likely to happen, leaving the door wide open for unauthorized access by adversaries with SharePoint skills.


  • SharePoint Server 2010 & 2013
  • Web Applications, Site Collections, (Sub-)Sites, (Custom) Lists, Document Libraries, Web Part Pages, Web Parts, Apps
  • Web Security, Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF)
  • Navigation Links
  • Web Sensitive Files, permission to Add & Customize Pages and Scriptable Web Parts, e.g. Content Editor and Script Editor (“SafeAgainstScript=False”)
  • Browser File Handling
  • Web Page Security Validation (aka Anti-CSRF token)
  • Lockdown Mode Feature
  • Remote Interfaces SOAP, CSOM, WCF Service, REST Interface
  • Server-Side Controls
  • .NET Sandboxing, Sandboxed Solutions and Apps
  • Self-Service Site Creation
  • Developer Dashboard
  • Audit Logs
  • People Picker

Topic #2 – Bypassing Android 7.0 HTTPS Apps Certificates Restriction

With Android 7.0, apps do not trust user imported certificates anymore.  Intercepting app network traffic with a proxy has become more complicated.

The goal is to find or create a custom application which is explicitly developed for Android 7.0. Then to configure the app with the network_security_config.xml file, which is used to bypass this restriction,  and therefore enables user defined certificates.


  • Android Studio
  • Android 7.0
  • Apktool

Topic #3 – JWT4B

Create a Burp plugin which helps the analyst when testing an app that uses JSON Web Tokens (JWT.IO).

Frist step is to create a prototype which enables Burp to visualize the tokens. On further hacklabs it should be possible to automatically perform JWT attacks.


  • Java
  • JJWT (library)
  • JWT

Topic #4 – CodeInspect

Evaluation of CodeInspect’s features.

Determine if CodeInspect could be used to make future  Android app analysis assessments more efficient.


  • Java
  • Android

Topic #5 – Smart Meter


An Energy Monitoring System was provided for testing. It is used to measure the current consumption and provides various interfaces. Web browser (TCP/IP) and Modbus are the main ones.

Assess the security of the interfaces. What can an attacker exploit if given network access to the device?


  • TCP/IP
  • Modbus
  • HTTP Web Application

Topic #6 – DNS Tunnel Debugging

Compass Security has its own trojan toolkit which we use for responsible phishing attacks in mandate for our customers, and also demos and proof of concepts. The trojan also implements DNS tunneling.

Analyze the source code and perform debugging to identify and fix some reliability issues while performing DNS tunneling with multiple clients.


  • C++

Lync – Missing Security Features

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.


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


[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, http://blog.csnc.ch/2014/01/lync-top-5-security-issues/, last visited 20.02.2014

[4] Lync – Privacy Configuration, http://blog.csnc.ch/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.

Lync – Privacy Configuration

We have shortly described the Lync federations in a previous post. With the usage of federations the question comes about the privacy and the security of the user’s information (e.g. presence information). There are scenarios where an employee doesn’t answer the phone but is mentioned as “available” in Lync. This could lead to a misunderstanding and bad mood at the customer’s or a partner’s side because the person “should” be available. Other scenarios involve e.g. stalking a given person using his present / idling status. These are just two practical examples – without mentioning any legal aspect – why there are good reasons to restrict access to this kind of information.

A further restriction could be set to only allow communication request of persons who are already in the contact list. Lync doesn’t offer many options for this. So in this post we try to show you the spot to look at to enhance privacy in Lync.

The following cmdlets are involved depending on your infrastructure:

  • CsPrivacyConfiguration
  • CsAccessEdgeConfiguration
  • CsHostingProvider
  • CsPublicProvider

Lync offers an option to limit access to your presence information to the people you already have in your contact list. Unfortunately, there is no distinction of corporation: you can’t just give access to your presence information to people of your company while restricting access for federated contacts present in your contact list. So either restrict access for all or nobody in your contact list.

Quote from “Configuring Enhanced Presence Privacy Mode” [2]:

“With enhanced presence privacy mode, users can restrict their presence information so that it is visible only to the contacts listed in their Lync 2013 Contacts list. The New-CsPrivacyConfiguration and Set-CsPrivacyConfiguration cmdlets have an EnablePrivacyMode parameter controls this option. When EnablePrivacyMode is set to True, the option to restrict presence information to contacts becomes available in the Lync 2013 Status options. When EnablePrivacyMode is set to False, users can choose either to always allow everyone to see their presence information or to adhere to any future changes the administrator makes to the privacy mode.”

PS> Get-CsPrivacyConfiguration

Identity : Global
EnablePrivacyMode : True
AutoInitiateContacts : False
PublishLocationDataDefault : False
DisplayPublishedPhotoDefault : False

Further quote from [2]:
“[…]Lync 2013 and Lync 2010 privacy settings are not honored by previous versions (Microsoft Office Communicator 2007 R2 or Microsoft Office Communicator 2007). If previous versions of Office Communicator are allowed to sign in, a Lync 2013 user’s status, contact information, or picture could be viewed by someone who has not been authorized to view it […]

In a migration scenario and due to these aforementioned compatibility reasons, enforce the following points before you enable enhanced presence privacy mode:

  • Ensure that every user has Lync 2013 installed.
  • Define a client version policy rule to prevent previous versions of Communicator from signing in.


Lync Server 2013 has public provider configurations for America Online, Windows Live and Yahoo! instant messaging. Each public provider is configured with the provider’s Edge server fully qualified domain name, and the default verification level is set to “Allow users to communicate only with people on their Contacts list who use this provider” (CsHostingProvider and CsPublicProvider). This default setting will limit communication to contacts that you have accepted and are in your contact list.

Selecting “Allow users to communicate with everyone using this provider” removes the restriction. Anyone can now retrieve your presence information, without you received and accepted a contact invite. This setting does not limit who can contact you from the public provider’s network.

A further VerificationLevel property is used to monitor and assess the verification level of incoming messages (CsAccessEdgeConfiguration, [3]). Valid values are:

  • AlwaysVerifiable: All requests received on the default route are marked as verified. If a verification header is not present it will automatically be added to the message.
  • AlwaysUnverifiable: Messages are passed only if the addressee (the user the message is intended for) has configured an Allow ACE (access control entry) for the person who sent the message.
  • UseSourceVerification: Message verification is based on the verification level included with the message. If no verification header is present then the message will be marked as unverified.

We strongly recommend to use “AlwaysUnverifiable” for the VerificationLevel.

There are not many options to limit access to presence information and how the communication is established to federated users, but the few options should be evaluated during the implementation phase. With the privacy setting, the users are able to restrict access to their presence information for those people who are on their contact list.

We recommend to use the privacy mode and to restrict the communication establishment as strictly as possible.

[1] Privacy supplement for Microsoft Lync 2013, http://office.microsoft.com/en-us/lync-help/privacy-supplement-for-microsoft-lync-2013-HA102762444.aspx, last visited 26.01.2014
[2] Configuring Enhanced Presence Privacy Mode, http://technet.microsoft.com/en-us/library/gg399028.aspx, last visited 26.01.2014
[3] Set-CsAccessEdgeConfiguration, http://technet.microsoft.com/en-us/library/gg413017.aspx, last visited 26.01.2014

Lync – Top 5 Security Issues

Microsoft Lync Server (a combination of “link” and “sync”, see [6]) communications software offers instant messaging (IM), presence, conferencing, and telephony solutions. Lync can be integrated with SharePoint or Exchange to extend its functionalities. Users can e.g. search for specific skills within the Lync client when SharePoint integration is enabled. Exchange is used as a unified store of different user specific data, like contact list.

As we are seeing in our daily business, Lync is becoming more and more a widespread collaboration platform within many companies. Therefore, it’s important to know the issues when implementing Lync and especially the hot spots for weaknesses to keep in mind during concept creation. This blog post will describe some of the top issues, without formal priority.

Lync has many security features built-in. Encryption is for example used by default and cannot be turned off since Lync Server 2013. Furthermore, internal user authentication is handled via Kerberos or client-certificates.

On the other hand, some features like the Federations (connection with other companies) highly increase the attack surface. Additionally, external users can authenticate themselves with NTLM. Therefore, attacks against the user accounts are possible. When not using Federations and external access, many security implications could be eliminated if no Edge server is in use. On the other side, the ease of the use of external access is a great advantage in Lync.

A very basic Lync topology is depicted in the following picture to show the weak spots described later in this post. The numbers on the arrows refer to the sections below.
Lync Topology diagramEdge Server allows us to communicate and collaborate with users located outside the firewall. Remote users (internal users working outside the network) or users from other companies (Federations) connect into the network through the Edge server.

Front-End-Server is used for user authentication and handling of all communication features (IM, voice). It’s responsible for registration and routing requests. All Web components, such as Address Book or the Control Panel (administration panel) are located on the Front-End-Server.

The Director role is used as an intermediate stop between the external users and the Front-End-Server. The Director does not host users but, as a member of an Active Directory domain, it has access to Active Directory Domain Services for purposes of authenticating remote users and routing traffic to the appropriate server or Enterprise pool. Directors can authenticate requests before they are passed to the internal servers. DoS attacks ends on the Directors and don’t reach the Front-End-Servers.

External access (remote users and Federations) is the possibility to use the Lync infrastructure from outside the company’s network. Federations give the possibility to communicate between different companies using Microsoft’s unified communication software. Full communication is possible (VoIP, messaging, conferencing). Remote access is also possible with mobile phones.

1. Threats because of Federations
The following policies are used to control federations and external access:

  • CsExternalAccessPolicy
  • CsAccessEdgeConfiguration

To allow federation on the Edge Server use the following PowerShell command (“Import-Module Lync” if the normal PowerShell is used):

Set-CsAccessEdgeConfiguration –AllowFederatedUsers:$True

Read the AccessEdgeConfiguration:


A further step is needed: every user must be covered by a CsExternalAccessPolicy that enables federation for those users.

Set-CsExternalAccessPolicy –Identity <scope> -<Enable*Access>
  • <Enable*Access> can be one of the following, depending on your needs: EnableFederationAccess, EnableOutsideAccess, EnablePublicCloudAccess, EnablePublicCloudAudioVideoAccess, EnableXmppAccess
  • EnablePartnerDiscovery should be set to false, to restrict federation to those domains specified manually. Otherwise, it enables open federation where companies looking to federate will locate each other through the DNS SRV records and connect automatically.
  • Be careful which external access is allowed for which users (federation, remote user, public IM connectivity, see [5] for more details about the different possibilities).

To see which domains are allowed and/or blocked, use the following get-cmdlets:


Inspecting chat traffic and disabling file transfer for only external communication is difficult in Lync. There is no known solution which implements this need. However, traffic monitoring could be applied for specific connections but preventing leakage of a company’s data isn’t available out of the box. This must be considered and kept in mind when using Federations or other external access.

If not used, Federations should be deactivated to mitigate the new possibility to exfiltrate data from the internal network to the outside and therefore bypass possible existing data leakage prevention (DLP) mechanisms.

2. NTLM AD lockouts without proper Edge Server security
The Edge server receives the authentication requests from external users and passes them to the Director resp. to the Front-End-Server. The authentication itself is performed by either one of these two servers inside the network against the Active Directory (AD). NTLM authentication is used when certificates aren’t available.

Therefore, NTLM lockout attacks could be performed against internal users. To mitigate this issue, block NTLM requests from outside and use only certificate based login for external users. This can be enforced by a policy which requires that the initial login request (always NTLM or Kerberos based) is only performed from inside the internal network.

Besides blocking NTLM request, the use of a security filter on the Edge server could be used to prevent the lockout of internal AD user. Such security filters handle failed login attempts on the Edge Server and don’t pass every login request to the Director or Front-End server.

3. The “Certificate-based-login” pitfall
Using certificate authentication has many advantages. One of them is availability: when a domain controller is not reachable, users can still log in because authentication relies solely on the client certificate. However, if the users are disabled in Lync and/or in the AD, they can continue to log in (which was an advantage one sentence earlier). Business processes such as those handling the decommissioning of user accounts must be adapted accordingly to prevent further usage of Lync for a disabled user (see [2][3]).

You can read the certificates used by a user with the following PowerShell command:

Get-CsClientCertificate –Identity <userID>

Revoke these certificates with the following command:

Revoke-CsClientCertificate –Identitiy <userID>

<userID> is the SIP name of the user, e.g. sip:name@lync-domain.tld

You can also use the Control Panel to revoke the certificates by using “Remove user certificate” on the specific user.

Really important side-note: A certificate is generated for each individual client, not each user. So the same user can have many certificates depending on the amount of devices he installed Lync on.

4. No End-To-End Encryption
The IM and web conferencing are encrypted between the different Lync components (e.g. Client and Front-End) but not end-to-end from the Client to the Client. There is no mitigation for this within the Lync environment and must be considered when evaluating it. This has different desired and needed reasons, e.g. archiving, monitoring or troubleshooting. Audio and video can’t be archived and are always encrypted between the endpoints (for federated partners, the Edge server is still in the middle). See [4] for more details about the communication paths.

However, the ability of snooping traffic on the Front-End-Server conflicts with the requirements for privacy and end-to-end encryption. Even Microsoft itself gives detailed instructions how to intercept the traffic, for troubleshooting reasons of course (e.g. [1], could also be done with Wireshark). And don’t forget the Lync archiving mechanisms which record all the data.

5. Role-Based Access Control (RBAC)
Lync introduced RBAC in Lync Server 2010 and enhanced it in Lync Server 2013. With RBAC, administrators can be granted only permissions they really needed for their tasks. An administrator is e.g. granted the rights to run certain PowerShell cmdlets. Cmdlets are used in the PowerShell to perform an action and typically return a Microsoft .NET Framework object to the next command in the pipeline. Besides a nice collection of predefined RBAC roles, custom roles can be created and then used to secure the execution of specific cmdlets.

The really important fact is, that RBAC only takes effect when you are using PowerShell or the Lync Control Panel (which in fact only executes cmdlets) remotely. You can see the cmdlets you are allowed to run by executing the following command:


To see the allowed cmdlets for a specific role, use the following command

Get-CsAdminRole [-Identity <role-name>]

The “Cmdlets” description is limited within this output. With the following command, you can expand this attribute:

Get-CsAdminRole –Identity <role> | Select-Object –ExpandProperty Cmdlets

When using the LSMS (Lync Server Management Shell) or the Control Panel on the Lync Server, the RBAC isn’t used. Instead the administration rights are governed by membership of the Real Time Communications (RTC) named groups.

Check roles and users in the special Lync groups and apply a strict RBAC approach. Follow the least privilege principle and only grant minimal permissions for the required cmdlets.

The most powerful Lync RBAC groups are:

  • CsAdministrator
  • CsServerAdministrator
  • CsUserAdministrator

Interesting fact: although CSAdministrator has the most functionality available in a role, it doesn’t enable you to run all the commands that exist in the Lync PowerShell.

The most powerful Lync RTC groups are:

  • RTCUniversalServerAdmins
  • RTCUniversalUserAdmins

As we just saw, Lync is a versatile solution which affects different components in an existing infrastructure. A default Lync installation has many security features available and enabled. It is important to understand its architecture and features before implementing it. There are different issues which must be kept in mind when using Lync. The above list should give you an overview about different spots to look at. We’ve seen that Federations gives a great new possibility to easily connect companies, but there are privacy issues and the NTLM attack vector which could be opened when not using the correct configuration. Or the new certificate based login approach increases the security of the login procedure but raises the new risk that a disabled user can continue using Lync.

This leads to the conclusion that despite a quit secure default installation of Lync, a proper understanding of all the security features and configuration must be acquired and applied to provide the most secure environment.

Further blog posts regarding Lync security features:

[1] http://blogs.technet.com/b/nexthop/archive/2012/02/15/how-to-decrypt-lync-2010-tls-traffic-using-microsoft-network-monitor.aspx, last visit on 15.01.2014
[2] http://www.expta.com/2011/03/disabling-user-in-ad-does-not-disable.html, last visit on 15.01.2014
[3] Mastering Lync Server 2013, Keith Hanna, Nathan Winters, 2013, p. 90
[4] Microsoft Lync Server 2013 Protocol Workloads Poster, http://www.microsoft.com/en-us/download/details.aspx?id=39968, last visit on 15.01.2014
[5] Overview of External User Access, http://technet.microsoft.com/en-us/library/gg398775.aspx, last visit on 15.01.2014
[6] Lync Server 2013, http://office.microsoft.com/de-ch/lync/, last visit on 15.01.2014

Lean Risk Assessment based on OCTAVE Allegro

The article will provide a quick overview and introduction into the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Allegro [1] methodology, its approach and terminology. OCTAVE Allegro is an asset centric and lean risk assessment successor of the OCTAVE method. The method supports a straight-forward qualitative risk assessment and structured threat analysis which mainly fits for smaller organisations (few hundred employees). Figure 1 is based on [2] and groups the methodology steps into four major phases.

OCTAVE Allegro Phases

  • Phase “Establish Drivers” aims to justify and prioritise the measurement criteria for risk for a specific organisation.
  • Phase “Profile Assets” is designed to identify and document logical, technical, physical and people assets.
  • Phase “Identify Threats” focuses on the identification of threats against the identified assets.
  • Phase “Identify and Mitigate Risk” supports the valuation of the risks posed against the critical information assets. Finally, after this step, the mitigation strategy for each of the identified risks is defined.

Figure 1: OCTAVE Allegro steps and phases [2]

OCTAVE Allegro Steps

This section goes through all of the OCTAVE Allegros steps to provide an introduction into the methodology. Moreover, each step will be accompanied by a fictitious example related to AMI. Note, that dark coloured steps in figure 1 are considered major steps in order to conduct a threat analysis whereas light coloured steps are crucial when approaching a complete risk assessment.

Step 1 advises to identify all areas that impact an organisation. The methodology requires for a minimum set of areas which includes safety, health, productivity, reputation, financial and fines. For each of the impact areas, a set of criteria to measure low, medium and high impact must be developed. Table 1 provides an example for loss of revenue in case of data privacy violation. Finally, the major areas will be ranked and assigned values in order to allow for risk scoring. In case five areas have been identified and “legal penalties” is considered the top risk area, then the area would be assigned a five. An example is provided in table 6.

Table 1: OCTAVE Allegro Step 1: Establish Risk Measurement Criteria. Impact Area Example

Step 2 provides guidance in identifying critical information assets for the organisation. The methodology also provides a set of questions and asks for example for the value of assets or the dependency on assets for the day-to-day business of the organisation. Each identified information asset will be attributed additional cornerstone such as the security requirements to make up a whole information asset profile. An example for key material in a smart meter is provided in table 2. Moreover, each profile’s most important security requirement is being identified to support the later valuation of the potential impacts. OCTAVE Allegro does not provide much guidance and structure on how to identify security requirements. A way to model such requirements is by means of misuse cases [3]. The misuse case approach lends it from the unified modelling language (UML) such as used in common software engineering processes where success and fail scenarios of interaction with data and processes is being modelled. Though, the modelling of misuse cases rather focuses on the abuse of such scenarios by malicious actors (misusers).

Table 2: OCTAVE Allegro Step 2: Develop Information Asset Profile. Critical Information Asset Example

Step 3 collects information asset containers in the form of an information asset risk environment map. Information asset containers, as the name implies, can hold, process or somehow get in touch with information assets. The methodology classifies containers as technical, physical and people. Table 3 provides examples for each of the types. Correspondingly, containers are being attributed whether they are of type internal which means under control of the organisation or whether the container is external.

Table 3: OCTAVE Allegro Step 3: Identify Information Asset Containers. Container Examples

For the analysis of an organisation the type column can be attributed with minimal effort. However, for an abstract analysis such as network protocols or embedded devices, some assumptions must be made. There is no general rule on what assumptions to make.

Step 4‘s goal is to identify major areas of concern. Thereby the method foresees to consider all containers and to identify issues that could affect assets within the container. The compiled list of “areas of concern” is then expanded with the according actor, the means to realise the threat, the motive of the actor and the potential outcome. Whereby an outcome is always one out of disclosure, modification, interruption or destruction. The method documentation further lists loss next to destruction. An example, implicitly referencing the affected information asset, is provided in table 4. This step does not aim to identify a complete list of threats but helps to capture the major concerns in short time.

Table 4: OCTAVE Allegro Step 4: Identify Areas of Concern. Area of Concern Example

Note, that I have made use of this step in order to capture area of concerns for the smart meter and wireless M-Bus analysis within my master thesis.

Step 5 ensures structured identification of all potential threats. Threat trees ensure robust consideration of threats. The step relies on four trees in total. Two considering human actors with either technical or physical means and two considering technical and other problems. Part of the “Human Actors Using Technical Means” tree originating of the methodology documentation [1] is shown in figure 2.

Figure 2: OCTAVE Allegro “Human Actors Using Technical Means” Tree [1]

With each information asset, each branch of the four trees will be traversed to ensure thorough coverage and identification of threats. The guidance provides worksheets and questionnaires to simplify the activity. The result of the walk through will be a comprehensive list of threat entries as shown in table 4. Optionally, each resulting list entry can be assigned the probability of the realisation of the concerned threat scenarios with either low, medium or high likelihood.
As this is a tedious task in an assessment based on OCTAVE Allegro, I would not dig too much into it unless the previous step “Identify Areas of Concern” does not provide sufficient material or the analysis significantly lacks coverage. However, if thorough coverage is a requirement, that step cannot be circumvented.

Step 6 consists of a single activity and aims to identify the impact if a certain threat scenario becoming realised. Following that, each threat scenario will be attributed a consequence. Thus, table 4 has been expanded with an additional column to describe the consequence for each scenario. Part of table 4 and the newly added column is shown in table 5.

Table 5: OCTAVE Allegro Step 6: Identify Risks. Risk Example

Step 7 focuses on creation of a relative risk scores for each identified threat scenario. The impact on each impact area as well as the impact area importance will be reflected in the total risk score. The score should help to decide on what mitigation approach to choose in the ultimate step of the methodology. Assumed the impact area ranking in table 6 and threat scenario listed in table 5 the risk score for that specific scenario calculates as shown in table 6.


Table 6: OCTAVE Allegro Step 7: Analyse Risk. Example Risk Score Calculation

Basically, for each impact area the impact will be measured according to the criteria defined in step 1. An example of such criteria is provided in table 1. High impact will be assigned a value of three and low impact accordingly a value of one. The impact area ranking is then multiplied with the threat scenario impact value whereby the result of that calculation contributes to the total risk score.

Step 8 the ultimate step in the OCTAVE Allegro qualitative risk assessment method deals with the mitigation approach of identified risks. In general risks can be accepted, mitigated, transferred, avoided or being further monitored (deferred) whereas mitigation aims to avoid or limit the risk. However, the efforts for avoidance and limitation should never outweigh a potential impact.
Though numbers have been assigned as risk scores, their specific value only provides indication to whether a risk should to be mitigated or not. One might also take the likelihood of occurrence and some organisation specifics into account. It is suggested to divide the risks into four pools, pool one to pool four, whereby each pool groups threats for a range of the total risk score. The four pools are then approached as follows:

  • Pool 1: Mitigate
  • Pool 2: Mitigate or Defer
  • Pool 3: Defer or Accept
  • Pool 4: Accept

Depending on whether probabilities have been assigned in step 5 of the methodology it is suggested to either form a list of all risks and then split it into four pools or create a matrix which reflects the four pools and takes the probability into account. Finally, a mitigation strategy should be formulated for all risks that need to be mitigated. The mitigation strategy should list the information asset container to which the controls will be applied. Plus, the chosen strategy should consider and outline potential residual risks. An example of such a mitigation strategy is provided in table 7.

Table 7: OCTAVE Allegro Step 8: Select Mitigation Approach. Mitigation Strategy Example


OCTAVE Allegro is a lean risk assessment method and does not provide guidance in selecting security controls as with extensive information security management standards such as ISO 27000 [4]. However, ISO 27002 [5] and NIST SP 800-53 [6] provide a comprehensive list of controls to choose from, if needed.


[1] R.A. Caralli, J.F. Stevens, L.R. Young, W.R. Wilson. The OCTAVE Allegro Guidebook, v1.0. Cert Program, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213. May 2007, Online http://www.cert.org/octave/allegro.html
[2] R.A. Caralli, J.F. Stevens, L.R. Young, W.R. Wilson. Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process. CMU/SEI-2007-TR-012, CERT Program, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213. May 2007, Online http://www.cert.org/archive/pdf/07tr012.pdf
[3] G. Sindre and A.L. Opdahl. Eliciting security requirements with misuse cases. Requirements Engineering Vol. 10 No. 1, pp. 34-44. Jun. 2004 (DOI 10.1007/s00766-004-0194-4)
[4] ISO-27000:2009: Information technology – Security techniques – Information security management systems – Overview and vocabulary
[5] ISO 27002:2005: Information technology – Security techniques – Code of practice for information security management
[6] NIST. Security and Privacy Controls for Federal Information Systems and Organizations. Special Publication 800-53, Rev. 4, Final Public Draft, Feb. 2013, Online http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800_53_r4_draft_fpd.pdf