By David Rihak, Peig.io
With growing interest in zero-trust architectures, reducing an attack surface has become synonymous with good security practices. In practice, reducing an attack surface is synonymous with reducing the complexity of infrastructures and systems and minimizing access rights individual accounts and users have at any given time. Although reducing a static attack surface is critical, another just as important practice is often neglected: reducing attack time.
Let’s take a typical application of cookies as an example: Single sign-on. Single sign-on is a widely accepted security (mal)practice, not so much for its security advantages but more so for user convenience. With single sign-on, users are authenticated once, and a website issues a cookie to store in the user’s browser. The cookie then provides access to multiple other services so the user doesn’t have to sign on repeatedly; hence, it is a single sign-on.
You guessed it! The single sign-on cookie expands the attack surface! If an attacker gets hold of the cookie, they’ve just gotten themselves access to a larger surface area: more systems, more data, and more ability to do damage.
As before, reducing an attack surface is a good idea and can be achieved by eliminating cookie-based single sign-on capabilities. You could have users fully re-authenticate when accessing every application. Annoying? Very much so if done wrong. More secure? Definitely yes. Luckily, there are also ways to do it right.
But what about time?
Let’s say we have reduced the surface area by only providing cookies that give users (and their devices) access to one application at a time. For most applications, a user can now use the same cookie for several weeks, if not months. That, too, is standard practice. Think about how often you have to re-authenticate. It’s probably once a week for some applications and barely ever for others, right?
What happens if an attacker gets hold of this one application-dedicated cookie? You guessed it again! They can do a lot of damage if they have enough to do it.
They can take their time to analyze the system in and out, export any data that is available without anyone noticing, or use the breached account for impersonation to trick other people in your organization to gain access to even more sensitive accounts: all of this is standard practice for hackers. That’s how they work.
Security practitioners and business leaders should, therefore, not only think about the static attack surface but also consider how much time is provided to users when accessing a resource. The usage time you give to users is the attack time you give to hackers in case of a successful breach.