{"id":137,"date":"2006-06-06T00:00:00","date_gmt":"2006-06-06T00:00:00","guid":{"rendered":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/2006\/06\/06\/how-to-protect-your-network-when-outsourcing\/"},"modified":"2021-12-30T11:36:35","modified_gmt":"2021-12-30T11:36:35","slug":"how-to-protect-your-network-when-outsourcing","status":"publish","type":"post","link":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/2006\/06\/06\/how-to-protect-your-network-when-outsourcing\/","title":{"rendered":"How to protect your network when outsourcing"},"content":{"rendered":"<p>Outsourcing, right-sourcing, best-sourcing &#8212; does anyone know what the latest buzzword is for this practice?  No matter what the neologism is, it presents real issues that many of us in the network security field face every day.  How do we allow offshore workforces into our domestic systems securely?  This seems like a simple question with a simple answer: Set up a VPN or a Web service and call it a day.  The author wishs that was the case, because it would give me more time to improve his golf game.  But before you make a tee time, beware that there are a number of serious problems you can face that never seem to materialize until 2 a.m. the night before you go on vacation.  The offshoring of technical jobs means that corporations need to connect their domestic network with a foreign network.  Making this connection raises real security concerns.<br \/>\nThe foreign network represents a vast unknown.  You have no idea what &#8212; if any &#8212; policies the partner company actually enforces, how aggressive it patches systems and what the overall state of its network is.  Regardless of what is discussed in contracts, wide-open access is extremely insecure.  And because most offshore work is actually taking place in the middle of your night, if something goes wrong you get the pleasure of waking up to a BlackBerry alerting you in the wee hours of the morning.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The type of work the offshore group is contracted to do will influence how you extend your network.  If the offshore group only needs to check code in and out, a full VPN would be overkill.  Most major code repositories have built-in Web interfaces and username\/password protection.  Your network only needs to be extended to allow the front-end Web piece to access the back-end code repository.  Using the popular Concurrent Versions System (CVS) as an example, there are several free, commercial-grade Web front-ends available.  By setting up a publicly available Web site, using Secure Sockets Layer and relying on the built-in username\/password protection in CVS, all that is required is a public IP address and fully qualified domain name.  This is a simple solution that will let you sleep at night and play an uninterrupted round of golf on the weekend.<\/p>\n<p>It also applies to offshore work that doesn&#8217;t require live access to your internal systems.  Building on the above concepts will work for any access requirements that don&#8217;t involve live, real-time access to systems.  If the business requirements are more involved than simple code check-in and check-out, then put the clubs aside.  <\/p>\n<p>What are the services the offshore workforce will need to consume that are hosted on your local network, such as Web services, database services or Network File System services?  It might seem like more work than necessary to grant access to these systems at such a granular level.  But by only exposing the application ports and hosts that are required for the specific job, you prevent any other traffic coming from the offshore network into yours, regardless if the traffic is hostile or not.   Depending on the size of the offshore workforce, there are two common methods normally used to accomplish this &#8212; implementing a LAN-to-LAN VPN tunnel or client-based VPN access.  A LAN-to-LAN VPN tunnel is a secure connection between two otherwise separate networks.  A VPN endpoint can be a router, firewall, Windows server, Linux system or a dedicated VPN concentrator &#8212; anything that can encrypt and decrypt packets at an acceptable speed.<\/p>\n<p>At this point, you have selected an offshore business partner, gathered a list of resources and purchased a VPN endpoint device.  Name resolution, routing, latency and IP address conflicts all have the potential to keep you off the golf course.  For an offshore workforce that has its own internal DNS servers, name resolution for the resources\/hosts that I identified earlier can be an issue.  A DNS zone transfer can be done between your DNS servers and the local DNS servers inside of the offshore group&#8217;s network, or you can create alias records on your public-facing DNS for these hosts.  This filters traffic after it comes out of the VPN tunnel and before it reaches any part of your local network.  You need to inject this network into your routing process or use static routes on the systems that the offshore group will access.<\/p>\n<p>All the traffic that will come through the VPN will traverse the firewall.  There are devices that will perform the VPN piece, NAT translation and stateful inspection all in one, but I have found these devices very hard to troubleshoot when using all of the above functions and not very good at controlling access to perform different functions.<\/p>\n<p>http:\/\/www.computerworld.com\/action\/article.do?command=viewArticleBasic&#038;articleId=9000983&#038;source=rss_topic17<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-137","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/137","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=137"}],"version-history":[{"count":1,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/137\/revisions"}],"predecessor-version":[{"id":2624,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/137\/revisions\/2624"}],"wp:attachment":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}