Security Assumptions – Don’t Make an ASS of U and ME

EH-Net - Kron - Security AssumptionsHave you ever stopped to ask yourself if the things you are defending against are really your biggest security problems? I am going to challenge you to think about things a little differently, as I have been myself recently. Prepare yourself, as this may challenge some of your core security beliefs, things we have been taking as gospel since the early days of securing networks. We all know our time is precious and limited, so it is more important than ever to use what time we have wisely. That is exactly why I think we need to look deep into our beliefs and be willing to challenge ourselves on a profound, uncomfortable level. So, let’s make an attempt to be completely and utterly honest with ourselves about our security assumptions.

Do you require users to have long, complex passwords and expect them not to write them down? Do you use firewalls to cover up unpatched software, block access to vulnerable or unused services or to make up for poor configuration? What about Full Disk Encryption? Do you deploy that on every machine in your organization?

If you answered yes to any of these questions, you might be doing it wrong. Perhaps it’s time to review what you are doing, and why. Sometimes we do things because we have heard others do it, but we waste a lot of time and energy, plus create needless friction by just following the herd.

Passwords

Password hygiene has long been a thorn in the side of IT and security professionals. Getting   users to treat these “keys to the kingdom” with the proper care has always been a challenge, one where we continue to fail. That being said, let’s ask ourselves if the changes we have been trying to get users to embrace are actually worth the fight. Let’s take this apart a bit.

Password length and complexity have long been something we have fought with. The idea is that the longer the password and the more special characters we use, the more secure we are. We have to ask ourselves why we believe this. The answer is, we have been told they are harder to brute force when they are long, and we are told that the more characters there are, the harder it is to break the encryption. While this may be true, let’s ask ourselves a question. When the last time we saw a real-world brute force attack take place that was not successful, simply because the users were using a well-known password (e.g., anything here), utilized credential stuffing with reused passwords, or had an easily guessed password, as opposed to a hacker throwing thousands or even millions of passwords at an authentication portal to get in?

In the real world, even if an attacker is already inside your network and is trying to pivot or elevate privileges, are they more likely to try to brute force passwords, try to crack the password encryption, or use a pass-the-hash attack? The answer is that the vast majority of attacks will come via a pass-the-hash attack. And guess what? With hashes it doesn’t matter if your password is five or 45 characters long.  Again, the attacks that are most likely to be successful against an actual password are most likely to succeed due to easily guessed, reused or common passwords, not by brute force password entry attacks.

So, rather than focusing on trying to get users to have these long, complex passwords, it makes more sense to concentrate on the bigger issue of password reuse, the use of well-known passwords or those with an easily guessed pattern (e.g., loveamazon1234, lovetwitter1234, lovefacebook1234) and the liberal application of multi-factor authentication (MFA). While MFA has its vulnerabilities, a five-character password with a second factor is still more secure than a 24-character password reused across multiple accounts.

In addition, using a password vault that allows the easy and automatic generation of random passwords, regardless of the length, is a goal worthy of your effort. Secure the vault with a second factor and you have a potent way to avoid the real issues with passwords – reused and commonly used passwords.

Perhaps in the near future with technologies such as the FIDO2 standard, we can start getting away from passwords altogether, but that has its own issues. For now, we need to focus on eliminating reuses and having second factors over making them too long and complex to remember.

How are those security assumptions holding up so far?

Firewalls

I’ve always assumed that firewalls were a necessity; however, I also think we need to understand where and when they are deployed. This is especially true in this day and age of Unified Threat Management (UTM) devices and personal firewalls for each and every endpoint. The marketing is awesome, the idea is appealing, yet the application of the idea is often flawed.

First, let’s set some definitions. When I use the term firewall, I’m talking about the basic functionality and not all of the add-ons we currently see. A basic firewall blocks or allows network traffic based on ports and a list of related rules or sessions opened from within the protected network and often provides Network Address Translation (NAT) services. Intrusion prevention/detection, web filtering and all of those other features that we often see housed in the same box are separate from what a firewall does. These are different technologies, so let’s be clear on that.

Firewalls lead to insecure configurations. They offer some basic types of protection; however, they can often be used as a mitigation that delays or even stops the application of real security. It becomes far too easy to deploy a machine with vulnerable services such as Telnet or FTP enabled, because we rationalize that the machine is kept safe by not opening the ports to the internet. Now what happens when an attacker compromises a machine that is on the local network through a phishing attack or other method? These poorly configured machines are then used to wreak havoc on your network.

On top of that, managing these devices can really drain your labor resources and have also been responsible for countless hours of downtime over the years. How often are changes to the firewall rule-set responsible for an outage in your organization? Now compare that to how often you suffer downtime due to an actual attack. Which is really your biggest threat?

EH-Net - Kron - Security Assumptions - Patch

A Patch Ain’t Just for Your Arm!

Consider this. In the real world, is a machine running a properly configured and patched SSH instance more secure with a firewall between it and the internet? Is it less secure connected directly to the internet?

If you use the Windows Defender Firewall on your endpoints, why? Ask yourself how much time you spend supporting it, and what it’s actually protecting against.

How about this question, which was posed to me by a friend… Do you know of a single instance where a firewall would have stopped an attack where the machine or service was otherwise properly patched and configured? Other than Denial-of-Service attacks, I personally could not come up with one. I can, however, list more than a few times in my career where the firewall was the cause of an outage.

Firewalls do a good job protecting misconfigured, vulnerable or unpatched systems from being exploited, but managing complicated rules can be just as much of an issue. They do not eliminate the need to patch and secure machines. These firewalls we rely on so quickly can actually make us more complacent and slower to patch and secure.

So does this break our security assumptions and make us think of going firewall-less? Hopefully not! But it should stress the importance of not just talking about the higher priority of patching but actually putting it into practice.

Disk Encryption

Over the last few years, the idea of disk encryption has really gained traction, but we have to ask ourselves if we have taken it too far. Again, it has its place, but how much time do you spend supporting it and how much of a threat is it really mitigating?

For mobile devices, Full Disk Encryption (FDE) is necessary in most cases. For typical workstations or even servers though, is it?

FDE mitigates the risk of physical theft of a drive and its associated data when the machine is powered off. It does nothing when the machine is turned on and the operating system is running. Here are a couple of questions to ask yourself:

  • Have you, or anyone you know had a data breach as a result of an unencrypted drive being stolen from a workstation or server?
  • Is a laptop with FDE but no password or a commonly used password (or perhaps the password written on a post-it note stuck on the bottom) less secure than one without FDE in the first place?
  • Do you require FDE and then give the users access to unencrypted thumb drives on which to store data and documents?
  • How much time and effort do you put into managing, supporting and setting up FDE?

If you aren’t required to do FDE on your workstations or servers by a regulation, or if you are not at a high-risk of physical theft, perhaps much of the time you spend dealing with FDE is wasted.

What Else?

So, what else might you be wasting time on? I’m challenging you to really consider what your risks are and where you are focusing your resources. Each organization has its own threats that it needs to contend with, and we can’t just apply a blanket solution, even within the same industry.

If you aren’t tracking every outage or degradation of service, start doing so immediately. If you already are, take a hard look at what is really causing your issues. Is it malware, phishing, misconfigurations, process problems or something else? Use your data to drive where you are allocating resources, not just tradition. And for goodness sake, please don’t ever rely on those tried and true security assumptions. We all know what the old phrase says about us when we assume.

 

Author Bio

EH-Net - Kron - PicErich Kron, Security Awareness Advocate at KnowBe4, is a veteran information security professional with over 20 years’ experience in the medical, aerospace manufacturing and defense fields. He is the former security manager for the 2nd Regional Cyber Center-Western Hemisphere and holds CISSP, CISSP-ISSAP, MCITP and ITIL v3 certifications, among others. Erich has worked with information security professionals around the world to provide the tools, training and educational opportunities to succeed in InfoSec.

All articles by Erich Kron

Tags:

Tagged: 

This topic contains 0 replies, has 1 voice, and was last updated by  janathan250 1 month, 1 week ago.

  • Author
    Posts
  • #170897
     Erich Kron 
    Participant

    EH-Net - Kron - Security AssumptionsHave you ever stopped to ask yourself if the things you are defending against are really your biggest security problems? I am going to challenge you to think about things a little differently, as I have been myself recently. Prepare yourself, as this may challenge some of your core security beliefs, things we have been taking as gospel since the early days of securing networks. We all know our time is precious and limited, so it is more important than ever to use what time we have wisely. That is exactly why I think we need to look deep into our beliefs and be willing to challenge ourselves on a profound, uncomfortable level. So, let’s make an attempt to be completely and utterly honest with ourselves about our security assumptions.

    Do you require users to have long, complex passwords and expect them not to write them down? Do you use firewalls to cover up unpatched software, block access to vulnerable or unused services or to make up for poor configuration? What about Full Disk Encryption? Do you deploy that on every machine in your organization?

    [See the full article at: Security Assumptions – Don’t Make an ASS of U and ME]

You must be logged in to reply to this topic.

Copyright ©2019 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.

Sending

Sign in with Caendra

Forgot password?Sign up

Forgot your details?