Jesper Writes About Security

  Prioritizing your work is absolutely critical. You can do all kinds of things, but if you don’t with some regularity do the right things you won’t be moving forward. A couple of weeks ago in a round-table discussion, someone mentioned prioritizing work based on the principle of maximum benefit for minimum effort. That reminded me that I needed to write up some thoughts and a job aid that I created a few years ago related to that very valuable principle.  The theory underlying it is really intuitive and straightforward: ensure you maximize the benefit you get from any unit of work. There’s just two problems with that: 1) how do you determine how much work something is, and 2) how do you determine how much benefit you get from the work? Work estimation is not exactly our strongest point in IT. There was a joke when I started out in software engineering back in,... well, it doesn’t matter when. To estimate how long a software project would take you ask the developer. Then you ...

  November 12, 2019: Apple finally released FIDO2 support in Safari.  June 9, 2020: A review of several websites reveals that a number of them still block FIDO2 in Safari.  On November 12 last year I thought that we finally would start seeing some adoption of FIDO2. However, this industry has a strange approach to protocol support. 7 months after Apple added FIDO2 support to Safari, AWS, Microsoft, and, yes, even GoDaddy, have code that blocks you from using FIDO2 security keys in Safari.  However, while so many vendors still block support of modern security protocols, they still support old and outdated ones. For instance, all of them support TLS 1.0 and 1.1. The major browser vendors coordinated an announcement in 2018 that TLS 1.0 would be deprecated in their products in March 2020. This was hailed as a major precedent setting announcement at the time. However, less than 1% of the traffic in each of those browsers, even then, was over TLS 1.1 and 1.0. Microsoft cl...

  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. I...

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 sens...