Are You Avoiding These Top 10 File Transfer Risks?

Brooke: Hello everyone. Thank you for joining today's webinar on the Top 10 File Transfer Risks, and how to avoid them. We're glad you're here, and hope you find our presentation helpful today. Before we get started, a few housekeeping notes. We are recording this event, and after the webinar's over, you'll receive a followup email from us, with the link to the recording, in case you miss any parts or want to share it with someone. The event is scheduled for an hour. If you have any questions throughout the event, please submit them through the Q&A window, in the bottom right of your screen. We have some team members who will try to answer your question as it comes up, and we'll also answer questions live at the end of the event. And lastly, at the end of the webinar, you'll see a quick survey pop up. Please do fill that out, it helps us understand how we did, and what parts of the presentation were most helpful to you. And if you have any questions that aren't answered on today's call, you can enter those there and someone will get back to you. All right, so let's take a look at the agenda for today's webinar.

We have a pretty straightforward agenda. So we're going to get started with a quick introduction to the topic. We'll go through the 10 common file transfer risks that you may face in your everyday environment. We'll do a brief GoAnywhere MFT overview for you, and we'll have time at the end for question and answer time. Let me introduce our speaker for today.

About the Presenter

So today's presenter is Rick Elliot. Rick is a Lead Solutions Consultant, here at HelpSystems, and Rick has worked with our GoAnywhere managed file transfer solution since July, 2012. The neat thing about his story is that previously while working at Discount Tire, Rick actually used GoAnywhere. So he has a really unique perspective as he traveled all over the world helping our customers with training and migration and all sorts of things. He really knows what he's talking about. One fun fact, after Rick lived in Phoenix, which is hard to imagine today from our snow covered Minnesota headquarters. All right, so that's Rick, and I will let Rick take it from here.

Rick: Yay for blue skies and warm weather. Maybe a few clouds and a couple of palm trees. I'm okay with that. But hello everyone. My name is Rick Elliot. I am, as she said, I'm a Lead Solutions Consultant here at HelpSystems, and I've been working with the product for quite some time, and kind of worked with a lot of companies on understanding the product and getting it installed and utilizing it and taking advantage of the features that it actually has. Today I want to talk about getting into FTP, and understanding what it is that you need to look at. What are the risks of utilizing FTP?

So to start off with, let's just ask yourself, have you ever caught yourself saying something like the following: "My company's so small, I don't have an IT department, so I do all of my FTP from my desktop. I use Filezilla, or I use WinSCP, or something like that." Do you catch yourself saying, "Hey, the company is so small, or it's a medium size. We don't really worry about that. I don't think there's a whole lot of companies that are going to mess with us, or hackers really care about my company." Or, "We're just a large corporation. I'm pretty sure somebody in the company has already got that taken care of." Or maybe you stop and say, "The network administrator or the system administrator has already got that. I'm not worried about it." And last but not least, have you ever really said, "Well, I'm pretty sure we've never been hacked."

If you've asked yourself these questions, and you can honestly answer them and say, "I'm pretty sure I've never been hacked," odds are probably you already have, and you don't even know it. Especially if you're using FTP. Now you're looking at the possibility of different things happening if you're utilizing an FTP protocol to communicate with companies outside of your network. This happens when you don't securely secure the site you're communicating with. You basically allow directory listings or anonymous FTP access. You don't secure the network properly. You run jobs under privileged accounts, or you don't set up proper ACLs or firewall rules. All of this makes it easier for an attacker to scan for vulnerabilities. They're going to look to find some means to provide an elevated access, privilege to get into your system.

Not to mention if you have a large or poorly trained staff, meaning they don't understand, not sure what happens in those situations. That totally increases the odds of someone doing a social engineering attack, and being successful. Think about whether or not your company is high traffic, high revenue, lots of sensitive data, HIPAA, PCI, et cetera. What if it has all of that? That immediately puts you at a larger risk for something happening. You're more targeted than most other companies in that instance, and those are the things that we want to talk about.

Data Breach Statistics

Looking at a couple of statistics here, you can see that the identity theft resource center says there were over 1,093 data breaches in 2016, a 40% increase over 2015. That's a lot. Companies on average are spending about 73.7 billion. That's with a B, in 2016. That's almost a 10% increase over 2015. And I'm sure that number is increasing the further we go. That means that more major corporations and small businesses are really taking secure transfer as an item that they really need to address. Sensitive data, personal data, PCI, HIPAA, et cetera. They're really taking a look at that now. So where does your company sit, between transferring sensitive data, even internally, and also including transferring data to your trading partners? Where do you balance mitigating that risk of using FTP, and getting that data to and from either the trading partners or internal? Are you willing to mitigate that risk by using FTP? And that's the question we want to kind of talk about.

If you still think you're not vulnerable, think about these items. If you know you're using FTP, do you have a password guessing feature on your FTP server? Meaning if you don't get the password right within three or five times, I'm going to disable the account. If you have one, do you even have it activated? Some companies don't. Do you force a password change on a regular interval? 30 days, 60 days, 90 days, whatever that is. Do you have a denial of service or brute force attack feature? Can you set a sensitivity level with your FTP service, so that if somebody is trying to break into your door, you literally can shut that down by an automatic IP blacklist? Is it enabled? Malicious names, do you check for them to make sure that someone's not trying to get into your system as a root, or an admin, or an administrator? Something that you know if they're signing on with that user ID, they're not looking to bake cookies and be happy.

Is your anonymous functionality disabled? Do you still allow people to just anonymously sign onto your system and upload or download files? Do you have a password intelligence built in? Do you put some kind of functionality into the password? Meaning it has to be X number of bytes, or include at least one or two special characters and numeric values and upper and lower case, to control access? Do you utilize two factor authentication? Do you provide a way for somebody to provide multiple access, like a PIN number, or something associated to the password? An SSH. Is your MFT server old? A lot of times people use their MFT servers as leftovers from other situations. I've seen some using 2000, 2003, even older. Are they updated? Do they contain the latest server updates, security updates, something that allows you to control what's happening just in the environment? Not on the communication, but just the environment? And last, do you use freeware to do your communications? Do you store information in the freeware? Do you bank on that freeware that somebody actually created and said, "Here, use," and you really don't know what's included in it.

Examples of Breach Victims

Let's take a look at the elephants in the room and talk about that. IHG, talking about Holiday Inn Express or Staybridge or Candlewood. They have reports of tens of thousands and even sometimes millions of points being stolen and used for fraudulent booking. That's a lot of money that can be disappearing right from under their nose, just because they don't have control over it. ESEA, they had 1.5 million records leaked. And they said that they were contacted by the hacker, and he requested $100,000 ransom just for his information. That's a lot.

Yahoo. If you have a Yahoo account, it was hacked. Three billion accounts, hacked. Information, user IDs, passwords, names, locations. Any information that they had associated to that account was hacked. Target, over 40 million instances of credit and debit card information was stolen. Again, these companies think they have it controlled, or they actually have security in place. Something went wrong somewhere. And as of late, the big elephant in the room, Experian with 143 million Americans' information was exposed. Over half of what's in the US. They think that they are actually utilizing things correctly, and these are people who are putting a lot of money into security. If you're not, do you think you're not exposed, or that there's not a risk using that?

So think about it. Are you sure you're actually ready to utilize FTP? If these companies in this size are using something that they can't control, or somebody hacked and got into that security, at least it's worth looking at and making sure.

Risk #1: Giving away user IDs and passwords

So let's step through some risks here of what you actually can think about with FTP, and whether or not it's worth it to mitigate that risk of using FTP, as opposed to having data or giving someone access to your system. Did you realize that one of the bigger things you're going to do here ism you're going to give away user IDs and passwords, mainly because it's not a secure transfer protocol. User credentials aren't encrypted. They are sent in the clear. User IDs and passwords.

This data can be sniffed and stolen during transit. There's extensive literature out there on the internet, root kits, sniffing software, key loggers, all of these things you can identify out on the internet to figure out how to do. Keep in mind folks, I'm not talking about inbound communications from an external source, as much as I am internal employees, or internal people that can get access to information that maybe they shouldn't have. Code injection attacks is one of the most common things. Somebody puts something out there that actually will... They'll put some kind of a malicious code on your system, and it literally exploits the weaknesses.

That means they can hack credentials, user IDs, passwords. Install Trojans and viruses to go in and look and then do insufficient sniffs and pulling information out of your transfers. Especially if you're using FTP. Try to use protocols like SFTP, OpenPGP, to encrypt data before you send it. FTPS, HTTPS or AS2. All of these require a secure channel. They use SSL or they use SSH. They use a more encrypted defined transfer protocol that you can utilize for securing that transfer from one instance to another. Block these situations, and if you don't open it up to that, then there's a less likely chance that you will be hacked. Always ensure your IDs and passwords are encrypted, even at rest. Never store them on your local computer, and always, always disable that anonymous, unless you have in a controlled environment, you know what it's for, or you don't care if someone hacks into that system. There's always a possibility there.

Risk #2: Sending unsecured plain text emails

Plain text emails. Data is always being sent. "Oh, it's okay, I'm just sending an email to somebody. I can just put this attachment there, nobody's going to pay attention to it." No. Any sensitive data going through an email is exposed. Even if it's in a document, it stores that data on exchange servers. Anybody who is an admin, or has access to an exchange server can get access to the data. There's always a possibility of something being sent to the wrong address. Things you can do here is you can actually provide a secure mail server.

Don't allow that sensitive data to be kept in an exchange server. Store it encrypted at rest. Take advantage of an encrypted file storage retrieval. Password protect that link. Provide an encrypted link. Store the data behind a firewall that doesn't have an open inbound firewall rule. Put the data out there and take advantage of it in a secured fashion, and now you can move that data and share that data securely with your trading partners and your customers.

Risk #3: Exposing data to the DMZ (Demilitarized Zone)

Do you expose data to the DMZ? A lot of companies still have this. They'll have a listener, like an SFTP listener, FileZilla, something like that, in a DMZ server. And then they will actually transfer files from their private network to that DMZ server, and then tell the customer, "Hey, the file's there for you to come pick up," and then they connect and download the file. Or they upload the file to that DMZ server, and then you go check every so often to see if there's something, and pick it up and bring it into your private network. It's exposed. If people can get to the DMZ, they can do something with it.

You have a higher risk of being accessed by hackers that way. Just because the DMZ is exposed to the internet, now you have to set up some manual scripts and moot that movement to move things around. Still not a good idea if you're putting those on the DMZ server, because they can be hacked. Solutions to this is to install a reverse proxy gateway. Put a listener in the DMZ that has no information, no user IDs, no passwords, no data. Put it behind a firewall that has no inbound firewall rules. Keep your data inside the private network. That way you don't expose it to being hacked in an open ended access to the internet. Only allow people who have authentication to get through the door. Log, record, maintain compliancies necessary to know who comes in and who picks something up or who drops something off. Never store data in the DMZ, regardless of whether it's sensitive not. I wouldn't put data out there for somebody to hack and get into if it's something I don't want floating around, especially if it pertains to my business.

Risk #4: Having open ports in your network

Inbound firewall rules allow hackers to gain basic system access. This has been true since quite forever. It can allow them enough privileges to compromise your systems, get access to critical applications and services, even potential direct access to your production systems. There's numerous ways this can happen. I've seen times where customers say, "Okay, I'm just going to set up an FTP connection to my system, and let my trading partners sign in and just drop off files." That's well and good, but if that FTP access was not controlled, or maybe they opened it up, and all of a sudden you allow quote commands and they can execute commands on your systems that you didn't know. Or use it to do something different that you don't want them to do. Again, push them through a reverse proxy, get them off of your private network. Don't let them in unless they have permissions to get there.

If you can, put a reverse proxy gateway in front of your private network. That's your best bet, because you have no inbound firewall rules. Make sure you update and maintain your PC firewalls and security patches. Stay up to date with that. The more you do that, the better your chances are of not getting hacked.

Risk #5: Using your own proxy software

Do you use your own proxy software? Maybe there's an older guy in your IT department named Joe that actually created a proxy software back in 1970s and 80s, and you've been using it ever since then. The older technology may or may not be giving you what you need or what you think you're getting, but yet people get complacent by saying, "Hey, this has been working this way forever. I'm not really going to question that."

I'm here to tell you, you need to question that. Check it out. Are the configurations correct? Do you have inbound and outbound ports? If you have an inbound port, there's a vulnerability. Use modernized proxy, reverse proxy technology. Take advantage of it. Secure your network, lock the door, put a bouncer out front. That's what we're talking about doing. Control who can get in and get out of your system. Maintain control of that proxy within your private network, not in the DMZ. That way, there's nothing in the DMZ for someone to get access to. It's literally just a pass through. And again, try to stay away from those inbound ports into your private network. That always opens up a possibility.

Risk #6: Writing and maintaining scripts

Then you have to actually look at maintaining scripts. Okay, do I have scripts defined? Most times, companies are going to use those scripts, batch scripts, shell scripts, PowerShell scripts, JavaScripts, and they'll store them on the DMZ. When something happens, they'll do some kind of movement, or they'll do some kind of piece that exposes them. Internally, maybe you have them. And then you're communicating with your customers, and all of a sudden you're saying, "Well, this group works well. I'm just going to make a copy of it, change a few things, and then use it for another company." And then that grows and grows and grows. Next thing you know, you have 25, 30, 40 scripts out there that do exactly the same thing. The only difference between them is they're pointing to different customers. Now you have to manage every one of those. If one thing changes in your daily routine, you have 40 different scripts you have to check out and make modifications to, not to mention all of the personalized information to those companies associated to each one of those scripts.

Exposed passwords, IP addresses, DNS, URL. There is no centralized auditing. Tracking problems is an issue. Not to mention if you need to go back and look something up, an audit or report to do some kind of a compliancy reporting, not easy to do at this point. Use a centralized and generic role-based script solution. Create something that I can pass parameters into. Do the same thing for all customers. That way I can actually control it. Something that gives me automatic notifications when I have a problem and I'm moving data. If I don't successfully transfer, or don't successfully encrypt or copy or move, I'm pulling data that has nothing in it.

Give me the ability to identify these things, and generate my own handling routines. Not to mention log and audit everything. I've got to handle all of the compliancy and mandates pushed in front of me by federal, state, and local entities. I've got to know who picks something up, who drops something off, when it happened.

Risk #7: Using free, outdated PC applications

Do you use free and outdated PC applications? If you do, then that means you have to have a dedicated personnel who understands and knows that free or outdated PC application. If they leave the company, what happens? If it's free, do they know everything about that product? There's an assumption there that the free product actually handles mandates and compliancy regulation reporting, but you don't know that. Or maybe there's something missing, and you can't get access to it.

You're dependent on community advice reporting. Maybe a blog that you go read, because you need to find out if there's an issue with a certain problem you've identified. Now you're at the mercy of someone who actually puts a modification in place with that free software to handle that. Do you know for sure that that's really happening? Ways to get around that? Look at certified security software that has administration and training and education. People that will help you identify these issues and setups and transfers. Know that there's trusted. They have compliancy and mandate reporting. They're willing to give you that reporting, and show you that you can actually provide detailed logs of transfers. They're regularly updated, and they include feature rich product enhancements. They keep growing. They keep changing. They keep it volume evolving, because that's what happens in the IT industry. Things grow, they change. And that's something that we can provide.

Risk #8: Not having proper key and certificate management

Look at your key and certificate management. Do you have a key vault? Do you have command line access? These user IDs can be stolen if they're not. People can get access to your system. It makes your system vulnerable, and it compromises what you do if you don't have control of those keys in those certificates. Install a secured encrypted key management system, a key vault. Implement role-based and log access to the keys and certificate updates. Know who makes changes, or updates, or deletes. Provide centralized access for the communication. That way you know what happens. You know when something goes in the door, out the door when somebody authenticates or when something's updated. Know what's happening within your system.

Risk #9: Lacking internal security controls

Do you lack internal security controls? Most companies will overlook them. They don't think a whole lot about them. Customer sign-on's. Do they have allowed IP addresses? White list, black list. I've got IPs that I literally don't accept. Is that global? Meaning I have to define that for my whole system, or can I do that with a specific user? Maybe you have employees that you want to be able to get to your system and upload and download, but you only want to do it when they're within your company IP range, not when they're sitting at Starbucks.

Can you control that? The brute force, DOS attack, malicious users, those things. Can you control those situations? Can you get granular with your cybersecurity? If someone signs onto your system, I can provide a folder that they can only list and download from. They can't do anything else. Can you get to that level with what you're doing on your FTP protocol? Can you secure your infrastructure? Can I control what they can do when they sign into my system? Yes or no? That's what we're looking for.

Risk #10: Not securing your system with the right permissions

So the question here is, do you think this is really going to affect you? Yes, you are vulnerable if you're using FTP. It is a vulnerable protocol. Like the old saying says, just say no. Don't use it. Use SFTP or FTPS, HTTPS, something that controls what you're doing, and how you're doing it.

GoAnywhere MFT Overview

So now what I want to talk about is just kind of give you an overview of what GoAnywhere can do to help you with this. GoAnywhere provides a gateway. We do give you that service to put into a DMZ server that allows communications to come into your system with no inbound firewall rules. There is no user IDs, no passwords, no keys, no certificates, no data, nothing is stored in the DMZ. Everything remains in the private network.

Access is controlled via the private network. Data is in the private network. We allow somebody in to pick something up or drop something off. On top of that reverse proxy, we also allow Round-Robin load balancing, which means we can handle high availability and faster throughput. So there's lot of things you can take advantage of here just by securing the front door of what you're trying to communicate with. Are there alternatives to FTP? Sure. GoAnywhere provides an agent. An agent allows you to enjoy centralized control of remote file transfers and workflows. That means I can install an agent internally on a server that I moved data to and from internally all the time. I can install one on a remote location, even in the cloud.

Now I can actually execute, monitor for files, look for information, transfer information to and from those folders on those remote agents, either internal or external, and I can do that securely. So now when someone uploads a file to me on their inbound folder that they always connect to me with, I could literally be dropping that file onto another server in a remote location in another state, if they actually connect to me via the agent. I can monitor for files in that remote server, pick them up, bring them back up to the corporate office, combine them with other locations, and then that way I have daily sales or daily inventory. And I can maintain that through that communication, without having to use FTP or SFTP. A lot of companies will use FTP in these types of scenarios. Guys, it's still not secured, but an agent will actually secure that communication, even inside your private network.

Secure Mail is an option. Instead of just putting a spreadsheet into an email and sending it through Outlook, even if it includes secure data, Secure Mail will allow you to actually take that document, upload it, store it in an encrypted location, generate an encrypted path back to that document, password protect it, and also put a limit on the number of downloads and the number of days it's available. That way, the recipient or recipients, if they send it to multiple, get a link back into your private network to pick that file up. We log everything about that connection. When they connect, if they download, was it successful, how many times they have left password access to that link. All of this is logged. We know what's happening. You can't control that if it's going through exchange.

The side benefit there is also, we only upload the file one time. And we don't care what the size of the file is. So if you have a one gig file that you need to send to 20 people, most of the time your exchange admins are not going to let you do that. So I can literally control that through Secure Mail, and make that happen. This also includes an Outlook plugin. That means I can integrate this with Outlook 2010 and above. Then I can type an email like I do any other day, sending an email to and from customers or trading partners or employees, but I can actually click on an add-in button to associate that directly out of Outlook. Ways that I can take advantage of that.

Another option we have is called Secure Forms. This is a way for me to actually request information from a customer or an external company through a web client, and then upload files, request metadata around that particular upload. Name, address, email address, phone number, zip code, account number. All of this information using HTTPS is a secured communication transfer. The quick and easy way to make that transfer across. Now I can actually automate movement of that data behind the scenes. I can take the account number they gave me, and compare it against the database table and validate that they know who they are. The name matches, the account number matches, before I accept the data. Again, with everything being secured. This also opens up the door for you to be able to utilize SOAP and REST requests. Meaning you can actually have a consumable web service through GoAnywhere. They can connect to you with a REST poster, REST get, and basically provide this information through automation, through HTTPS. Multiple ways to make that happen.

Q&A

So with that being said, if there's any questions, it looks like we have a couple here, [Brooke, 00:35:06] is that right?

Brooke: Yeah, we've had a few come in during the webinar, so as a reminder, if you do have questions for Rick, you can submit them through the Q&A pane in the bottom right of your screen, and we've got a couple minutes where we can speak to those.

Rick: All right. It looks like the first one is, "In your opinion, which of these 10 risks would you recommend addressing first?" I still stick with the idea of my first mitigation here is to get rid of FTP. Use SFTP, use FTPs or HTTPS instead. That's just a global definition there, but make sure, if you have the option, get off of FTP. There's so many vulnerabilities there that you have to watch and mandate and control that you really don't want to be involved with that.

"Do you guys do live product demos?" Absolutely. We'll be glad to help you with that. You can make a post or comment there, contact Brian Pick, who will be glad to help set that up, or contact with a sales rep or a manager to get in touch with you and actually talk to you about demos, what areas you're having issues with, or that you have questions about. We'll be glad to demo the product for you, and actually show you how it can benefit your company.

Any other questions? Anything else I can help answer, or does anybody have questions about? I guess not.

Brooke: So we'll give you guys a couple more minutes. If you have questions, go ahead and type them in. If you are new to GoAnywhere, we do have a free 30 day trial on our website, and you can download it, try out the product, see if it's right for you. We've got contact information on the screen, so again, if you have questions or are interested in a demo, you can email us at that email, or call us at either one of those numbers. And then if you do have questions and you don't want to ask them now, there will be a survey that pops up after the webinar, and you can plop any questions in that as well. It's helpful for us to hear what you're wondering about.

Any other questions at this time? Just monitoring the window here, Rick. All right, looks like we're good. So thank you guys again for joining today. Really appreciate your time. We'll let you get back to your day, and if you do have questions that weren't answered, we'll follow up after the webinar. Thanks again, and have a great rest of your day. And thank you, Rick.

Rick: All right, take care guys. Thank you very much.