75

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

iainpb
  • 4,142
  • 2
  • 16
  • 35
Rakesh N
  • 851
  • 1
  • 6
  • 6
  • 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 '17 at 08: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 '17 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*. – Eric Lippert Nov 21 '17 at 03:21
  • 15
    "If we are behind a gate, do we still need to lock our front door?" – Tavian Barnes Nov 21 '17 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 '17 at 14:03
  • 1
    "We tried to defend our castle walls, but the attack came from within the halls" - A firewall quickly becomes meaningless if you don't fix the gas leak inside – Nic Robertson Nov 23 '17 at 22:34
  • “Recently, a third party Apache library's security vulnerability (apparently, a remote code execution one) was published.” Past any of the conceptual discussions here, patching an Apache server is so incredibly simple and easy to handle nowadays it should *not* even be considered something one sees as optional. If you are paranoid about breaking a system with a patch, that speaks more to crappy system implementation because patching Apache via a package installer is painfully simple. – Giacomo1968 Nov 25 '17 at 17:53

8 Answers8

162

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.

iainpb
  • 4,142
  • 2
  • 16
  • 35
  • 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)". – Monty Harder Nov 20 '17 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 '17 at 21:38
  • 21
    Users clicking on links they shouldn't. Users opening e-mail attachments they shouldn't. – Tracy Cramer Nov 21 '17 at 01: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. – R.. GitHub STOP HELPING ICE Nov 21 '17 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 '17 at 18:05
59

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 18
    how is the picture relevant here ? – Martin Vegter Nov 22 '17 at 15:53
  • 34
    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 '17 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. – Lightness Races in Orbit Nov 23 '17 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 '17 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.

ymbirtt
  • 483
  • 3
  • 7
  • 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. – Monica Apologists Get Out Nov 20 '17 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 '17 at 15:17
  • Yeah, I kinda went outside-of-scope on my comment above. – Monica Apologists Get Out Nov 20 '17 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.

tim
  • 29,018
  • 7
  • 95
  • 119
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.

rackandboneman
  • 975
  • 4
  • 9
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.

unknownprotocol
  • 347
  • 1
  • 3
  • 11
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.

mootmoot
  • 2,387
  • 10
  • 16
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.

dan
  • 3,033
  • 14
  • 34