How I made my company’s office into a fancy internet cafe and why should you too

These are strange times. COVID-19 has changed the way we work, the way we communicate, and the way organizations operate. One of the concerns that is taking more and more focus now is around the move from working inside the perimeter to working outside the perimeter. We all know how to work in the perimeter, and we have learned in the past few months how to work outside the perimeter, but the back and forth between these two modes of operation can introduce risks on its own. Think about a computer in the perimeter, protected with perimeter security, that now goes out and is being used by someone working from home. During that time it’s less protected since the perimeter isn’t there. Then that computer is taken back into the perimeter and brings along with it threats it picked up outside - unwanted software, maybe an attacker with a persistent foothold on it. Now, it poses a risk to the entire organization from the inside.

In this article I describe a security strategy that helped my organization avoid this scenario by simply ignoring the perimeter, making us indifferent to the location our employees are working from.

About a year ago, I was adjusting my security strategy. As a CISO at a cybersecurity vendor, I have access to information about many attack groups and techniques as well as organizations who suffer from cyber attacks. My conclusion was that, despite some organizations having a much larger security budget and a larger security team, they all still eventually fell to the same techniques over and over again.

I had to find another trick that could keep my organization secure from these attacks. It needed to be a strategy that would allow me to reach a very high level of resilience to the techniques I commonly see, and simultaneously would align with the way the company operates. 

Our company is relatively young  and relies heavily on SaaS and cloud infrastructure. We don’t have many legacy systems, and our corporate architecture is similar to many companies, based on Microsoft Active Directory. In terms of operation, our company is distributed around the world. Some employees work from an office, some from home and some from the road. 

For my strategy to provide security in this heterogeneous operating environment, it had to address a component that is present in all of the APTs out there. The universal element here  is the login. In (almost) all attack scenarios, at some point, an attacker needs to gain access using a valid login. It can be an interactive login session or by hijacking an existing one, it can be using a token or key, or it can be compromising a password; no matter what, it’s always there. This was the key insight that led to much more.

Attack scenarios on the login process come in many forms: brute forcing, getting a password via social engineering and phishing, hijacking session tokens and using them, or even just getting control over a workstation and using the legitimate access of the user. 

The thing about the login process is that in a corporate environment, especially one that is based on Active Directory, it is very hard to follow the complex array of different login actions and to define strict rules for them. It’s really a mesh of services and accounts that all work very well together in the background to make Microsoft-based infrastructure work conveniently. 

Unfortunately, attackers are constantly taking advantage of these services in order to conduct attacks. A few simple examples are pass-the-hash/pass-the-ticket techniques, the use of domain controllers accessibility from all domain member workstations, the use of NetBIOS weaknesses, and many more. All of these are used to “move around” in a compromised environment, gathering credentials and moving from machine to machine. 

To avoid such attacks and make sure the login process is secure, I decided to take a different IT approach altogether. Being a young company with few legacy services, there’s not much reason for us to be tied to the traditional Active Directory. Many of the services that organizations use that tie them to it are used differently by us: email, file storage and sharing etc all have cloud-based alternatives.  Moreover, even if we wanted to, we couldn’t rely on these solely, simply because many of our users are working beyond an office network, and forcing them to be connected to a VPN all the time is simply not practical. 

The new approach puts the authentication process in the center. For that, we need to protect the parts that may be attacked independently: 

• The endpoint the login is done from
• The authentication act itself
• The account management on the systems side

If any of these parts is susceptible to an attack, the attacker can get in. For example, an attacker can gain access to an insecure endpoint and just “ride” on legitimate sessions without the need to attack the authentication point itself. Another example, if a system manages accounts poorly, an attacker may find accounts with weak passwords and use them, even without gaining any access to the endpoint that the real user uses. Time for the Internet cafe strategy (from now on: ICS) to go into action.

The way I built the strategy is based on the following concepts:

• Each endpoint stands for itself. It needs to protect itself, to be self reliant and to have the needed security controls all by itself. The assumption is that every endpoint is connected to an insecure network by default.
• Access to sensitive services goes through clear and designated gates. There are no “open ports” from any segment in the network directly to any sensitive service or component.
• Do not rely on centralized network controls. They still need to be there, to provide governance and avoid the common diseases that can cause a headache for a CISO or an IT manager; but when it comes to APTs, the assumption is that there is very little trust on these controls.
• Services should be un-meshed. Every service has to be well defined, understood, filterable, etc. That puts out of the equation the classic Active Directory model with it’s mesh of connectivity and interdependence.
• Management from everywhere must be possible. Security and management services should be applicable no matter where the endpoint is. 

Critically, the strategy was executed as a set of projects and not in one monolithic, risky move:

• One identity provider that takes all of our logins (at least all of the important ones) had to be in the center. This of course has to support strong authentication, conditional access and more and was a big undertaking alone.
• An access broker for sensitive services to act as the gate to all sensitive services and components. This will enforce strong authentication, has the audit trail all in one place, and ensures the security of protocols. It also prevents any direct open ports from anywhere in the network to the sensitive services.
• Migration from classic AD to the cloud-based Azure AD to reduce the services mesh in the corporate network, and the default settings that are not as hardened as it should be. In this case, like in the Gordian Knot story, it’s easier to simply change the concept altogether than to spend so much time and effort tweaking the classic GPO and it’s subtleties to reach the desired level of security.  
• MDM for the management of endpoints to make things tight and simplified. Active Directory’s Group Policy doesn’t cut it. Instead, MDM services do a much better job providing visibility and pushing configuration of the things that matter on the fleet of devices.
• Micro-segmentation for every workstation to protect itself. We closed down network ports to peer-to-peer communication. This stops many of the common lateral movement techniques, and luckily it is not really needed for the work we want. We did leave only what’s needed open, and now we also know exactly what that is.
• Endpoint resilience suite - Every endpoint is equipped with several security controls, from personal firewall to EDR and include AV, NGAV, DLP and more. 
• Monitoring emphasis, which is now a lot easier since we have eliminated a lot of noise and complexity. We can basically monitor much more extensively, and this is a better use of my staff anyway.

It sounds quick and easy, but it wasn’t. There are several challenges when implementing this strategy. I’ll describe the main ones:

• The Internal sell - a transition of strategy doesn’t always go easy in organizations. It requires a mind switch, different budget allocations, different security limitations, different work processes. All of this needs to be clear not only to the CISO, who lives and breathes security, but also to the business-side peers. It needs to be clear to the CEO who owns the risks at the top of the pyramid, and to the CFO who budgets it. It needs to be clear to the R&D management and the technical operations teams that may need to do some adjustments in the ways they work. In order to make that internal sale, the reasoning needs to be translated from security language to several other languages. The discussions need to happen before getting to execute any part of it. And the buy-in needs to be as wide as possible. 
• Defining the needed security value - when you change your security strategy by replacing tools with other tools, it’s sometimes not like replacing apples with apples. You have to go back to the drawing board, refine the actual security value you need to get, and then find the tools and controls that can provide that value.
• Integrations - going with central systems, some serve as gates and require integration of these systems with other infrastructure components - services, servers, in-house developments, cloud. In order to make that happen, you need to choose the right tools. The tools you want are the ones with a broad support for integrating with known IT security systems, as well as common protocols. A good example is the Identity Provider - you want one that can easily integrate with your cloud services, traditional on-prem services and homegrown tools.  
• Operational change - using different technologies than you aren’t used to also requires adjusting within the security team. It may require your people to learn new technologies, adopt new operational processes. It changes your IR strategy, and your daily routines. Plan this ahead, so you can create continuous processes in your security operations throughout and after the change.

The end state this brought us to is better than the original:

• Access to services relies on the right person logging in from the right endpoint.
• Every endpoint is a bastion host in itself. An attacker gaining access to one endpoint has no advantage when trying to move to the next endpoint or almost anything else. 
• The office network has no real significance in itself, as it doesn’t provide any access; all access again comes down to the coupled user-endpoint. 
• There’s no difference in the level of control and visibility between someone sitting in the office vs someone on the road or at home. I can push patches and get information from both exactly the same.
• Making access changes is very easy, since it doesn’t require any infrastructure change; it can all be done by managing logical groups in our identity provider. 

Bottom line, we moved from office-centric security management with a lot of baggage we didn’t need to an individual-centric security management, hardened, resilient and simpler environment. 

And the office remains as a very fancy internet cafe with nicer screens, artwork and rooms. For more info on securing your remote workforce, check out our secure business continuity toolkit.