Security basics, part 5 – How?

Overview

You’ve gotten this far so let me wrap this series up for you.

Why – Why someone tries to access the environment?

Who – Who should be able to access the environment? Can we authenticate the users or identify them in another way?

Where – Where are the users connecting from? From the office network? Some specific country/countries/region? Can we either whitelist or blacklist the locations?

When – Is the environment accessed around the clock? Can we recognize peak usage times?

How – What kind of device they’re using, what possibilities we have locating and authenticating the user?

Breakdown

Eventually, the goal is pretty much the same, you have a user that needs to access data as securely as possible with a suitable device for the purpose.

Managed model

I can’t really say that managed model is all bad, but it certainly has its challenges. Covering all access needs with this model might get really laborious and expensive. Rarely this model is very agile either.

Things to consider:

• All devices that connect to organization data need to be managed, not just your Windows PCs, but also the mobile devices (Android/iOS) and the evergrowing of Mac OS X and Linux endpoints.
• Delivering the devices to users might cause latencies for users to be able to complete the tasks set for them, especially in a case where their existing device breaks. If your install center is located in one place and you need to ship the device to the other side of the globe, it might take some time, or having several install centers is not cheap.
• Your organization often has also subcontractors and partners that need to be able to connect to your environment. In the past I had a pile of laptops on my desk or I needed to go to the customer office to access their environment. In this post-Covid world (well it’s still here…) this is rarely a requirement and these users are able to connect using their devices which means you no longer have only managed devices accessing your data.
• Virtualized endpoints (like Citrix VDI, AVD, Windows365…) are way easier to manage and also scale the amount to meet your requirements.

All that being said, there are still a lot of places where the managed model is the best fit. One approach to managed endpoints is to use thinclients. There are many vendors in this business that also provide great tools to manage thinclients. Having managed thinclients makes them really easy to deploy and a solid solution for your end users as they always have the correct configuration in them. When you combine a thinclient with a virtualized desktop / applications, they’re also pretty secure, since no data is stored on the endpoint.

Some thin OS’ also allow repurposing clients that are not Win11 compatible and extend their lifecycle further. This’ll certainly save money, but also the environment.

And if you ask me if VPN is dead, I’d say it’s not, it’s just evolving! Users need to access the data, and if they have a secure and working way of doing so using a traditional VPN or with a zero trust architecture (“VPN on steroids”), there’s nothing wrong with it. The solution just needs to be developed (or evolved) to face the challenges we have discussed in the earlier posts and the challenges that are coming in the future.

Any device (/ BYOD) & hybrid

Designing the environment to support any kind of device from ground up might sound a bit hazardous (and it certainly is, if not done correctly).

Having ways to identify all the connection parameters (not just “who” and “where”, but combining this with “what”) can help you to draft a more granular set of rules for the use cases bearing in mind that the users still need to be able to work and complete the tasks set for them.

One could start off by assessing the required access and limitations:

Who	Where	What	Intranet	Email	HR application	Server
Employee	Office	Company laptop
Employee	Home	Company laptop
Employee	Home	Personal mobile device
Employee	Office	Virtual desktop
Contractor1	Office	Company thinclient
Contractor1	Home	Contractor laptop
Contractor2	Office	Company thinclient

This is a really high-level approach and it gets more complex when you add stuff discussed earlier in this blog in the second part (Who?), like what level of user account is in question, how have they authenticated, and so forth.

In the above example, we only define whether the users have full access, read-only access or no access. This is still very basic and there are ways to control other capabilities based on the connection parameters like:

• Clipboard – two-way, one-way, just text? What about files?
• Printing – allowed to print? To any printer or just the secure print solution at the office?
• Download/upload – can you transfer files with the application using the application built-in capabilities?

On top of this, can we get protected from key loggers, prevent screen captures (ofc one can always take a picture of the screen…) and in an unsecure use-case add watermark on top of the application.

Forget about the “old castle and moat” approach (discussed in pt3) and also include your SaaS application in to the equation and make sure your solution also covers this use-case!

Followup

Comping might have an idea or two!

This was the last post of the series. We’re likely to get back next year on identity-related stuff concentrating on the Citrix and NetScaler capabilities (federated authentication, chained (federated) auth, PKI, different flavours of OTP and so forth…).