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.

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. 


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.
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).
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.
Harden the server itself and if applicable deploy a WAF, or other controls, in front of it.
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.   
