There’s a theme going around that you should create secure products, not buy security products. And, as far as it goes, this is… Well, actually it’s not good. My initial response was “Why not both?” We need to secure the products we develop. There’s no doubt about that. And we need to mitigate mistakes. How do we do this? Spoiler… security products :-) In response to this I got a message “If you have secure products, you do not need security products.
I’d previously written about the Yubikey 5 and how we could use it to solve various use cases and when to trust it. Personally, I think it’s a great device for corporate authentication solutions. But… This week, Yubico released an advisory that stated that ECDSA private keys could be stolen from a Yubikey 5 that’s running firmware older than 5.7.0 (or 2.4.0 for the YubiHSM). This is due to a flaw in the cryptographic libraries written by Infineon and discovered by NinjaLab.
I don’t normally write about specific products, but I was asked to take a look at the YubiKey series (primarily 4 and 5) and write up a summary of when and how it can be used. This is timely, because CISA is pushing for access management enhancements and recently published a chart for phishing resistance. I thought this interesting; typically I’ve looked at this from a user perspective (“can I use this to secure access to my bank account?
In a well controlled environment you typically do not want people logging into servers with privileged access (absent of additional external processes, such as a keystroke logged session manager). If you have 5 SAs all logging in as root then how can you audit activity and determine if it was Tom, Dick or Harry that rebooted the server? Similarly you don’t want DBAs directly logging in as oracle; how do you know who dropped the production table?
One of the exciting parts of the “new world” of cloud is the ability to green field solutions. We don’t have the legacy requirements and so we’re free to do what we want. Or so the evangelists would have you believe. The past lingers on The reality is that many people are closer to a brown field environment. The organisation their team is embedded into has a tonne of reporting (“is your machine patched?
We’re all used to using passwords as an authenticator. However, passwords have a number of problems. In particular people tend to re-use them on other sites (so if one website was broken into the password used there may also work on another site). Also passwords are susceptible to replay attacks (even if you force a password change every 90 days, there’s still a large window of time where a stolen password can be used).
Identity and Access Management (IAM) historically consists of the three A’s Authentication What acccount is being accessed? Authorization Is this account allowed access to this machine? Access Control What resources are you allowed to use? Companies spend a lot of time and effort on the Authentication side of the problem. Single signon solutions for web apps, Active Directory for servers (even Unix machines), OAuth for federated access to external resources, 2 Factor for privileged access… there’s a lot of solutions around and many companies know what they should be doing, here.
One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it.
If your organisation is anything typical then you have multiple web sites and application that require authentication. If you’re lucky then you might have something like CA Siteminder, but your staff still complain about needing to re-authenticate every so often. The more times they need to login, the greater the chance of a mistake, causing a lockout and driving people to distraction. So you hatch a plan; let’s do a true Single Sign On.
Identity and Access Management (IAM) historically consists of the three A’s Authentication What acccount is being accessed? Authorization Is this account allowed access to this machine? Access Control What resources are you allowed to use? On top of this we may also need to consider Auditing Log the attempt to use the machine Provisioning How does the account get onto the machine?
