76

I have recently joined a security focused community in my organisation. Many of our products are deployed in the intranet (on-premise) nothing in the public cloud. So, the internal portals can be accessed within the organisation's network only.

Recently, a third party Apache library's security vulnerability (apparently, a remote code execution one) was published. Our security lead had asked us to upgrade the library to the latest fixed version immediately.

I had asked, "Since the portal is accessed only in the intranet behind a firewall, do we still need to upgrade the library?". The lead could not provide a detailed explanation due to lack of time and confirmed that the upgrade needs to happen regardless.

So, what's wrong with the statement (assumption?), "since we are behind a firewall and such vulnerabilities do not affect us".

7
  • 43
    First of all, not all of your internal users are trusted. You don’t want everybody to see or be able to change everything. There are enough compliance frameworks which exactly ask for separation. And secondly there is the principle of in-depth Defence, an attacker might make it around the firewall and their lateral movement should be limited. Today with BYOD, WLAN, on-site visits and internet facing services the perimeter is no longer the last line of defense (but the first). However only the first point would explain urgency.
    – eckes
    Nov 20, 2017 at 8:47
  • 23
    The NSA - one of the US government's bodies with the highest security requirements and toughest background checks for their employees - was compromised several times now by one of their own. Trusting you employees is good, patching your systems is even better.
    – Tom K.
    Nov 20, 2017 at 14:55
  • 40
    Do you know why firewalls are called "firewalls"? Firewalls are walls that are resistant to the spread of fire. Would you ever say "we're behind a firewall, so we don't need smoke alarms, a sprinkler system, or emergency exits?" Firewalls resist fire spreading; they don't prevent them, and they are intended to be a part of a defense strategy. Nov 21, 2017 at 3:21
  • 15
    "If we are behind a gate, do we still need to lock our front door?" Nov 21, 2017 at 14:49
  • 2
    So, you prevented a direct attack from the outside. What if one of your intranet PC gets compromised, and then that one launches the attack? First rule of IT Security: trust no one
    – BgrWorker
    Nov 22, 2017 at 14:03

8 Answers 8

163

Your statement makes two faulty assumptions:

  1. Your firewall(s) is/are fully correctly configured and has no vulnerabilities that would allow an attacker to compromise it and that perfect state will continue.

  2. Everyone in your organisation is trustworthy and presents no risk.

You should always operate on a defence in depth approach and secure every layer wherever you can. If an attacker does penetrate a perimeter, or you do have a rogue actor, then this Apache vulnerability could be exploited if unpatched.

5
  • 37
    If you look at the details of well-known data breaches, you'll find that often the first thing to fall was some third-party device on the network, which was then used as a beachhead to mount further attacks. It wasn't even a question of trusting everyone in the organization, it was a failure to appreciate that the equipment not owned nor operated by the organization had nevertheless been allowed "into" the organization without ever appearing on an org chart as such. So I don't know if this qualifies as a "3)" or just a further elaboration on "2)". Nov 20, 2017 at 17:16
  • 8
    And 3) there is no way for an attacker to bypass your firewall. (Such as by plugging a Raspberry Pi into an internal network port)
    – user253751
    Nov 20, 2017 at 21:38
  • 21
    Users clicking on links they shouldn't. Users opening e-mail attachments they shouldn't. Nov 21, 2017 at 1:41
  • Item 2 should really be broken down. "Is trustworthy" and "presents no risk" are two huge categories in themselves. The latter is likely more important and includes things like malware infections on their boxes. Nov 21, 2017 at 17:47
  • 1
    In addition to 2) EveryONE... I would add 3) EveryTHING inside is safe and unaltered. With all the IoT things passing data in and out of networks, it only takes one item inside that's available from or in contact with outside to be affected.
    – WernerCD
    Nov 21, 2017 at 18:05
60

This is an age-old question and always has the same answer.

Chewy Center

You cannot depend on your attackers being unable to access your network. All it takes is a single employee clicking on a phishing email and the attacker has a toehold on your network. If you leave everything unpatched, they will have a field day.

4
  • 18
    how is the picture relevant here ? Nov 22, 2017 at 15:53
  • 35
    The picture represents someone who built something to protect themselves from the outside, but it wasn't designed or expected to protect them from every threat. In this case, someone built a structure to protect themselves from the elements but not wildlife. Also it has smiling polar bears. Who doesn't love smiling polar bears?
    – corsiKa
    Nov 22, 2017 at 16:41
  • 4
    Or, more accurately, someone built a structure to protect themselves from the wildlife without realising that the wildlife find said structure delicious and can/will simply eat straight through it. Without further defences inside the structure, you're immediately hosed. Nov 23, 2017 at 15:40
  • 1
    I think this is the simplest and most powerful answer: "All it takes is a single employee clicking on a phishing email."
    – Jon Watte
    Nov 25, 2017 at 19:18
27

Threat reports routinely find that you are significantly more at-risk from your own colleagues than you are from outsiders. From this 2015 report, for instance, we have the following figures:

74% of breaches originate within the extended enterprise – either amongst employees (40%), third parties (22%) or ex-employees (12%) – with 26% originating outside the organization

...

Two-thirds (67%) of internal security breaches originate from inadvertent error – one in three (33%) is due to malicious intent

So 33% of 74% gives us around a quarter of all breaches being caused by one of your own colleagues deciding they don't like you.

This specific vulnerability would need to be exploited by a malicious and technically capable insider threat. On the one hand, the "technically capable" qualifier here narrows your likelihood of attack quite significantly. On the other hand, "this vulnerability only leaves us vulnerable to insiders" is a wholly inadequate reason to not patch.

3
  • Technically capable only covers actual exploits, whatever. I can piss off my finance person real bad and have them leak my information to some Russian crime syndicate. That's not to say that these are "real" breaches, just that technical skill isn't necessarily needed. This also means that hardening has to be more than just applying patches and using strong passwords. Nov 20, 2017 at 15:14
  • 1
    @Fistbeard, sorry if I was unclear, but "tecnically capable" was referring to someone exploiting the RCE vulnerability in OP's question.
    – ymbirtt
    Nov 20, 2017 at 15:17
  • Yeah, I kinda went outside-of-scope on my comment above. Nov 20, 2017 at 16:10
13

Yes, you do need to patch internal systems.

Let's assume the following is true (which it probably isn't):

  • your internal system is 100% impenetrable from the outside world (or you are fine with every internal system being taken over in case of a breach).
  • you 100% trust everybody in your organization (or more accurately anybody with access to the intranet, which may also include visitors, temporary employees, etc).

There are still web-based vulnerabilities which do not require access to the intranet at all, specifically reflected XSS and CSRF.

If you take the same approach of not updating with web applications as you take with web servers, it is fair to assume that some applications will be vulnerable. Now an attacker that knows or guesses what software you use might be able to gain code execution via XSS or CSRF if anyone in your organization is not careful when clicking on links or visiting websites.

6

To explain metaphorically:

A firewall, in the usual meaning of a directional packet filter/NAT masquerading gateway, will keep the rest of the world from force feeding your "people" poison.

It will also keep them from causing too much damage to the rest of the world if they go insane and violent in case someone still does poison them.

Unless you keep them on a very strict diet, it does not keep your people from reaching out for and eating food that someone poisoned, either with the express purpose of poisoning them, or just out of sheer untargeted sadism, to cause terror...

A more advanced firewall (Deep packet inspection, blacklist/whitelist etc.) will police the food, but still be unreliable at it. It can also create trouble when it thinks fabric softener is gatorade, or that smelly cheese is an attempt at gassing everyone, or that salt being greenlighted means that a bottle of saturated brine will be safe to consume.

6

Insecured Intranet-only services and applications are often the end-target of breaches. Sadly, more often than not over-confident (and dare I say naive) system/network admins) neglect to secure them.

What if a normally trusted intranet user's machine contracts a virus, or trojan, or botnet malware, or what have you, that scans your intranet from within, and sends that info to an untrusted party? Now the untrusted party not only has a vector into your intranet, they know the layout and how to access it's unsecured services.

To counteract the many unforeseen vulnerabilities one should have multiple layers of security, not just one.

5

Software vulnerabilities is an issue that is difficult to mitigate with specific measurement unless it is fully tested. So no vendor can answer you such question unless they are very sure about the mitigation method using firewall.

In fact, you should asked whether the patch will break your current application and process, whether it can be rolled back.

1

To maintain up to date a firewall and to maintain up to date softwares are 2 independant lines of defense

In short, the answer to your question can't be yes or no, both are wrong.

And here are some explanations why:

  • A "perfect" firewall (this model doesn't exist) and even a completly isolated intranet (i.e. with not a connection to the Internet) doesn't protect your systems against the connection within this highly protected intranet of a contaminated or attack computer. (This a real life feedback : ~ one such attack from the inside / year). See also Stuxnet (2010, analysed by Kaspersky Lab.).

    In short even a "perfect" firewall can't protect you against the major risk from the inside.

  • On the other extrem of the spectrum of evil events, an upgrade of an OS or a software isn't the guarantee of an improve of security. Most upgrades of software are increases in number of lines of codes and the probabilities law tells us that the number of bugs increases proportionally. An OS upgrade may open a vulnerability on port 80/tcp (http) inside Apache which wasn't present within the previous version. And as is the case on many firewall configuration, this protocol might be legitimatly permitted to enter your network. Then your OS upgrade might cause a serious vulnerability within your whole network. See also remote root access vulnerability by upgrading to MacOS High Sierra (2017, analysed by Lemi Orhan Ergin).

    In short, even a "perfect" practice of "always update" can't protect you against the major risk of editors bugs in front of an open port of your firewall.

There are many other scenarii to demonstrate that none of these 2 approaches is sufficient: the "perfect" firewall, the "perfect" upgrade practice.

So what should I do?

My personal advice it to maintain firewalls and softwares up to date independantly after a minimum checking that none of them is introducing a vulnerability which the other isn't prepared to defend against.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .