Welcome back to my blog series on Security Design Decisions. The intent of this blog post is to explore the need for a solid security framework, since more and more companies are now investing in security automation to fill in the gap.

When designing new implementations, Citrix Consulting uses a layered approach: User Layer, Access Layer, Resource Layer, Control Layer, and Hardware Layer. There are important security decisions associated with each of these layers, and I’m going to walk you through each approach in this blog series. If you missed my first blog post on User Layer, you can check it out here.

In this post, I’ll discuss the intricacies of the Access layer. The access layer is like a great wall that stands between the users and the resources. This is the first line of defense and it cannot be weak, because your security is only as strong as your weakest link. Like the User Layer, we must plan who can access and answer who, what, where, when, why, and how:

  • The who is the client, an end user, vendors etc.
  • The what are resources such as files, applications, desktops, etc.
  • The where is a point of authentication in this hyper connected world, (e.g. NetScaler or StoreFront)
  • The when is time of the day, of the week, of the month and of the year.
  • The why refers to process of approving the access
  • The how is method of authenticating, identifying and performing accounting to track the user.

The who are the end users, which are divided based on risk level (low, medium and high) and value (CEO vs. Contractor). Please refer to Part 1 – of this blog series for additional information regarding the who.

The what are the enterprise resources (e.g. data, hardware, applications, etc.) we intend to protect from any potential risks (e.g. hackers, malware, viruses etc.). In the current age of hyper connectivity and mobility where users can access corporate resources from inside or outside the network, it is becoming increasingly important to identify what we need to protect from threats. 

In the past, external access was risky and internal access was seen as safe, but now, both are deemed equally risky. For example, Google considers all internal networks as potentially dangerous. If both methods of access are equally dangerous, we must raise the security baseline higher. We should invest or leverage in existing tools that enables the enterprise to protect yet provide seamless services to the users. For example, once the users are authenticated at the point of entry, the users are then authorized and directed to their respective silos.

The Citrix NetScaler MPX or SDX series has all the right ingredients to mitigate security threats and risks for both internal or external access. For example, NetScaler AppFirewall can be leveraged to protect the environment against Denial of Service (DOS) attacks, Cross Site-Scripting (XSS) and other security-related attacks. However, we should keep in mind that even if we have the most powerful device at hand, not tuning it to address the security concerns will render the device useless.

The where is the access point: Citrix StoreFront and/or Citrix NetScaler. Which authentication point is preferred will depend on authentication method and session encryption requirements. NetScaler supports a broader range of authentication providers and functions as a reverse secure proxy for ICA traffic. StoreFront, however, supports single sign-on for a more seamless user access experience. Most designs include a combination of NetScaler and StoreFront access points. NetScaler can be deployed fronting the public network to authenticate external or internal user groups. Upon successful authentication, the request should be forwarded to StoreFront for further validation and resource enumeration; finally allowing access to the authorized resources.

The when is time of the day, of the week, of the month, and of the year. This is determined partially by operational requirements: some businesses operate at certain times of the day (e.g. 8AM – 6PM) while others have 24-hour operations. We should clearly separate users that require either 24-hour access (e.g. IT Support) or more limited access (e.g. Task Worker). If 24/7 access is needed to support business objectives, we should strategically implement security controls to monitor the access and alert if an anomaly is detected. For example, using application analytics to identify the location of the user and alert if multiple login attempts are seen in rapid succession from disparate locations, which would indicate fraudulent activity. Besides that, we should also perform periodic audit on the logs to track what was accessed, by whom and when. This will not only assist in identifying new security threats, but also identify users with excessive privileges that have been accumulated over time.

Even if we have the who, what, where, and when figured out, we should not forget about the why: companies need a valid reason to provide access. Some businesses do not have external access requirements or prohibit it for security reasons, while external access is a core business function of other companies. In order for users to be granted access to a system, regardless of the access point, there should be a business justification for the access, which also aligns with a basic security principle of least privilege.

Now, let’s address the last question: how do we provide secure access to authorized users (enterprise users, contractors, vendors etc.) or devices (e.g. laptops, tablet, mobile phones) to the environment? This really comes down to authentication: how to validate that someone is who he/she claims he/she is. This can be achieved via a range of options from single sign-on to multi-factor.

While single sign-on eases the authentication and identification process by allowing the credentials handed over to Citrix Receiver seamlessly, it does create a gap in security where there is no additional prompt to validate the user; how can one be sure it was the same user that logged on in the first place? N-factor is complex to implement and less seamless for the user, but is generally more secure, as a user has to prove his/her identity in multiple ways, so long as multiple channels are leveraged. For example, if we send three One-Time Password (OTP) via SMS messages to the same number, no additional security is added over sending one OTP via SMS. Once we have successfully authenticated the end user, we should ensure the end user’s devices are compliant with the enterprise security policy. We can leverage end-point analysis (EPA) feature on the NetScaler to identify if an antivirus and certificate is present on the device before allowing the final authorization.

The good news is that security is evolving: we now are able secure the environment based on context, for example SmartControl and SmartAccess. SmartControl is a new feature in NetScaler 11 where it is used to provide restrictions at the network layer (e.g. block client USB drive redirection from client to desktop VDA). SmartAccess is implemented within XenDesktop 7.x using policy (e.g. restriction based on client IP address) and there is support for mobile clients in XenDesktop 7.13.

Now, what is the formula to secure an enterprise environment? The majority of business uses n-factor authentication (PIV card with TLS Certificate and pin prompt) however, there some cases n-factor may not be feasible, because the cost of managing and implementing n-factor companywide is costly.

To summarize, some key takeaways when designing a secure Access Layer:

  1. Identify what critical resources requires security control and assume internal and external access pose similar risks to the enterprise environment
  2. Deploy NetScaler fronting the public and private network to provide VPN functionality as part of a defense in depth strategy
  3. Determine if 24/7 access is required and apply the necessary security controls such as active monitoring, anomaly detection, and periodic log reviews
  4. Determine if an employee requires or is approved for remote access. If yes, apply the principle of least privilege to avoid any privilege escalation attacks
  5. Deploy multi-factor authentication using different channels for additional validations, for example, combining Type 1 (password), Type 2 (one time password) and Type 3 (geolocation or callback services) to authenticate end users
  6. Determine if single sign-on (SSO) implementation is worth the risk especially for accessing business critical environments
  7. Develop an access policy baseline and ensure the user and device meet the requirements before allowing access (e.g. End Point Analysis to identify if antivirus or client certificate is present)
  8. Leverage SmartControl and SmartAccess features of NetScaler to provide restrictions at the network layer.

Look out for part 3 of this series, where we’ll examine the resource layer and the security-related design decisions made in this process.

ponemon 3 banner