Zero trust

• Zero Trust, Threat reductions
• by Sebastian Wallace

Audio for this article

Zero trust sounds like something you would implement in a prison, it's not trust me. In this article we will look at what zero trust is, why it's important in the tech industry and the impact it can have if you don't  implement it. 

What is Zero trust and how can a business use it to strengthen cyber resilience?

So here is the good news, it's not a specific framework, noire a standard, or a policy, in fact it's not even a singular concept. Instead try and think about it as a new way of 'thinking', a mindset change which means you change how you think cyber resilence and defence, whether you are in software development or systems administrations. 

If you are a car driver, and also ride motor bikes you will understand this train of thought. You drive a car on a road, as you do a bike, but a car has four wheels, a steering wheel and a large metallic cage around it. The controls are different as well, vastly. Your feet control acceleration and braking, your hands change the gears and control the car. A motorbike you brake with one hand and one foot, you steer by turning a bar and leaning your body to one side or another, you brake the back wheel with one foot and change the gears with both your hands and feet! So it's a safe assumption the thought process behind driving a car and riding a bike are very different, but they are all on the same road, traveling to the same destination.

This rather removed example demonstrates how changing your thought process but working towards the same end goal is key in implementing zero trust. 

I could do what most other posts seem hell bent on doing and applying '10 simple rules' which turn out to be not so simple. Instead I will impose one. A single simple rule which if you remember you can't go wrong. 

Don't Trust anyone

It may sound crazy, but even authenticated users who have logged into there system through MFA are not to be trusted. The threatpost said it best when they wrote: 

This goes beyond basic authentication and access management in that the approach assumes that users are a threat, regardless of their identity, location or how they connect to a network

Alot of articles out there explore zero trust from a sys admin point of view, or from the point of view of a security manager, or infrastructures engineer.  I want to look at it from a software development point of view, what is it and why is it so important to engineer with zero trust in mind. 

 

Design systems to trust no one

Lets say we have a login system, which authenticates someone, and that, that system then allows someone to create an order. Zero trust would dictate that in order to create, edit, delete or even view that order that the users permissions should be checked at every process. 

Example

To view an order with zero trust

 

    function viewOrder(int $id): array 
    {
        if ($this->isloggedin()) {
            return $order;
        }
    }

Whats wrong with this I hear you ask? The assumption that just because someone is logged into a secure area that they have permission, here is how its suppose to be done

    function viewOrder(int $id): array 
    {
        if ($this->isloggedin() && $this->hasPermission('view-order')) {
            return $order;
        }
    }

The additional check of the users permissions is key here, we don't trust users. This is just an example of how you could implement zero trust. Another example is to not trust what a user sends you. 

    function createOrder($order) {
// SQL injection prevented.
      $database->query('INSERT INTO company.order (name, age, order,) VALUES (?,?,?)', [$order['name'], $order['age'], $order['order;[]);
    }

So what happens if a user sends some javascript in the request? it might get reflected or even stored (a typical XXS attack) so instead we do this.

    function createOrder($order) {
      foreach($order as $key->$value) {
         $order[$key] = strip_tags($value);
      }
// SQL injection prevented.
      $database->query('INSERT INTO company.order (name, age, order,) VALUES (?,?,?)', [$order['name'], $order['age'], $order['order;[]);
    }

Try not to focus on the code more the concept. In the first example I was focusing on sql injection (which is correct) but I trusted that Jim from the office would never try and inject some javascript into his request? Why? Assume Jim might and as a result we need to strip tags from everything that is requested. 

Here are some simple tips to follow

• Always assume the user is a threat.
• Sanatise everything from a user.
• Never assume broken logic won't be abused.
• always assume a user could manipulate request.
• Always force the user to comply with security polices for example password lifetime, connection over SSL etc. 
• only allow what is needed. Don't give access to additional functionality just because its harder to restrict it based on permissions. 
• ALWAYS and I can not stress this enough ALWAYS audit users activities. Have audit trails established. 
• Limit the amount of information which can be requested over a certain time frame, this will reduce the risk of scraping.

Impact of not using zero trust

The biggest impact is what could happen if a 'trusted' users credentials become compromised, what could an un-trusted actor do in a trusted environment, how much damage could they cause? Could they steal confidential information or destroy mission critical data? Lets look at a practical example of when a un-trusted actor gains access to a trusted account.

Bob went on holiday, he left his username and password on his desk on a post-it note in case anyone needed to access his account while he was away, Bob was the logistics manager. A cleaner noticed this and took note of it, that evening he went home, knowing the works ip address he logged into bobs account and started snooping, soon discovering he had access to much more that logistics, he had access to finance, even though the links were disabled he was able to guess them and because he was a 'authenticated' user he could do what he wanted. When bob returned from his holiday he was surprised to learn the companies suppliers were becoming increasingly nervous and unwilling to work with the company. It turned out the company was going through hard times, but had done so in the past and had survived just fine, as long as they kept the orders going. However what they didn't know was that the cleaners wife worked for one of those suppliers, and gave them a copy of the compromised financial records, which make the suppliers rather nervous to work with the company. It also meant that other suppliers who were all in contact with each other felt the same way. As a result the company was unable to continue fulfilling orders due to lack of supplies and eventually went out of business.  

So what could be done to prevent the above. I'm going to focus on zero trust things, and not that bob was an idiot and allowed his account to become compromised. That's another subject altogether! 

• The company should not have allowed an external login to there internal systems. Instead having a white list of safe IP addresses and allowing staff to connect via a VPN to when working outside that white listed environment would have prevented the initial access. 
• The code should have checked the users permissions before allowing access to the finance information. In this instance Bob should not have had access to something he didn't need. Instead they simply 'hid' the menu item.
• During bobs absence someone else covering his role should have been granted additional permissions to do his job, with the view to remove them upon his return. While bob is away temporally disabling his account would have also been preferable.
• Finally the entire process should have had an audit trail behind it, every event or action should have been logged. If the company had, had logging, after the company started loosing suppliers they could have investigated and realized what had happened. 

Lets take another look at the example but this time from a different type of threat. The insider threat. 

Jake works at the same company as bob, however Jake works in the sales team. He has limited access to resources but knows that once he is logged in, he can directly access other areas of the system. He also has access to a network drive which contains various files he should not have access too. When bob's account is compromised and the cleaner leaks the financial information, the company, at a position of being forced to let staff go, fires Jake sighting that his role is no longer cost effective. Jake finds out about this before the company fires him. That evening from home he log's into work and after finding a program on the internet starts scraping all the sales information he can, namely a customer information (an area he shouldn't have access to). Jake also copies all the suppliers and various procedural files from the network drive. Jake finds a new job with a competitor and using the new information he stole, is able to gain a substantial lead in the market, which further adds to the issues the company face.  

I know, I know this is all rather doom and gloom. Here are some lessons learnt from Jakes antics;

• Again he should never have been able to log on from home, however he could have done this from work, but doing it from a works computer may have triggered some alert if he attempted to download some external program for web scraping 
• He should have had permissions checked, this would have prevented him accessing sensitive information (customers information) 
• A limitation on the amount of resources he could access within a time frame would have prevented the scraping of customer information 
• and finally an audit log trail would have highlighted what Jake was doing to management allowing them to  prevent him or at least seek damages for the information he stole. 

So those are two examples of how implementing zero trust can strengthen cyber resilience. Hope you liked this article and are a little clearer as to what zero trust is. 

I will be talking in more detail about what an insider threat is, its risks and preventing them in a future article.