Blog

Password policies. Every site has a different one. How often they should be changed. Special characters. Do they display as you enter, etc. By 2021 we have all come to the realisation that the password is imperfect. But, its all we know. Does that mean we cannot improve?

The US National Institute of Standards has a special publication, NIST 800-63B that talks about Identity guidelines. I cover it in more detail here. It is a set of best practices for password policies, codified. And, I will wager, your system is not compliant. Let’s look at a couple of examples:

Password Complexity (Composition Rules)

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

https://pages.nist.gov/800-63-3/sp800-63b.html, 5.1.1.2 Memorized Secret Verifiers

Huh. Is that what your password policy says? Or does it say “at least one special character, at least one upper case, one lower case and 2 numbers”? Now, I’m not suggesting you should use “12345“, but, forcing too much complexity is not increasing the odds people will remember a more complex passphrase.

Password Change Frequency

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

https://pages.nist.gov/800-63-3/sp800-63b.html, 5.1.1.2 Memorized Secret Verifiers

Huh, is that what your password policy says? Or does it require you to change it every 19 days +- 3?

Show The Password

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

https://pages.nist.gov/800-63-3/sp800-63b.html, 5.1.1.2 Memorized Secret Verifiers

As someone who has poor vision, this is a password policy that bothers me. I know the password I’m creating. I’m not sure I’m typing it properly. Let me see please.

It also goes on to talk about salt+hashed passwords, something that is inexcusable if sites don’t do it. I’ll let you in on a secret: if your system can retrieve your password, it is not salt+hashed.

A Merger or Acqusition is an exciting, disruptive event. Formerly competitive companies might be merged, causing a long battle of who has the best system. Formerly orthogonal companies might suddenly be called to cooperate. The quicker we can merge, the quicker we can start aligning interests, the quicker we can be successful. Amongst the barriers is our IT systems. Identity, Access. What is the best approach to quickly align these teams? Mergers and Acquisitions: Zero Trust.

20 years ago now my company was acquired by Cisco Systems. Cisco parachuted in a large team who executed a well thought out plan. Work stopped on friday as company A, and work started monday as Company B. To make that happen, a lot of people re-imaged a lot of machines, and a lot of changes happened. At the team we were acquired we were hundreds of staff. If we had been thousands, I’m not sure this would have succeeded as a strategy. Instead, I think a much messier mesh of VPN’s and partially cross-linked identity systems would have been lingering for days, weeks, months, maybe even years.

Fast forward to 2020. We have new technology and practices. We can achieve our merger, acquisition with Zero Trust.

First, we need a Federated Identity system. Don’t create new accounts and logins. Instead, create a new Federated Identity system which allows for a user to be working for one of the companies, or the other of the companies. Make no differentiation in ease of use nor security nor access.

Second, we need a means of authorising access to the resource. Zero Trust Network Architecture allows us to treat resources in isolation. Make no differentiation in ease of use nor security nor access for any resource, regardless of which of the 3 entities “owns” it. A Merger or Acquisition with Zero Trust allows authorisation regardless resource or user location or ownership.

Don’t hire a firewall or a VPN to do the job, they are not fit for purpose. They have a time and a place. But not here.

Once achieved, we can a la carte build the team and tools that will make the merged entity successful. And, in the unlikely event the merger fails and needs to be divested, its trivial to disconnect. Fast to start and try, fast to fail if needed. This is what continuous is all about. M&A, Zero Trust.

A Joint Venture allows 2 unrelated companies to share resources, ownership in a new special purpose entity. For cost reasons you might want the new JV to have access to partial resources of one or more of the parent entities. Users might have permissions in both the JV and the parent organisation. How does one achieve this? A mesh of VPN’s? A new Identity system? These seem likely to lead to heart ache and security woes. Business needs to be fast and efficient. Starting a new JV we should not have to worry about who can login to what. What’s the best approach? A Joint Venture with Zero Trust.

First, we need a Federated Identity system. Don’t create new accounts and logins. Instead, create a new Federated Identity system which allows for a user to be working for one of the parents, or the other of the parents, or the JV directly. Make no differentiation in ease of use nor security nor access.

Second, we need a means of authorising access to the resource. Zero Trust Network Architecture allows us to treat resources in isolation. Make no differentiation in ease of use nor security nor access for any resource, regardless of which of the 3 entities “owns” it. A Joint Venture with Zero Trust allows authorisation regardless resource or user location or ownership.

Don’t hire a firewall or a VPN to do the job, they are not fit for purpose. They have a time and a place. But not here.

Once achieved, we can a la carte build the team and tools that will make the Joint Venture successful. And, in the unlikely event the Joint Venture fails and needs to be wound up, its trivial to disconnect. Fast to start and try, fast to fail if needed. This is what continuous is all about. Joint Venture, Zero Trust.

Ransomware is one of the most successful cyber crimes of recent years. A criminal gains access to your network, encrypts your data, asks for money to return it. If you don’t pay, they threaten to release it publicly. Most organisations pay. The payments are large enough, and frequent enough, to be a motivator for the criiminals, and small enough to not be a motivator for the international police co-operation needed. Let’s fix this with Zero-Trust.

The most successful ransomware follows a simple pattern. A distribution campaign tricks one user into running something (through spear phishing, social engineering, etc.). This malicious code fetches the ransomware, which then scans the local machine, and all connected machines. It encrypts everything it finds and then generates a ransom note.

The most common means of sharing files in todays corporate world is the Microsoft SMB (CIFS) protocol. You see this as a ‘share’. And these shares are a fertile breeding ground for ransomware. In a typical small corporate environment all your desktops directly access a small number of servers. And, importantly, the servers can all access each other. This system is only as strong as its weakest link. And here, the weakest link, is you. And the route from you to your corporate world is the SMB protocol. Click a spearphishing link? It takes out your machine, and everything your machine can access, and everything those machines can access. You are 2 or 3 hops away from your entire company.

What can we do about this. Well, educate users, install endpoint security, that sort of thing. Nothing wrong there, certainly best practices. But it hasn’t worked. Bad ransomware happens to good people. So ransomware happens, people pay, the cycle continues. What can we do better?

First, we adopt a principle of Defense In Depth. Instead of a single (presumed) infinitely strong security point (the Firewall, the VPN), we assume each layer of our defense will be breached. We switch to a set of fallback positions, delay the attacker, shift the cost from us to them. Think trench warfare rather than a single combat line.

Zero-Trust is the principal of switching from a perimeter-based trust model (you -> VPN -> building) to a user -> resource model (you to application-1). In doing so, you end up with a set of point-to-point links rather than a point to “whatever” link. In adopting Zero Trust, we are adopting Defense in Depth. We assume one user might become compromised. From there, rather than them having access to everything directly, they only have access to what they need. And, those systems in turn only have access to what they need. We have limited the blast radius.

But we can go one step further. We can stop using the SMB protocol to share in a hub-and-spoke model everything to everything. We can instead use WebDav. Same affect for the user: a remote directory is shared locally. But, more importantly, we can apply fine grained role-based access control. Since WebDav is HTTP, it doesn’t suffer from the same complex-protocol weakness that has enabled SMB to become such a transmission route. Users are now more loosely coupled, they don’t need to have a direct link to the Domain Controller, to the File Servers.

Coming back to what the criminals do here. They encrypt your data and ask for money. But, did they merely encrypt it? Or did they also exfiltrate it? When you refuse to pay you find they suggest they’ll leak your private data to the web. When ransomware happens the first thing you will ask is: what data, where did it go, what accessed it? In a traditional ‘walled-garden’ approach, we cannot ascertain this. Once inside the firewall & VPN you have unfettered access to everything, without access control, without audit. Zero Trust fixes this two ways. First, removing the walled garden means we are authenticating to each resource, so we can see who accessed. But, the Zero Trust agent can also product audit logs of what was accessed.

Zero-Trust implemented means a dramatic reduction in the risk of ransomware. Both the risk of getting it, and, the risk of it spreading. It allows you to ascertain who got what, when while simultaneously reducing the amount of who, the amount of what.

Simple for the users, Secure for the company. Defense in Depth via Zero-Trust is better.

Move the company network out to the users via VPN, break their video conferencing. Didn’t know what was a thing? Assumed that all the problems with latency, lag, quality, etc where due to poor home networks, older devices? It might surprise you that its could be how your route your traffic. The corporate VPN.

In the video below I go through the dreaded hairpin, that line in red in the below animation.

For years we have used syslog and netflow style logging, convinced that we could easily correlate events, find security issues, forensically see what happened. Then reality sank in. Multiple devices on the same IP due to NAT. Proxy servers. Spoofed IP. Big investments in SIEM and correlation became big work to get the most out of them. There has to be a better way!

Well, there is. We swap that perimeter-security and port-forward-DMZ-firewall world for Zero Trust Network Architecture. We place a cryptographically-secure header (JWT) on each transaction. We audit based on the contents of the JWT.

Now it doesn’t matter about IP address, 5-tuple-lookup, who had that DHCP address, spoofing. Each transaction has a GUID, called a SUB (Subject, e.g. the user). Correlation becomes exact match, no complexity, no confusion, no time horizons, no inside the NAT vs outside. Simple. Secure. Learn more in the below video!

The myth of the VPN, the Firewall as the only and best method of remote access has lived for 20 years. Let’s retire it together. I discuss the myth, and, an outbound-only, no firewall reconfiguration method, no client method of achieving your goals of happier productive users accessing their data and applications.

In this short video I discuss Zero Trust Networking as a means of, no-client, no-vpn, no-inbound-through-firewall means of achieving higher security, better performance, and simpler end user experience.

The VPN is breaking your video conferencing. its costing you money. Its frustrating your users. Let’s break down the myth that its the best or only solution to accessing data and applications. Its not.

Zero Trust Network Access. The principle of managing security between a user and a resource, rather than a user and a perimeter. By Identifying the user, providing Authorisation in the network, and then remote access to individual resources, we increase security and simplify at the same time. But, did you know you can do this with 0 inbound connections open? Nothing. No ports open to see on a pentest, on nmap, on Shodan. How? In this video I explain. In a nutshell, the resource makes a permanent outbound connection to the cloud. The user makes an outbound connection to the same cloud. Identity is confirmed, Authorisation is confirmed. The connections are stitched together. Simple and secure, no reconfiguration of firewalls. No client VPN software.

Have you seen or used a web application that suggests “Sign in with Google” or “Sign in with Apple”? Did your eyes skip over that and head to the familiar comfort of “create new account” while you tried to remember a unique password based probably on your cat and your birthday? After all, why would you sign into “random-app” with “gmail”? Well, let me explain. The tldr is “if you do this, you are more secure, and its simpler for you, you are giving nothing up”. The longer is, well,. check the short video.