When we hear the name “Titanic,” there are many words and associations that immediately come to mind.
Tragedy.
Disaster.
Lifeboats.
Catastrophe.
Leonardo DiCaprio.
Arguably, though, the word most commonly associated with the storied ship is “unsinkable.” The advertisement and marketing campaign prior to the ship’s launch was focused exclusively on this claim. Just look at the original marketing brochure for Titanic and its sister ship Olympic: “…as far as it is possible to do so, these two wonderful vessels are designed to be unsinkable.”
Selling this idea to the masses really worked — Titanic and Olympic were the toast of the town and tickets sold out in a flash. And this myth wasn’t just bought by consumers; no. Experts, too, started to believe this “unsinkable” idea and became overly confident.
God himself could not sink this ship — anonymous crew member
I cannot imagine any condition which would cause a ship to founder. Modern shipbuilding has gone beyond that. — Edward J. Smith, Captain of Titanic
When you believe that your preventive measures are impenetrable, when you stop thinking about contingency planning, you get complacent. Half of Titanic’s lifeboats were removed, as they were not aesthetically pleasing. Bulkheads were not watertight. Using a double hull was considered too expensive and unnecessary. Titanic was designed for a very specific scenario: a head-on collision; other scenarios were not considered. We can find many technical reasons, but in the end, it was overconfidence and the human factor that was responsible for this historic tragedy.
In recent news…
When I think about the current state of cybersecurity, I often imagine huge, slow-moving cruise ships (enterprises) navigating waters thick with pirates (hackers). Just like icebergs, most cybersecurity threats are not visible on the surface. The captains steering these technological behemoths often believe the “unsinkable” claims about their IT security only to have the rug pulled out from under them when those claims prove false. They, like Captain Smith, have to go down with their ships. We are getting used to the weekly news about the next cybersecurity “Titanic” — and many captains are trying to right their ships without bringing them to a screeching halt. But this is good news; the approach to cybersecurity is changing, with more and more companies focusing on “what-if” scenarios because they understand that security breaches aren’t just a possibility, they are likely.
Great Eastern
Is there, perhaps, something that we can learn from naval engineering? More than 50 years before the launch of Titanic, another interesting ship was built: “Great Eastern.” Originally christened “Leviathan” (an indicator of her size), the Great Eastern was five times larger than any ship before it and she would not be matched for over 40 years. So, yes, she was big. Her first transatlantic voyage had to be postponed, as the crew were drunk. They lost control of the ship on a third journey, as the cargo was not properly stowed and was rolling loose in the holds. After 75 hours of drifting without control, passengers — passengers, not crew — fixed the rudder and the ship returned to Ireland.
If anything, the crew made the situation worse instead of better. During one of Great Eastern’s earliest journeys, there was a huge explosion, but the ship, incredibly, survived. In 1862, she ran into a rock formation, which opened a gash in the ship’s hull more than 25 meters (83 feet) long and almost 3 meters (9 feet) wide — that’s over 60 times (!) the area of Titanic’s damage — yet the ship survived. She was scrapped after 30 years of service and is considered one of the great engineering achievements of the Victorian era.
What was the secret of Great Eastern? The answer: Great, innovative design that focused on answering those pesky “what-if” questions. The ship had a double-hull — one hull inside the other. It had sixteen watertight compartments and a watertight bulkhead. Designers hadn’t tried to identify every potential catastrophic scenario; instead, they focused their design on post-disaster survivability of the ship.
Solution: Secure Zones
This is an important lesson to learn. Just as large ships are designed with compartments to make sure that one leak doesn’t sink the whole ship, companies around the world need to think about their “ships” the same way. Attack surface has been greatly increased in recent years: more mobile workforce, BYOD, smartphones, IoT, and so on. There are many factors behind this trend. Segmentation is one of the most important and strategic decisions to ensure the continuation of business.
When people ask me about Citrix and security, this is one of the most powerful stories that we have. Being a security company doesn’t mean that you must have your own antivirus solution or other active protection technology; you can greatly impact overall security by focusing on visibility and control aspects. It’s not a new story; I’ve been successfully designing and deploying secure zones using XenApp for many years.
The general idea is quite simple: you lift your applications from your endpoints and run them on a farm of XenApp servers that are sitting between your endpoints and backend systems. A Citrix XenApp/XenDesktop site is used as a bumper zone between two environments with different trust levels – endpoints are usually considered untrusted, while backends are considered trusted. There are a few scenarios where this is reversed, such as with a secure browser, where endpoints are trusted and the other side (internet) is untrusted.
The beauty of this solution lies in its universal nature — you can apply the same architecture and security measures for different generations of applications.
Many companies often ignore the security of older applications, arguing that they will be replaced anyway or that securing them would be too expensive. But that’s not the case here. Another benefit of this approach is that they can be used to contain potentially unsecure applications during transition to more durable and secure alternative. For example, if you have an application that requires potentially unsecure runtimes (eg. Flash/Silverlight), you can isolate them in dedicated sandboxes instead of reducing the security of the endpoints where these plugins would otherwise be installed.
NetScaler is another important component of this architecture. For each of the secure zones, you want to make sure that minimal surface is exposed; ideally, only a single network port and all the traffic is encrypted. Whenever attackers are moving between zones, gateways can act as checkpoints, making it much easier to spot an unexpected connection or behavior. Contextual security plays a major role here, ideally using it as an invisible authentication factor (or detection mechanism). One of my favorite examples is using machine certificates to confirm the identity of the endpoint, combining this with more traditional multi-factor authentication to confirm the identity of a user.
When your secure zones are properly designed, you will have a catalog of XenApp servers that have predictable behavior and limited set of applications. Using application whitelisting on these single-purpose built machines is much easier and more robust than using them with general desktops, as there are only limited variations of the running processes and executables. Solutions, such as WEM Application Security, can really make sure that attackers cannot download any of their favorite tools. No Kali Linux distributions, Metasploit, Ruby or Python… you are, again, designing a chokepoint system that can be closely monitored and any unexpected behavior can be immediately reported.
As always, the goal is to design a multi-layered security solution. One of the great invisible security layers that you can include in your secure zones is XenServer Hypervisor Introspection (HVI). What I really like about HVI is that it provides protection from zero-day attacks – it’s critical to include protection against unknown threats and always expect attackers to have upper hand. You can see HVI in action in this video or read our detailed white paper about on-premises secure browser deployment.
So far, we’ve covered how to segment your applications (XenApp/XenDesktop), reduce the attack surface (NetScaler), limit the ability of attackers to compromise system (WEM) and finally provide protection against zero-day attacks (HVI). These solutions are focused on network segmentation.
There is, however, one more type of segmentation that is now possible – identity and privileges segmentation using Federated Authentication Service (FAS). FAS allows you to seamlessly transition between different accounts as described in this video, with most common cases being B2B (vendors/mergers & acquisitions) or B2C (individuals/contractors).
However, FAS can be used to provide identity segmentation, as well. You can have a standalone AD environment within the secure zone and use FAS to provide seamless transition to these isolates accounts. These isolated accounts are using virtual smart cards for logon, which allows you to completely disable passwords, removing support for explicit authentication and configure all servers to provide access for virtual smart cards only, reducing the ability of lateral movement. Even if an attacker uses brute force to capture the password of one of these accounts, he won’t be able to logon.
As I’ve mentioned, Citrix is focused on visibility and control aspects of security. Ability to centrally store, process, and analyze various logs is important aspect of this approach. With secure zones, Citrix not only provides detailed logs about access, but also records and replays whole sessions using Session Recording. If you’ve been watching our recent releases, we’re adding a lot of cool features and keep improving them.
Finally, if there is one area where I see huge potential for Citrix, it is in the ability to provide end-to-end connection with underlying advanced Citrix Analytics engine that can identify anything that is unusual or suspicious. Being able to to analyze the HDX stream and recognize users by the way they move the mouse or type on the keyboard is potentially game-changing technology. Instead of recognizing a user by something he knows or owns, we could identify him by something he is — using his unconscious behavior as a continuous authentication factor.
So, what’s the reason that most corporations ended up with Titanics instead of Great Easterns?
Segmentation can dramatically increase complexity and decrease visibility of IT environments if not handled properly. Visibility and control is the focus of Citrix — and we have another new component that can help with management of these complex environments. Shortly after Citrix announced the acquisition of Unidesk, I began a deep-dive look at their technology. What captured my imagination right away was a combination of the concept of layered images — and ability to integrate them with single-image provisioning systems like Provisioning Services (PVS) or Machine Creation Services (MCS). Citrix App Layering is a great solution to reduce the image sprawl and centralize the management of these separate secure zones. With the agile development of software, IT professionals need to adopt agile management of IT systems; delaying updates and upgrades by months is no longer going to work.
Summary
Building secure zones or enclaves has been one of the proven approaches to contain security breaches. This architecture has been used to provide secure access to SWIFT or PCI DSS networks, however, companies should start adopting this principle for their general IT networks as well, especially with the new generation of privacy laws, such as GDPR. You don’t want the ship to sink just because of one small leak, do you?
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more TechBytes and subscribe.
Want specific TechBytes? Let us know! tech-content-feedback@citrix.com
