Jesper Writes About Security

  One of the challenging aspects of defining a security strategy is to define how complex an attack you need to defend against. Over the years, I've seen far too many organizations that are trying to build complex reverse engineering capabilities to dissect potential malware, while leaving 85% or more of their environment unpatched, not implementing strong 2-factor authentication, or failing to perform basic hardening. Security is very often mostly about doing the basics well. If you cannot tell the board that you know who all the global root users are - including the ones that could become global root easily - implementing a complex data loss prevention solution is probably not the item that should be at the top of your list. One of the challenges in security is thinking through the threat environment we are facing. Typically, we can never measure anything with absolute certainty in security, and there is opinion in everything, but one thing that seems to work is bucketing things

Last time I wrote about how to decide which of the many many options for multi-factor authentication to use. While this involved a fairly complex spreadsheet of various options, they all pretty much came down to three things: If U2F/FIDO2 is an option, use that If not, use TOTP, or smartcards if you are in an enterprise If neither is possible any MFA provides more protection than no MFA To be honest, that’s pretty universal advice when it comes to MFA. If you want to just walk away with that, you can stop reading now. Everything else I have written in other articles, as well as this one,  is largely just justification and technical details leading to that summary.  States of Authentication Most of the time we think of authentication as a binary state; you are either authenticated or you are not. However, we can make our system more flexible if we are willing to accept a certain amount of complication.  First, consider the case where you have at some point authenticated. If you are fami

In past articles we have covered a lot of different second factor options. We have talked about how they work, and covered advantages and disadvantages of each option. If you recall from the first article, the series started because someone asked “where do I go to learn about multi-factor authentication?” Hopefully, by now we can agree that we have a base level of knowledge about the topic, enabling us to switch to the decision making process. If you are doing this for yourself, you will at some point have to decide which factors you want to use for which service. If you are considering implementing or changing your multi-factor authentication (MFA) strategy for a business, you need to decide which factors to implement for internal users. Or, perhaps you are responsible for a customer-facing service and need to decide what to support for your customers.  Reasoning about MFA The first thing we need is a decision making framework; a way to reason about MFA options and which make sense. T