Why is it bad to connect internal systems to the Internet?

Question

We have an intranet system we use to book, track and process invoices for our core business. My boss would like to move this system to the Internet to make it "accessible everywhere". However, I feel this is not wise. Are there some reasons that connecting internal systems directly to the Internet is a bad thing?

The system does have its own user and authentication system and was developed in-house by some gifted coders. It has also been penetration tested, but this was all done on the basis that the system was only accessible from the internal domain.

Answer 1

First, it might be best to fully understand the client (your boss's) needs. It's possible he or she only needs access to one small subset of the data on this server from anywhere and not necessarily all of it.

Where possible, instead of saying no in this situation come back with a few options.

1. VPN so people travelling, can access the data wherever they are at. If possible add additional security controls like internal firewalls and Data Loss Prevention (DLP) if needed. Harden and add additional security controls here as necessary.

2. Strong authentication and encryption to a separate server which contains a small subset of the data but possibly not all of the sensitive data. Harden and add additional controls here as necessary. Only allowing the server with the sensitive data to push data to the one that can be accessed publically and blocking all packets from the publically accessible server going back to the one containing the sensitive data can be a helpful trick (one-way firewall rule).

3. Create a secure front-end server which can be accessed from anywhere and has controlled access to the backend server. Harden and add additional controls here as necessary.

4. Harden the server itself and if applicable deploy a WAF, or other controls, in front of it.

5. Think of other creative solutions depending on your boss's actual needs (your question isn't specific about the actual needs).

No matter which option is chosen make sure you log and monitor access to the system. It would be wise to follow up with your boss after the system starts getting connections from other countries (or at least IP's that are obviously not from people who work with you) and show him or her the global connections to the system. Sometimes this real-world feedback is required for people to understand that the risk.

Use this as a chance to educate your boss but do so in a very humble manner sticking strictly to real data, he may have had too many people selling security to him with Fear, Uncertainty, and Doubt (FUD) and may simply not listen to anything that sounds similar regardless of how legitimate this information is. Beware of FUD fatigue. If he or she has reached their limit anything you say in this respect will have the opposite effect you want. When this occurs your best solution is delivering factual data and allowing him or her to come to their own conclusions.

Be a problem solver here, provide your boss with solutions, rather than simply with reasons to say no. Don't be afraid to propose expensive solutions that you think are too expensive for the company, your boss may be ok if it moves functionality forward quickly for him or her. That said when possible, always keep security as inexpensive as possible long-term (avoid recurring costs that may get cut during an economic hardship). View this as an opportunity for you to get more security in place by enabling the business rather than fighting it. If you show that you can empower the business and frame needs in terms of what moves the business forward or how things could affect the business you'll get much better response from people like your CEO. Understanding when the business is in a rush is important too, it's not uncommon for a company to pay more money for a solution or approve things which they might not otherwise approve if it can add value and be deployed quickly. To this end, knowing when to time requests and understanding the urgency of the projects in flight will also help you.

Think of this part of business as a martial art, you want to leverage your opponents energy and redirect it to a place you want them to go while minimising your own energy expenditure. If you can quickly grab his or her desire to have this accessible, now might be a great time to get a lot more security in place. Speed is important here and you need to get buy-in while it's hot so to speak.

Finally, recognize that you will be much better off addressing this as a business problem that you can help with, rather than just a technical security problem. Likewise, start looking for and anticipating additional security needs going forward and bring them to your boss early on so you look like someone helping the company rather than as a roadblock to progress. This bit of framing accomplishes the same objective but gets security in faster and with less conflict.

Addition after original post: One thing that may also be helpful for you is to create a long-term security roadmap and share that with your organization. What this entails will be different for every organization but it's very important to show the work you are not currently doing and also work that may be things your organization will never do internally (small start-ups are less likely to have forensic teams in-house). The reason for this is to help educate and also to help set expectations with your leadership team. This is something many security teams have in their head but formalizing a plan and showing a path forward can help you get more buy-in for your security program. A large part of this is about communication and having a shared vision business-wise but another part of this is about educating senior management about where they are risk-wise. I find that visualizing your organizations security-debt helps people automatically make more thoughtful decisions.

Answer 2

Are there some reasons that connecting internal systems directly to the internet is a bad thing?

You're unnecessarily increasing the attack surface. Here are problems to consider:

• An attacker who obtains control over this single exposed service can eventually leverage that access to infiltrate other services on the intranet.

• You might be having a hard time monitoring the logs for unauthorized access. Attackers from everywhere will attempt to log in and exploit the service, constantly triggering false alarms.

• Attackers could DoS the server and make it unavailable - even unintentionally, using automated scanning tools to test the application for vulnerabilities or in an attempt to brute-force logins.
• If a stranger captures the login credentials of an employee logging in from a pulic hotspot (you're hopefully using HTTPS, but they might just be shoulder-surfing), they can log in straight away from their own browser without having to get inside the company network in the first place.

• Even if the service uses HTTPS, the hotspot owner will know that the employee accessed internal.yourcompany.com and might become interested.

• If you're using a known framework, CMS or other popular software, you have to be fast with updates if a security problem with that software becomes public. You have to expect that attackers are mass-scanning servers for unpatched instances.

• You're exposing which technologies you use internally. That's not necessarily a bad thing but it might work as an argument to your boss.

• You say the service has had a security audit - does your boss trust the assessment to a degree that any stranger on the internet may challenge it?

Most of these problems could be mitigated with a VPN solution for employee remote access instead of directly exposing parts of the intranet. A VPN gives your boss the ability to quickly enable, block and monitor remote access directly at the gateway.

Answer 3

In a commercial applications/systems/deployment, you never run a system outside of the official specifications.

The fact that the system was developed and penetration-tested under the assumption that it will be deployed to internal network only should be enough to convince your boss. Developers and caretakers (you being the latter) of such a system will not and cannot accept the blame for any consequences, which may or may not be severe.

If you need analogies to convince your boss, here are some:

• Running company's trucks past the red line RPM to speed up deliveries
• overloading your electrical network with higher amperage than fuses allow to save on electrical system upgrade
• landing an aircraft at a speed beyond max landing speed

I am sure the boss would not dare to suggest any of the actions above. This is everything you need to convince him. Many people contributed valuable detailed information to this thread, but the core of the argument is in my first sentence, in bold.

Answer 4

Some good answers here. To add on, here are a few bullets.

• By placing the application on the internet, you are not only exposing that application, but increasing the exposure of your internal applications as well. if your invoicing application is compromised, a hacker may be able to use it to access your other internal systems.

• Invoice data presumably contains information about your customers. You will be responsible if any of their sensitive data gets exposed.

• Putting your application on the internet may add an additional regulatory burden. For example, if you handle health care information, you will need to meet HIPAA's cybersecurity standards; if some of your customers are government agencies, ISO-27000 may apply.

• If you intend to use the same authentication mechanism, it is possible your password complexity rules aren't good enough. You may need to set the password-reset flag on all users and have them set up new passwords under new complexity rules.

• When you put a site on the internet, you may require more hardware. You will need at least a perimeter firewall and possibly an additional firewall to establish a DMZ. This may mean that your web servers will need two NICs each.

• You may need to purchase a public SSL certificate, which comes at a cost.

Answer 5

With the limited information you have provided, here are my inputs.

Exposing a currently internal system to the internet may or may not be a bad idea depending on various other factors. The question you need to ask yourselves before making it accessible to public are the following.

1. Who are the potential users of the systems and service?

If the application is only used by employees, the wise move is to make it accessible over VPN. However you can make it public too, after performing an architecture review.

2. What is the current risk profile of the application?

I understand that the application handles sensitive data. But what is the risk profile of the application according to the organisation? Understanding this is important because one of the factors affecting the risk profile is going to considerably change - the internet footprint - after making this change.

3. How often do you pen test the application?

The current risk profile of your application may not be high enough to perform regular pen tests. The likelihood of new vulnerabilities, zero days etc also need to be considered while exposing it to external network.

4. Authentication mechanism.

Does the application use domain credentials? Does it use encrypted traffic? Does it use 2FA? Does it have a lockout policy? Many of these questions may have been ignored as low risk while performing a pen test considering the application as internal. A fresh perspective testing on the application as an external application may be required before deploying it to the public.

Answer 6

1. Anything that's on the internet can be compromised and should be treated as insecure.
2. Anything that's not on the internet is harder to compromise but can still be compromised and should be treated as if it's on the internet.

In other words, keeping a system off the internet makes it more secure but isn't an excuse for bad security elsewhere in the system. I'm concerned about your "this was all done on the basis that the system was only accessible from the internal domain" part - a system that's not on the internet should be made as secure as a system that is on the internet, and as far as designing/auditing/pentesting goes it should be treated as if it's on the internet. However a sensitive system should always be kept off the internet unless there's a very essential reason why it has to be on the internet (e.g. there are offices in a remote location).

A similar situation applies to VPNs, proxies, gateways, and so on. They make a system more secure, but they're no excuse for bad security elsewhere and they can still be compromised. It's like putting another lock on your door - it might slow an attacker down but it can't stop them, and your system is still far less secure than if it was kept off the internet.

Answer 7

There is a rational formula for risk. Risk = Threat x Vulerability

What is the value of the asset? (What will it cost to recover if the data is lost, stolen, or damaged? Is it customer data that will cause you to get prosecuted if it's stolen? How valuable is this data to hackers or competitors?)

Identifying the value of the asset helps establish how likely a threat will exploit a vulnerability to cause a loss.

What are the vulnerabilities? (You are already attempting to establish the vulnerabilities with the pen testing).

What is the cost of a security control to mitigate a vulnerability? If the cost of the control exceeds the cost of the asset then it's not worth installing the vulnerability mitigation.

If you run this data by your boss, he/she may think about the cost of convenience. Some people think the cost of convenience is well worth the risk, while others want no risk and do not care about convenience. Remember that risk mitigation is the key factor.

Answer 8

The main security risk is not the VPNs. All of them are very well hardened against any possible crack.

The security risk is the content what you move through these VPNs, and the false belief that the VPNs will defend your system. Yes, they will nearly surely defend - against the attacks to the VPN. But not against the attacks of your booking system, which is surely far more complex, and far lesser security tuned.

Its traffic between your external hosts and local network is perfectly legal traffic from the view of the VPN.

If you use a different solution, and not a VPN-based one (for example, by using some data syncing), then you can protect far better your internal network, but can't solve the essence of this problem.

In my opinion, if it is a booking software, then it may be about financial, thus highly sensitive and private data of the customers. Most companies I know, they defend their customers data actually more strongly as their own, and it is a quite rational behavior from their side. Without knowing anything from your system, I see it quite possible that this data is actually more important for your employer, as your whole local network et al. Your boss surely knows this, and I think if you want to convince him, argument into this direction and not into technical ones.

Answer 9

Your question includes the biggest reason.... it was penetration tested under the assumption that the system is not accessible externally. So start with the cost to perform the pentesting without that assumption and that testing will come back with all the risks.

Making they app accessible externally without proper pentesting shouldn't even be considered your you and your company. You are not a subject matter expert in assessing risk of exposing a service which was designed to be internal to the public internet.

We can all guess the numerous ways this application would expose your company, but that is only guesswork. You have to assume the worst case, which is that someone breaches the hosting server and gains root access to the server and then uses that to gain access to all your other servers. IF your business depends on your IT systems then your business can be disrupted to the point that you are unable to conduct business, suffer the loss of credibility within your industry, and potentially legal consequences.

Answer 10

In a language that your boss will understand: The disadvantage is that he has to worry about security, most likely in the form of hiring some external experts, and boy are we expensive.

Once you put the system on the Internet, every bored hacker from China can break in, just for the lolz. If you don't think they will do (standard argument "we have nothing worth stealing"), look back at what I wrote: The lolz. You don't need a reason to break into a system. The majority of attacks these days are undirected, i.e. they simply throw a bunch of standard exploits at a whole network and see who falls over. Only after they've broken in will they even check what or who it is. And if you have nothing to steal, there is still CPU power, bandwidth and being part of a botnet.

Having a system not on the Internet is the #1 security measure even for Internet systems. That means if he wants it on the Internet, fine. But there should be a Firewall and/or a WAF and/or an application gateway in front of it and a DMZ around it. Of course you can put it on the Internet if he wants to. From your question it's not clear your boss understands that means more than putting a different cable into the network port.

Answer 11

If your system was built for being publicly accessed it would be very smart to do that.

There are services that let you manage invoices directly on the Internet, for instance.

Having a service opened to the Internet does not make it inherently more or less secure. However knowing it is more exposed should become a very good incentive to make it as bulletproof as possible.

In other words, if you know your apps are hidden behind your internal network, the day someone breaks in, it will be very fragile. Most systems those days are not 100% isolated from the outside world forever: wifi access, firewall breaks, viruses, vpns, ...

So it is good practice to have security in depth.

If it is inherently secure, I then don't see why it could not be opened on Internet. Today, banking, online gambling, even healthcare are accessed from Internet.

So it is doable.