Replacing FTP Scripts with Managed File Transfer

Angela: Hello everyone. Thank you for joining today's webinar on replacing FTP Scripts with managed file transfer. Today we will explain why using FTP and other insecure manual methods is a threat to your organization's cybersecurity. We hope you find the presentation helpful. I'm here with my co-host Dan Freeman. Dan, are you there?

Dan Freeman: I am.

Angela: Excellent. Before we kick things off, I'll remind you that the event is scheduled for an hour and if you need leave or drop off at any point, we are recording the event and we'll send the link afterwards so you have it. You can feel free to ask questions throughout the presentation as we'll have team members online to answer them, and we'll try to answer a few verbally at the end as well. Finally, a survey will display at the close of the presentation. If you fill that out, it will give us good feedback on what parts of the presentation were most helpful. And you can also reiterate any questions that weren't answered on today's call and someone will get back to you shortly.

Alright, here's our agenda for today. We'll go through the context of replacing FTP Scripts with managed file transfer in addition to common issues organizations have with homegrown solutions. We'll talk through why you should consider managed file transfer, and then wrap with a demo and introduction to GoAnywhere as a managed file transfer solution. And then if there's time for Q&A at the end, we'll go through that as well.

Alright, let me introduce you to our presenter. Dan Freeman has spent the last 10 years of his career in various security roles ranging from systems engineer to security officer. He currently serves as senior solutions consultant at health systems for the GoAnywhere product line. Dan, thanks for being here, and you can take it away.

Dan Freeman: All right, thanks, Angela. I appreciate that. And thanks to all of you for taking time out of your day to join us in this managed file transfer discussion that we'll go through. We do have quite a few slides to go through so I'm going to try to keep it pretty high level and flip through pretty quick. So we'll cover most all the solutions and mitigations if you will to the common pitfalls of traditional FTPs, various scripts, decentralization, weak, no encryption, stuff like that, that we'll go through in the slides.

Now usually, I like to kick things off by telling a joke or a quick anecdote, but today I'm feeling a bit bummed after reading about some more senseless violence described by the headlines on this morning's paper that I read. It read in bold print two hashes walk into a bar, one was assaulted. Yep, I know what you're thinking. I totally made that up. I mean, who reads the paper anymore? Okay, enough of that. Let's get going and get to some of the real content here.

Okay, most companies, it doesn't matter who it is, we're going to be exchanging information somehow, someway as you guys know, lots of different methods that we do this. In fact, it is predicted that data will pretty much double every two years over the next decade. Obviously, that's going to be an ongoing problem of how we actually exchange that data. A lot of things from like you see there, collaboration, very popular as far as the cloud type services are concerned. Your Dropbox, Google Drive, Box, things like that. Your applications, sometimes you might have some non-secure APIs that are opening up some security vulnerabilities within those applications sharing data back and forth.

Email attachments, being a former exchange admin many, many years ago, this one is a pain point for me, but for whatever reason, it seems like email is a defacto standard for communication. So we do need to tighten things up as far as management is concerned and actually transmitting potential PII, PHT, FTI, whatever the case may be, any kind of sensitive information so we can look at that as well. And then looking at those automated scripts, this is where they can be great, but sometimes they're going to be hard to either create, even when you do create them, maintain them things like that. So we'll dive into that as well.

Okay, some of the file exchange types, pretty straightforward, we do have the B2B or your server to server type interactions. This is going to be your automated unattended file transfers, no human intervention. I think of this, or a lot of people think of this as the command line scripting if you will, not really any of the human interaction of doing just that transfer from system to system. One that we definitely will talk about is going to be a little bit on the EDI standpoint. That's a good example of complete no human interaction, just computers talking back and forth to each other on certain protocols.

The other one, person to person or person to server, this is more of that traditional ad hoc type file transfers. We'll go over some of those examples as well. This is going to be like your email is a perfect example or even things like we are going to FTP or FSTP things out the door, so things like that as well.

Alright, some of these external exchanges, so we're going to see that top little picture on the right-hand side. We have some of those listed in red, your FTP email like we talked about, HTTP, those are the ones that we want to avoid. So we definitely want to leverage some encryption keys so we can get to the green-colored arrows, the HTTPS protocols. We'll leverage some TLS types of encryption using certificates. And then we have the SFTP to go beyond, I guess, what FTP is so we can actually leverage some SSHTs to encrypt the in-transit protection when those files are going across the wire.

Then, that's your in-transit, the next bullet point down there, we're talking about the end to end encryption, so we'll talk about not only the in-transit but also the encryption at rest. We definitely want things, when they land on our network, to also be encrypted to keep that protection even when it is at rest. I think a lot of times organizations do forget about this step. They definitely pay attention to the in-transit, but a lot of times we forget about that at rest encryption, so we'll address that as well.

And then to briefly mention the EDI document translation, this is going to be, again, where it's really, really coming down to a computer to a computer or a business to business communication that's automated to get that human interaction out of processing invoices or purchase orders, things like that. So a lot of time they can be some homegrown solutions that can be difficult to maintain or just some of those ERP systems or the other ones that are going to be quite expensive. So we'll definitely see it on the price tag.

Internal exchanges, we've talked about the application integration, but this can be anything as you guys probably know, whether it's between just network shares, whether you have FTP servers that you're doing internal communications, if you are opening up rest or soap, maybe APIs in the homegrown application, lots of different things. And scripts, as you guys probably have as well. You probably have a lot of internal scripts that are moving files depending upon what business function that we need to do.

And also, the different servers, platforms, and applications, this can also get a little cumbersome over time if we have the different OSes when you need to worry about a lot of different things. And then we're going to have things one-off and definitely not centralized, we're going to be all over the place when it comes to the different servers and applications that we are exchanging data with.

This one here, still external, but we're talking about the different locations, whether these are going to be traditional MPLS lines so it is acting as one entire network, so we can have the security piece there. Maybe we're doing just regular VPNs, or maybe we're actually doing things over the internet. Definitely things to consider there, not only just the security aspect of it but looking at that bottom bullet point there talking about the transmission of maybe large files. Maybe you're an architecture firm and you have CAD drawings and those big, big ... or maybe video files and you need to transfer these things internally throughout your network.

That latency maybe between those lines if you don't have high speed or are dumping a lot of money into your infrastructure as far as the lines are concerned, that can be an issue as well, whether or not files actually fully get across the line. Maybe they time out. Maybe they just take a long time. In any case, time does equal money, so those are some other things to consider as well when we're actually looking at some of the other considerations for internal exchanges of data.

Alright, some of the trends within security here. One of the things that I think is the biggest thing to note, well, aside from that first bullet point, the 1.7 billion records stolen in January of 2019 from data breaches, whereas fall of 2017 was 2.5 billion. So we can obviously see the increase of data breaches and methods on how they're actually getting done. And that completely could be a different webinar in itself, but it is just key to point out that data is very, very important in how we actually secure it whether it's transmitting over the line or actually housing it in-house and what we need to do.

The main trends let's look at, I think the biggest one to look at, especially when we're talking about MFT or the managed file transfer space, the human error. That's a huge one. We're going to talk about human errors as the point I wanted ... When you see that bullet point that says accidental loss or bad configurations, these are things that when you do get into a managed file transfer solution, we can eliminate those things because we're not actually having human beings involved in the actual transmission of these documents or applying the correct PGP key to send to a certain partner, or connecting up to the right SFTP server to make sure that we send it to the right place.

Actually, at a previous job, I did a lot of security for a healthcare organization. And probably one of our biggest bugaboos or at least potential breaches of information was actually sending it to the wrong person or provider. And usually, it was a fax, they just transposed the number. Sometimes it was actually FTPing it to the wrong person. The point is, we didn't have a nice MFT type solution to take care of those things to where users just knew, "Okay, I just drop a file off here and it automatically goes." Or better yet, we're actually just going to monitor for certain locations, grab files, and dependent on where it was, we're going to call a project to do the PGP encryption and then SFTPN to that particular person.

So that human element has always been a huge problem and it still is today. I know a lot of people, sometimes we talk about hardening your networks and using technology, but it always seems to come back to that human interaction. Automating those processes as best we can is always a good thing.

And then a couple of other of those bullet points there, the 2021 damage cost will be six billion. You'll see these figures anytime. Just Google anything about the breaches and the trends, and this is the common theme. What's really nice though is lately, people are, and when I say people, organizations are realizing the importance of this and so they are starting to dump a lot of money into it. I mean, the relationship to the cost in breaches to what people are actually spending on security used to be a huge gap. At least that's starting to close, so people are starting to recognize the problems and try and address them.

Okay, some of the common issues with our homegrown solutions, development of maintenance. Okay, so I think we all know developers are pretty sharp folks, but sometimes those processes that they create can be, I loosely use the word convoluted, and difficult to understand. So this can leave that dependency on a certain few individuals. That could create definite delays, maybe their availability, and could be expensive at that. Maybe it's not in-house and maybe you're actually contracting that out. Even though we do get those, they do provide some good scripts, good programs to do what we want. But sometimes maintaining them can prove to be a struggle just from the fact of their availability, from a cost perspective, other things like that.

A lot of things like outdated and misconfiguration tools, having to maintain your client one-off type apps to do these types of things could be really troublesome. It can be really a pain in the rear and, again, we're going to get away from that centralization type theme, which we'll talk about in a second.

Keeping up to the latest security, we talked about PCI specifically with using just one piece of it and the TLS version 1.2. We are a member of the PCI Security Council so we keep up to date on that. And we'll talk a little bit more about how GoAnywhere and the management of the actual application so we can make sure that we do keep up to date, again, getting back to that centralized thing.

Again, when we'd have all these things, one-offs, we have just things that are replicated, duplicated strips. Maybe people don't really understand the security protocols and how they actually work. Those are types of things that we need to make sure we're doing correctly so we are protecting our data how we thought we were. And again, definitely time-consuming to pull or rein in all of these different resources should we need to on the creation, development, as well as maintaining them going forward.

Okay, yep, we just mentioned this. Decentralization, I think it's probably one of the biggest things with the MFT space, and not having one is going to be that centralized administration or that single pane of glass to do all the different movements and data manipulation that you want to do. This is really nice. When you do have those various scripts tools and solutions, say you've got people that are using a free FTP server and then somebody else is using an open PGP studio to do their PGP Encryption. And somebody else is something else for some other fax or file transfer.

The point is, they're going to be all over the place, so keeping track of those things, not only from a maintenance standpoint like we just talked about, keeping them up to date but also from an auditing standpoint, which is another problem we'll talk about in a second. It's going to be really difficult to try and keep any of that under wraps and have a nice clear view of what's actually going on with your systems. It makes it really, really difficult when everything is one-offs and they're all over the place.

And then the management of service users and those mostly are the case in the systems, so we'll talk about that too when we jump into the demo portion. But user management is going to be a huge problem, whether it's administrative users, whether it's the users that connect up to your system to do SFTP or log into web client. Not having a centralized place is going to be really difficult, not only difficult to manage, but also can create security holes as far as creating different service accounts like we talk about here.

The integration to AD, I think that, obviously, if you have Active Directory or generic LDAP, most people have AD, but we do have ways to, or if you don't have ways to do that then again, you're going to have maybe individual user counts on your FTP server alone that are actually local server accounts. And then for another piece, it's just really tough to manage.

And then the encryption keys, which again, we'll talk about, those can be all over the place. Maybe you have your own PK environment for certificates, but you use open SSH, some type of server for PDP keys, and then maybe you generate the SSH keys using PuTTY or something else. The point is again, they're just decentralized. They're all over the place. Who's managing it? Who is taking ownership? How you audit and things like that are going to be a real pain in the rear.

Okay, limited automation capabilities, this tailors exactly to what we saw in that security slide when we talk about human interaction being basically our biggest problem when it comes to data breaches, exactly what's going on here. We definitely want to automate as much as we possibly can from things like reliability. So having that auto retry logic if we're doing an SFTP to a partner, we as the client, we want to make sure that we're doing some sort of due diligence to avoid network hiccups. Maybe their router reboots or maybe ours does. You want to have some of that retry logic so that we actually do have a successful delivery, or at least do our best to make sure that happens.

The workflows piece, we'll talk about, specifically projects, how we handle that. But that's going to be a lot of that stuff, when we want some sort of business function to handle, we can build out a project which is going to be a GUI-based, task-based type script. I guess the workflows and projects is the closest thing that we'll talk about in relationship to what traditional scripts are doing. Again, we'll jump in the product to show you how that works and how much easier it is to create and also maintain on those.

And then, yeah, operating with sensitive data, this is where maybe you're giving it into your hands of folks that when they have to send something to a provider or somebody and it's sensitive information, you're depending upon them to actually use the secure mail tool that they may or may not have first off, or maybe to actually encrypt the data with the correct PGP key. We definitely want to get those things out of their hands as much as possible. Or even internal things, we talk about payment of payroll and things like that. We want to make those as automated as possible.

And again, encryption and decryption as still a manual process, if it is, that's really a pain in the rear. That's again, human intervention, interaction I should say. So we can definitely handle that stuff and we'll go over an example of that as well.

Again, getting to the decentralization, we want to focus in on the audit notifications all within one tool so that we can know when things are coming in no matter who is sending them, no matter what protocol they're sending them by. We want to make sure that we're getting things and we have insight to everything that's going on. I know that lot of times we might not even have the audit data for some of our one-off processes or applications like we talked about just a couple of slides ago, so that's a huge issue.

And pretty if anybody out there has been on, I don't want to say the bad side, or the person getting audited, if you have things like that where you don't have centralized tools and auditing, basically you know that you have a huge wave of panic I guess is the best way I can put it when you know that an auditor is coming in to audit. And they're going to ask you for all the different things. They want to know I'd you know what's going on with your data at any given time. So that can be a huge problem, we'll put it that way when it comes to auditing and compliance.

But some of the other things as far as the alerts go. Maybe it's not so much even for auditing purposes. Maybe it's just for we have a certain few partners and we have to have files get delivered to them, obviously, for us to do business with them. Well, maybe a trading partner might dispute or is questioning whether or not a transfer was actually delivered. Maybe you have SLAs, worst case scenario I suppose. And they're questioning whether or not something was delivered or not. Auditing here, you can definitely go back and look at when that job or project was supposed to happen. You can actually track to see if it actually was successful.

Now granted, that's being reactive. That's if they actually tell you, "Hey, by the way, we never got something." We can actually handle that from the reactive side. But going forward I would actually say those alerts and notifications, we can definitely put that within some of the project logic to make it to where we're getting those real-time alerts so we can stay in the forefront of those things. So we can be the one doing that research before the customer says, "Oh hey, by the way, I didn't get what I was expecting." Or worse yet, we didn't deliver something on time and violating an SLA, which could cause, obviously, all kinds of problems, whether it's reputation being hindered or actually using business and then a monetary problem. Those are types of things that we definitely want to have those audits and notifications from a real-time perspective.

And the last one, this is a generic problem, I guess, but it is definitely a very viable one and very, very important one. A couple of slides on this one we'll go through. Security obviously is a problem. When we talk about encryption, that bullet point there, this is where, and I know that the title of the webinar was Let's Replace FTP Scripts. I think this discussion goes beyond FTP. I know that's definitely the step-child I guess of the protocols. No one likes the FTP. It seems to be an unclear text. So it's definitely a viable point, but this goes beyond that and talks about more on how we do provide encryption no matter what protocol we're using.

So yes, definitely let's get away from FTP if possible in the scripting. And let's start using that encryption that we'll talk about and specifically with our key management system that we have within GoAnywhere or just making sure that we are using encryption, whether it's in transit, which we'll talk about, as well as at rest. So we want to make sure. And not only are we using encryption but make sure we're using things that are not outdated like a SHA-1, for instance, that's been known to be hacked. So we want to probably use a SHA-2 flavor for an algorithm. Probably want to at least use AES, better yet if we use AES 256.

So it's not just encrypting things, but we also want to make sure that we're using the right protocols, or algorithms, or cipher suites that are actually going to make us properly protected. And if anybody out there has regulations to adhere to, you're probably getting mandated to use those certain protocols. So you'll know that. GoAnywhere will give you that opportunity to use that, just need to make sure that we use those.

Access management, the segregation of duties is another thing. Any type of auditing or regulation will have an access control type, I'll say family. But that's going to be things like we'll look at the administrative users. I think we have 18 different RBAC roles. So depending upon what that person needs access to in the system, they can be a part of a role or combination of roles. And we also have a custom role. Again, I'll show you that when we jump from the product. So you can get as granular as you want to give only the permissions that you need for that user that's going to be an admin user needs when they log into the system.

The deactivation, there's going to be a couple of other things in there that we talk about, disable accounts that there are certain inactive or failed login attempts, the time in between there. That's what we're talking about there. You'll see that a lot, repeating. Whatever regulation you're a part of, they're going to tell you that you need to safe lock for three null attempts. You need to safe lock to 30 days of inactivity, things like that. Those are things you can handle as well.

Strict password policy I think people hear about that all the time. MFA is something that's definitely getting pushed out more and more as an actual mandate. So we'll talk about the MFA. And just a side note on MFA, that is a really good way to probably get rid of 90% of potential breaches of your usernames and passwords. That multi-fact authentication, whether it's a text to your phone, an email, whatever makes it exponentially more difficult for someone to hack into your accounts. So MFA from a personal perspective, I highly recommend it as well.

Okay, from the architecture, I'm trying to be quick on this. This is anytime we're on the server side of things we definitely want to have some protection from the outside world into our private network. I think the next slide there's a better diagram. I'll walk through how we handle the gateway. But this gets from a traditional like this picture is depicting in the middle there the FTP server in the DMZ. Traditionally, that's been the case and they'll house different folders on the DMZ or credentials out in the DMZ, things like that.

You're leaving yourself definitely vulnerable to that machine getting hacked. And you can have your data out there as well as not only your data but also some user credentials. What we would like to do from a GoAnywhere perspective or from a managed file transfer perspective, take that, take the credentials, take the data, take anything out of the DMZ. Just have that be a proxy if you will to forward do your authentication on the backend. The actual data is going to be housed on the backend private network. We want to get to that architecture. We want to get rid of things actually hanging out in the DMZ as far as some of your data or credentials are concerned.

So this one here talks about the architecture again, but also from the architecture standpoint, we'll talk about availability. We definitely want to make sure that our managed file transfer solution, whatever it is, we do have some sort of high availability. Usually, that's going to be in the form of a cluster, like an active, active cluster so if one node does happen to go down, whether it's the application or whether it's the OS it's actually sitting on, we want to make sure that we don't lose any functionality. So we definitely want to have that high availability built-in.

And then certain things like your prevent/denial service features or brute force attacks, if you're definitely listening on things like your SFTP 22s and 21 for FTP, 443 for HTTPS, those are going to be common ports that people or bots are going to be hitting and trying to log in. We can have those types of things built-in for an automatic IP blacklist, malicious username, things like that. So we want to have those as well.

And then integrity, has the data been altered when received by the recipient? Make sure we have some checksums in place. A lot of these things here, we talk about the CIA and I don't mean the Central Intelligence Agency, but usually, when we talk about security we're going to talk about the confidentiality and the integrity as well as availability. So that's what we're looking at here. A lot of people think of it as the confidentiality. They forget about availability, but that is a security concern. If it's not available, then you can't do work. Integrity or make it only available to the person that you want to make it available to. And then integrity, make sure things are not altered in route and people are grabbing things or some sort of man in the middle attack.

Okay, on this one here, we've gone through and I'm just going to wrap this up here. Protecting the data that's exchanged, this is going to be obviously making sure that we have that encryption in place, whether we're using PGP file level encryption, whether we're using the actual transmission protection. We want to make sure that we have those things in there, so it's a common need. You always hear, "We want to encrypt data in transit as well as at rest." So those are two things that we need to address, which we can do.

Secondly, we want to manage and control those file transfers from a single site or as we talked about, a single pane of glass. And again, for all of those regions we talked about, we definitely want to have that one place to do your auditing, your alerting, checking on things, all of those types of things to where we're not having to worry about one-off applications. And not only from an auditing perspective but from a maintenance perspective, we only need to update and keep one tool to the latest and greatest from the security perspective.

And then regulation compliance again, I think most people in the business, in some form a lot of these regulations are going to touch somebody somehow, some way. So a lot of this stuff here we can handle as far as regulatory compliance just because of the algorithms and cipher suites, the key exchange algorithms, those types of things that we have available within the product. We need to make sure that we're using those so that we can maintain that regulatory compliance should we need to.

Okay, so why managed file transfer? These I can fly through because I think we've covered that. Secure file exchange management, I think we've covered that. Centralized admin, absolutely, you want to have things a single pane of glass, all in one place. Full traceability and control, again, that gets back to that auditing, which we'll go through. And automation, absolutely, we talked about that.

On this slide here, it goes over the overarching things that go on with GoAnywhere. I think on this one we can fly through this and just talk about some of the different pieces here because in the actual live demo I think we'll cover a lot of these things, so we'll just fly through this. I'm just looking at the time here. Okay, and here the MFT solution unified web base again gets back to that centralization thing. Ease of use, one thing I do want to point out there and we'll look when we jump into the product. Easy to deploy, update, upgrade, things like that, it's unbelievable easy to manage this application. It's a Java-based app. It doesn't get its hooks in the OS. That's why we can be OS agnostic. But also, you don't have to tinker with the registry and things like that. It's really easy to install, upgrade, create clusters, anything like that from a sysadmin perspective.

From an actual workflow perspective, creating the business functions or what we call projects, synonymous to what your traditional Scripty is doing. It's unbelievable easy. It's a GUI project designer. It's task-based and we'll walk through a common project to show you how that works. Cross platforms just like that, we talked about the application we can put on any OS and it doesn't matter. The cross platform is nice because now you as a sysadmin, you can choose whatever OS you're comfortable with. It's not going to behave any different no matter what OS it's on.

And then the extensibility, this is more towards I think the flexible pricing configurations. This goes to we're a modular type application so you only pay for what you are going to use. And I think beyond that, which is nice, most everything in there is going to be a perpetual type license so you pay for it, you own it, and you just pay maintenance from there on out. You can have unlimited users, transfers, file sizes, stuff like that. So we don't ding you on the way you use it, which is frustrating.

Server connectivity, we'll talk about this when we jump into the product as far as how resources are concerned, but this is another good way for that centralized administration. So not only are we going to have that managed file transfer solution, in our case GoAnywhere, but now we can reach out to other servers and services to leverage their functionality to bring in-house to GoAnywhere to now have all that centralized. We'll talk more about that when we jump in.

Cloud application connectors, a lot of those different ... we talked about Box, Dropbox, SharePoint, a lot of different cloud connectors. I think we have, I'm going to be wrong because they update this all the time but probably somewhere around 37-sh, 40 different cloud connectors. But in essence, this is us connecting out to different cloud services. And we're providing an easy, again, task-oriented drag and drop to do certain things, where, in the background, it's going to be all of the rest ATI calls that you would normally do if you logged into say Dropbox and you uploaded a file. All of that's going on unbeknownst to you behind the scenes. The same thing with GoAnywhere, we make the connection to a Dropbox or whoever. And now you can do automated projects or scripting if you will in GoAnywhere. So you can have again, more centralized management.

Commands and APIs, we do have free APIs out there, your GoAnywhere CMDs or you can leverage other applications to call projects within GoAnywhere. Or maybe you want to make things web services or SOAP and REST enabled, we can use web service type calls to call projects, things like that. So when you're actually calling those things like we mentioned there, override variables, run interactive batch, those are things that we can pass in those parameters at run time whether we're going into our commandments or open APIs that we can have available to us.

Here, I think we covered most everything on this. I'd say encryptions and the key management systems, we'll run through that when we jump into the product here. I think we can skip over a lot of those. Here, the customer portal is one to point out on the ACTPS web console. Should you have a ACTPS web interface for people to log into, you can customize it with your own logs and backgrounds and stuff like that so it looks like it's a custom page.

Or even if someone was using this for multi-tenancy and they wanted to have different listeners and they could provide or apply those different web client brands to each individual ones depending upon the URL and then can look like it's their own page as well, so kind of cool as well.

The two-factor authentication, we'll definitely jump into that, things like you can use a radius server like RSA, Secure ID, Google Authenticator, Duo, anything that can support radius, the protocol. Or we have things like a couple of TOTP options, whether it's the traditional TOTP like Google Auth, or Duo, or Microsoft authenticator apps on your phone. But we also have one that's built into GoAnywhere so you don't have to really on a third-party app, which you can send an email. Everyone knows how to read email. Or they'll send a six-digit random code or SMS should you have an SMS server and we connect it to GoAnywhere. You could have people get a text should you want to do that from a two-factor authentication standpoint.

Okay, this, I think is the last slide. Then we'll jump in the product. But for this one, I think for most IT professionals, finding credible third-party evaluations is critical when researching new software. Most of the time you want to most comprehensive honest information you can find to decide if that solution is right for your organization. For the managed file transfer market, analysts and third-party reports haven't always been easy to find. In fact, it's been difficult to find. But while file sharing products may call themselves MFT solutions, many lack the security controls and detail auto trails for compliance requirement.

File transfer encryption automation and auditing are all qualities of a standard MFT tool. Centralize all in one location, we've talked about that a lot with the need for this type of solution growing in leading organizations. This depiction here is Info-Tech Research Group. They released their 2019 managed file transfer category report with scores of the leading vendors based on customer reviews. As you can see, we did get the number one, the leader quadrant in the upper right-hand corner. If you guys are familiar with the Gartner quadrant, this will make sense to you. And this is easily readable. The point being is the further right and the further high you are, that top right-hand corner, that puts you in that leader category. So I guess the number one per se.

I know they're about to release an updated version of the report based on the last six months of data, which is good for us. Obviously, we're still in the number one position, so I thought that's really cool. We'll have this new version of the report available soon. But anyway, you can see the report for yourself, website, downloading it. I think it's on the GoAnywhere.com/info-tech/. We'll probably have that information after this is over as well. Oh, it's actually down there at the bottom.

Anyhoo, alright so let's jump out of her and let's look at a couple of scenarios that are going to be common to what we've been talking about. Obviously, we could go on probably for hours to go through a bunch of different scenarios, but I'm going to grab a couple that I think are pretty common. But before we do that, let's get some general knowledge of what we're looking at here. So this is going to be a web-based portion to get into the admin console so you don't have to download any clients to actually manage GoAnywhere. It is a Java-based application like I talked about. You can pretty much use any browser. I'm using Chrome, but you could use any browser you want to log in here.

The first thing to point out, we talked about the admin user roles, so we do want to have that job segregation of duties. So the administrative users as you probably have guessed are going to be those users that you create to log in to GoAnywhere to do configuration, stuff like that. We do have some pre-built RBAC roles in here. I think there's about 18 of them. So you can give someone an RBAC role or a combination of a bunch of them. Or if you want to do the add role, which is pretty cool, this is where you can say, I don't know what we're going to call it, whatever.

The point is, let's say we want to have help desk users be able to reset web user passwords and manage we user groups, but that's about it. So I can say, "Okay, my subject is going to be web users, and here's all the actions they can do." Now, if they're a part of the wen user management group as the canned RBAC role, they would get all these things. But again, we want to be a little bit more granular. We don't want to give that much away, so I just want to give them the ability to reset passwords for web users. And then maybe let's ... Nope, let's do a subject. Yeah, and delete that one out of there.

And then also, we want to do some kind of management with maybe web user groups, so we'll grab that as a subject and say we just want them to be able to view them, that's all for whatever reason. So again, you can get as granular as you want with those admin roles, so it really makes it nice to do exactly job segregation duties and only give rights that they need.

Okay, the other types of users are going to be web users. For us, web users just mean those users you're creating to log into whatever services you're offering as for as GoAnywhere is concerned. So some people get tripped up thinking web uses just means the web client. No, it means any service you're offering from a GoAnywhere perspective.

Throughout this discussion, I created one user called partner A. We'll use that throughout this theme here. But with the web users, we talked about the user management and login methods. Very quickly, you can do an individual or an application login method unique to GoAnywhere. But you can also define LDAP methods to where you can connect up to active directory. I think probably most pp are using the AD, but it can be any generic LDAP or any of these LDAP environments you see here. So after you configure those, now those folks can log into GoAnywhere, again, whatever protocol you're giving them access to. And they can use their LDAP account username and password. So you can manage those users in AD and not have to worry about it here within GoAnywhere.

A couple of other things of note, you definitely want to be able to give them the rights that they want to have. This user has HTTPS and the SFTP rights. These are all going to be dependent on the ACTPS client, which we'll look at here when we log in. And then the folders, when they log into GoAnywhere, depending upon what service it is, SFTP, HTTPS, it doesn't matter. Where do they physically have access to? So you can decide where they're physically going to go and then the actual permissions that they have.

Okay, let's go and just look at very quickly the services that we offer, pretty straightforward. An ACTPS web client, FTP, which we frown upon, FTPS, SFTP, and then we've got a couple of proprietary listeners as well. We'll hone in mostly on the ASDPS and we'll talk about SFTP. Again, we could go on for hours on a lot of this stuff, but we'll just focus on those two.

So what makes ACTPS? What makes SFTP? We definitely have to apply private keys to encrypt that traffic. So how we do that is we can mosey on over here to the key management system. And this is where we can manage those keys. Whether we're creating them from scratch, we can manage certificates, SSH, and PGP keys. So if you're importing, great. If you already have a certificate you can import it, or you can create the certificate right from here. You can actually generate the certificate sign and request. Go to go data thought whoever, pay the money, get it signed, bring it back. Import, see reply, and now we're good to go.

So now once we either import or create our private keys, we can now apply them to, in this case, the ACTPS listener for certificates and the SFTP server for our unique SSH keys. So we've got those things, we can manage them right here within the product. We'll look at PGP keys when we jump into one of the examples here in just a second.

Okay, another common theme, we talked about those resources, this is us connecting out to all sorts of different servers and services. So now we can leverage those to bring them in-house into GoAnywhere. I'm just going to cover a couple. Again, there's tons of them out there. But pretty common ones, network shares, which we're going to leverage. This is something where you can connect out to a different network share throughout your environment. In our case, it's going to be the origination point for a folder that we're monitoring to see if there's files to grab to send PGP encrypt and the SFTP out. But this can be anything that you want to do as far as connecting up to di network shares.

And then also we've got an SSH server, and this specifically will be for SFTP that we'll use in our example. But to dd those, it's pretty straightforward. You're going to put in your information. And then one of the things, just a quick note here. This is going to be our retry logic within the actual SFTP server connection itself, so this is us doing that due diligence that we talked about earlier. So we're going to test to make sure that it actually connects. If it does, that's great. Now we can leverage this actually in our projects. So okay, we were good. It actually connected up.

So now that we've got our resources defined, and I know I just covered a couple, but we'll define those resources so now we can actually go into those projects and actually use them to do whatever it is we're trying to do. So very quickly, I'm looking at the time here. We've got about 18-ish minutes. We'll take a scenario where you have internal employees, obviously. And maybe you guys are sending files to, and we're going to say partner A. Partner A is going to be our person we're sending files to or getting files from. And partner A is requiring you to PGP encrypt those files before you send them. And they want you to use the SFTP protocol to actually put them in a directory of their choice.

One of the first things that we would need to do is, from an encryption standpoint, partner A at some point, since they want us to encrypt this using PGP keys, at some point they would have sent us their public PGP key. And we would get that, and we would just import it into our key management system, specifically in our PGP key area. So let's assume we did that. Hopefully, we did this already. I think we did. We've got a partner A PGP encryption key, so that's them sending it to us. We imported into our product, so now we have it available to us. So we can now use that key to encrypt files that are being sent to them.

Okay, what we're also doing is, for our users, we're saying, "Hey, users, there's a folder out on some network share, whatever the case may be. I just want you, if you need to send files to partner A, I just want you to dump them in this folder. That's all you have to do. You don't have to worry about PGP encrypting. You don't have to get an FTP client to SFTP it to them. You don't have to worry about any of that. Just dump it in this folder." So we'll assume that, and that's going to be where we can use a monitor, which is going to do just that, monitor for a certain folder. In this case, it looks like it's a partner A outbound folder. We're going to monitor for anything. We don't care what comes in there. We're actually going to do just if the file exists.

We're going to check it every 15 seconds, which is a high frequency, but for purposes of the demo so we can see it action. When we do get a hit, whether it's one, whether it's 100 files, we don't know, we don't care. We need to call this project that's called partner A, SFTP that you haven't seen yet we'll get there in a second. And we're going to pass in whatever it is, if it's again, one, 10, five, 100, whatever, as a file list in a variable call file. So with that in mind, let's cancel that there and let's go to the actual project that's going on. And let's go down to partner A, SFTP.

So this is what we talked about very briefly as far as projects. This is building out that business function, similar to what traditionally people we're doing via Scripts, or Python, or Power Cell or something. They were using something to do this process. This is where I was talking about, it's a nice GUI interface. You just drag and drop the task that you want to do into this project outline, define a few things, and then will go step by step depending upon what we want to do.

So very quickly to go through what we were doing here, this first task is going to be a PGP encrypt task. So we would just grab that PGP encrypt task, drag it up in here, and drop it in there which I've already done. What are we going to do? How are we going to PGP encrypt this task? Well, we're going to PGP encrypt it with that partner A PGP key that we imported into that KMS, so now it's there. And what are we actually PGP encrypting? What's the actual files? So this is where that monitor that I just showed you, it was monitoring a certain folder, it was checking every 15 seconds when there was any file, we didn't care what it was. When you get a hit, I want you to call this project, which is now going to take that file list and encrypt them in this first step. So that's where this input is coming from. There's that file's variable that we defined in that monitor.

So now, again, we don't care if it's one, 100, it doesn't matter. We're going to take all of them. We're going to PGP encrypt them with partner A's public PGP key that we were given. And then we're going to take those PGP keys, we're going to connect up to, and I'm sorry about the name, I should have called this partner A. We're going to connect up to partner A's SFTP server, and then we're going to do a put. And what are we putting? We're going to put the actual PGP files that we just did in this step up here in whatever the destination directory is. We just had a test one here.

And then we're going to archive or use a copy task, and we're going to copy those original files that came out of that folder monitor. We're going to put it into an archive directory. And then we're going to delete out the original files that we got from that monitor because we dint want that monitor to process those same files again. All of this is going to happen again. If anything goes wrong we talked about keeping up to date or real-time alerting if things don't happen the way we want them to. That's what we're seeing by this errors module. And where that's defined is it's just saying, "Hey, if anything goes wrong in this main module, which is every single task in here, so if anything goes wrong in here, I want to switch the focus to that errors module that I created." We'll call it errors.

So it'll switch the focus to this module, which is just sending an email basically saying, "Hey, by the way, the system job name," which is going to be the project name, "failed." And we're going to attach the system job log which would just be the text depiction of what actually happened. Okay, so let's just jump out of here. That's fine, I'll just save that.

So let's see that in action. We're going to play the role of the internal employee. Here's our partner A folder. We want it to be outbound. That makes sense. So let's just dump a file in here and we're just testing that text. Oh, that monitor, I probably had it too fast. Oh, yeah. I didn't even get a chance to rename it the monitor picked it up so fast. In any case, it grabbed that file, it shipped it on its way. It deleted it. It put a copy of it in the archive folder like we wanted it to, and it's actually sitting in that test directory on the SFTP server at partner A. So that's a quick example of what it's doing. We'll look at the log file here towards the end to see the actual PGP encryption step, actually sending it on its way, and then making the archive and sending it here. So one way that users again, they just dump them in there. They don't know the wiser. The monitor picks it up, calls the project. It PGP encrypts. It SFTPs it to the partner and we're good to go.

Scenario two, let's say that partner A needs to send files to us as well. And all we're doing is okay, we're going to create a web user called partner A. I'm going to give them access to our HTTPS client so they can actually go to a web client and log in. And then they can just do some drag and dropping of the files into a folder that I have created for them. I'll show you in the backend where this is going and how this works. So in this one we've given partner A, we've sent them username and password, whatever their credentials are. Oh, and by the way, we're also going to use the TOTP option. Let's just jump there real quick.

You go to web users and let's search for partner A. We did set for the HTTPS protocol for them to use a TOTP option as far as the authentication is concerned. So when they go here, we're going to sign in partner A. Oops, enter the right password. They're going to broadcast it. Okay, so this is going to be our TOTP. So what you didn't see beforehand, if this is the first time they're logging in, they would get that QR code, which you may or not have seen before. You'll take your phone, whatever app you're using, I'm going to be using Google Authenticator which obviously, you can't see me doing right now. But it is giving me a six-digit code, so I'm going to put that in real quick. And this should authenticate me. Okay, great. So that actually worked. Now, you can use Microsoft Off, Dup, Google Off, any of those apps to use that TOTP.

Okay, so this is partner A and he knows when he logs in he's just going to send things up to the upload folder. So let's just grab a folder or a file. Let's just grab this to-do icon, whatever this is. Let's upload that file. And then what should happen is what we want to do is when partner A uploads a file, we want to know about it right away. So what we have done is similar to what we did from the monitor standpoint. Now we're doing something called triggers. So we're actually setting up a trigger that's saying, "Hey, by the way, when the web user partner A uploads a folder to that upload directory that he just did, I want to ..." In our case, what I have set is just saying, "Hey, I want to send an email to somebody."

So this is just saying a file gets uploaded successfully. I don't care what service or protocol. I'm going to say any. My condition is if the event username, which is web user equals partner A, then I want to send an email and should have all this information. The from should be partner A. The from email should be partner A's email address. The two is going to mine and then upload. It's going to be upload from the organization has arrived. So we should see in here 10:50. Yep, that just came in. So it says yeah, there's our partner A, who it came from. It says upload from partner A organization has arrived. And here it has some other information.

So this is me getting an email that says, "Oh. Hey, by the way, partner A just uploaded a file." So then I can say, "Oh, great." And then I've got to do what I've got to do. Now granted, those triggers can do other things as well, not just email alerting. Maybe you want to actually call a project instead. So it can do what you want it to do in an automated fashion. I just wanted to show you that you can do this as well, just a simple alert. But you can call a project to do all kinds of more intricate details should you want to do that.

The last thing that I wanted to cover really quick, at least from a scenario perspective, is email because I know email is again, that common thread or common use of communication. So let's use partner A again. Let's go back to the web client and let's say we've given him access to secure mail. And we want to take that file he just uploaded and maybe we want to send that to somebody. So we can just drag it right into the compose section there and it'll pull up my secure mail. I'll just send it right back to myself so we can see it. Message from me. We'll say read receipt. Okay, sounds good. Let's just go ahead and send it.

And you can limit the amount of downloads. That's finally to 10. I'm going to allow him to be able to reply even though he's not a user on the system. Let's just go ahead and send it. So from the recipient standpoint what you would see usually is going to be a URL protected link instead of the actual contents of the email. And let's see here. So we got an email that says secure delivery. You got an email from partner A. It looks like he attached a file, a PNG file. So let's go ahead and download those files. It'll send you, in this case, it's going to send me here. That's the web client to actually download as real as read the message because that's going to be encrypted as well. So we can download those attachments. So this maybe was PHI or something sensitive. So we're going back to the HTPPS protocol to pull those down. So essentially the recipient is going to log back into your network and download the email via HTTPS.

What's also cool is now partner A, one he's going to get a read receipt saying oh, he actually opened the file. But he can also go to the sent items and go through and say, "Oh, you know what? Did he actually get the email?" Well, we can always go to activity and say, "Oh, yep. He received it and he actually downloaded the attachment." He downloaded it once, he's got nine more remaining. So a little bi of self-repudiation from a user's perspective or a sense of comfort knowing that they actually got the email that you thought they were supposed to get. And you can see their actual actions here of exactly what they've done.

Everything that we've done, and I'm cutting short on time here, we can go back to the admin console and go through a lot of the auditing. This is something again, that's a very centralized theme. We have to have little of that auditing in one place, so everything that we just did. We did a lot of things via the web client, so we can jump into HTTPS. And we should see all the different stuff that we did as far as partner A is concerned. So we can see that we actually logged in. So look here, it says, "Hey, by the way, partner A tried to log in. He passed the first-factor authentication. And okay, yep, it looks like he actually logged in using a second-factor authentication.

When he logged in, he uploaded a file. And it looks like he actually kicked off a trigger, which we saw in action. So this is going to be something where you can actually look at that log so see okay, cool. Not only did he upload a file, but that file upload, it sparked a trigger. Now we can go into that trigger to see what that trigger actually was doing. What did it actually do? What different directories did it do? So we can look at all that information.

Getting back to the projects, I know that was one of the first things that we looked at, we can also look at each individual job log from each individual project every time it is run. So in this case here, I think this is probably one of the first times we've ran it. We can look at the actual job log to see what that looks like. And so we can go through and see that okay, great. We were looking at that monitor. It grabbed, it looks like just one file. Yep, one file and it called that project, which first, it's going to do the PGP encrypt.

It's going to encrypt it using partner A's public key. Everything looks good. Okay, great. Now we're going to connect up to their FTP server and we're going to go ahead and upload those documents. Great. We close the connection. Now we're going to make a copy of it and put it in our archive directory and then delete the original so we dint process that again. And by the way, oh yeah, we looked at the archive. So there's our archive. Okay, in the interest of time, I apologize. That's what I wanted to show. I'm going to pull the deck back up for Angela here to cover one last slide I believe.

Angela: Great. Thanks, Dan.

Dan Freeman: Mm-hmm (affirmative).

Angela: We do have just a couple of minutes for Q&A. But before that, I wanted to thank everyone for joining us today and let you know that we're happy to answer any questions that you have if you'd like to contact us. And all of our information is right there on the screen, so feel free to reach out if you have questions that you'd like to submit. For those who need to drop off or have already had your questions answered, thanks for joining and we hope you have a great day. For the rest of you who'd like to stick around, if you'd like to submit a question for Dan to answer, you can do so in the question pane there in the bottom right-hand of your screen and we'll watch for those to come through.

Dan, there are just a couple of questions here since we do have just a couple of minutes. One of them that came through, what's the difference between SFTP and FTPS?

Dan Freeman: Yeah, both are going to use the FTP protocol. SFTP is going to leverage your SSH keys for the encryption on that transfer. SFTP is going to be just one channel, which is why I think it's easier to manage, meaning the command channel or the channel that's actually going to connect and do all of your handshaking and things like that. It's going to be the exact same channel that's going to be used for the data. So it's pretty easy to use.

FTPS is going to leverage your SSL certificates for that encryption on that channel. FTP, on the other hand, is going to be a traditional type FTP where you have one channel for the handshaking and negotiating and then a separate channel for the data channel. So those are, I guess, your differences as far as the security aspect is concerned. SSH keys versus SSL certificates, I think it comes down to a matter of what kind of algorithms that you're actually using when you set up those keys, whichever one. It's from a configuration standpoint.

Angela: Okay, great. Thank you. And then one more since we have a couple of minutes. How can GoAnywhere make me compliant on various regulations?

Dan Freeman: Oh, yeah, let's do this. You can still see my screen, right?

Angela: Yes. Yes, I can.

Dan Freeman: Okay. Okay, so we talked about the different cipher suites, key exchange algorithms and stuff like that. It's important to do that encryption. It's important to do a lot of things. But how you actually apply them or the different cipher suites that you use is definitely a configuration item. So I would say we give you the tools. We give you the NIST approved or there's a FIPS 140-S2 compliance module. We give you the tools to be compliant, but it's definitely up to you on how you configure the application to make sure that you are compliant.

But one cool tool, actually just a side note since you brought that up, there is a security audit somewhere, a security settings audit. This is just one of the reports. And this is going to generate a PDF file. It goes through like 70, I want to say six-ish different controls within the application. And it'll tell you whether you, I guess, "pass or fail". If you fail, it'll give you mitigation steps on what you need to do in the application. And then we're mapping it to PCI just because that's the one we pulled up on the security console. This is going to be specific to the actual control within PCI, but a lot of these settings are going to be pertinent to whatever regulation you're part of. Yeah, that's [inaudible 00:59:46].

Angela: Perfect. Well, thank you so much for your time today, Dan. And thank you all for joining us. We hope you have a great rest of your day. And if you have any additional questions, please feel free to submit them via the information that we had on the screen a short while ago or via the survey here at the end. Thanks, everyone.