Maksim Kabakou - Fotolia

Security Think Tank: Practical steps to achieve zero trust

In theory, the elimination of trust on the network simplifies IT security, but zero trust also brings new complications and new challenges. How should CISOs go about moving their organisations from traditional network security to a zero-trust architecture?

Trust is an interesting concept. Consider “do you trust this person?” or “would I do business with this organisation?”. Trust is something that can be developed over time, but where do you start, because without trust, you wouldn’t do anything.

In the end, it comes down to an understanding of risk and exposure of a situation and the controls that could be put in place to mitigate risk and exposure, or at least reduce the risk and exposure to an acceptable level.

Zero trust in the context of a business or organisation is currently a hot topic, but what does it mean? In essence, the default situation is that nothing is trusted outside or inside of an organisation’s network and therefore controls must to be put in place to reduce risk to an acceptable level. In other words, defence in depth.  

Two main trust factors are at play – people and technology – and there is an interplay between them. The starting point for these trust factors is a well-thought-out and up-to-date set of policies, standards, procedures and work practices, supplemented by detailed, up-to-date network documentation and asset inventories (information, software licences, hardware, and so on).

Technological considerations in zero trust

Looking at the technology side, let’s start with traffic incoming to a network from an external source, such as the internet or a partner network. Typically, this is initially controlled at the perimeter by a combination of firewalls architected with demilitarised zones (DMZs) supporting proxies, reverse proxies and terminating equipment that offers email, virtual private network (VPN) and client access termination from external networks and web browsing of the internet from the internal network.

These proxy and terminating devices would typically run anti-virus, malware and spam prevention technologies and, where needed, provide access authentication and authorisation (AAA) services (proxied from an internal AAA system). Application-level firewalling (for example HTML, SQL) might also feature in the services offered on the DMZ. Next-generation security devices from a number of suppliers integrate some or all of these features and so can, in turn, offer network managers a unified view of their operation.

The design of the internal network can then add further controls, such as network segregation and additional anti-virus and malware detection technologies, together with AAA controls over system and file access. Often, the human element forms the final control, be it someone receiving an email or browsing the internet. The effectiveness of this final control depends on education and a supportive, no-blame organisational culture. Again, this is defence in depth.

In network segregation, recommended practice is that key servers and services (such as NAS & SAN), company employees and guests are given their own Wi-Fi networks and, in larger organisations, thought can be given to putting some departments on their own networks. All these networks would then be connected together via firewall technology, which could be discreet firewalls, or utilise the firewall capabilities found in enterprise-level Ethernet switches, or be connected to an enterprise-level, multi-ported firewall, or a mix of all three approaches.

The function of these internal firewalls is to provide isolation from the other networks, allowing connectivity based on IP address and port filtering. Additional functions, such as application-level firewalling or proxy capabilities, could also be included. The effectiveness of network segregation can be partially undermined if AAA policies and procedures are poor, are not rigorously enforced or are poorly implemented in technical controls.

How to reduce risk and improve trust

  • Passwords should be strong, a minimum of eight mixed alphanumeric and printable characters, 12 or more characters by preference and not recognisable words.
  • User IDs and passwords should be kept safe, and there should be an enforced clear desk policy when people are not at their desks.
  • Normal users should not have administrator privileges, even on their own company PC.
  • Only authorised technicians should have user IDs with admin privileges and even then, they should be given two IDs, one normal for day-to-day functions (emails, report writing, and so on) and one limited to admin duties. Thought should be given to using a “jump-off” server for administrative tasks.
  • Two-factor authentication technologies should be explored and, where deemed necessary, implemented.
  • Access and authorisation to the company network, systems and files should be strictly based on the principle of least privilege that enables a person to do their job. No user should be in a position to access all the company files and systems, only those pertinent to their job and general company information. File access functions should also be limited. For example, if read-only access is required to a file, then only read access should be given. A person’s seniority should not override these principles.
  • Variable user profiles. It is recommended that user access profiles are automatically altered based on where they access a company’s network, for example a full access profile if accessing from a company PC connected directly to a company network, but limited access when accessing from a non-company PC, for example a person’s home PC or an internet café or hotel PC. Access from public places and public Wi-Fi networks should also be restricted, but less so if it is from a company device over an encrypted VPN link. Note, https browser access could be accorded the same privilege as encrypted VPN access where there is mutual authentication using company-specific X.509 certificates. Two-factor authentication should again be considered.
  • While there must be a no-blame culture within the company, users should still be accountable for their actions, such as keeping their ID and passwords safe.
  • Culture should be supportive and blame-free. If a user is unsure what to do (maybe they receive email from a known source but with an unexpected attachment or link), they must know that they can ask for assistance and not be made to feel guilty for asking. This should be supported with clear, advertised lines of communications to enable users to report problems or request help.
  • Users should be taught how they can help to improve an organisation’s security and this should be supported regularly with reminders and campaigns. There needs to be a log of given education to ensure everyone (including the board) is taking part in the programme.
  • Informal workshops to help people understand security with an emphasis on the home and its internet-connected technology is a great way to get buy-in from people to be more security-conscious, which will, in turn, improve the corporate security culture – a win-win.

Read more on IT risk management

Data Center
Data Management