Meeting Compliance Requirements with GoAnywhere

Angela: Hello, everyone. Thank you for joining today's webinar on Meeting Compliance Requirements with GoAnywhere. This webinar will cover specific compliance categories you should be aware of, like HIPAA and the GDPR. What it means to be non-compliant and how MFT can help you comply with the proper regulations. We hope you find the presentation helpful. I'm here with my co-host, Dan Freeman. Dan, are you there?

Dan: I am.

Angela: Excellent. All right. Before we kick things off, I'll remind you that the event is scheduled for an hour, and if you need to leave or drop off at any point, we are recording the event and we'll send out a 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'll give us good feedback on the parts of the presentation that you thought were most helpful. You can also reiterate any questions that weren't answered on today's call and someone will get back to you shortly.

All right. 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 HelpSystems for the GoAnywhere product line. Welcome, Dan.

Dan: Thank you.

Angela: All right. Here is our agenda for today. We'll kick off with, what is compliance and the cost of being non-compliant? From there we'll go over various regulations, laws, standards, and frameworks, and what can you do to help ensure that you are compliant? And then Dan will launch into a demo about our GoAnywhere secure solutions, and we'll wrap up if there's time with any Q&A.

All right, Dan. With that, I'm going to turn things over to you.

Dan: All right. I appreciate it. And thanks guys for taking a little bit of time out of your day to take a listen to this conversation on compliance. Speaking of compliance, let's give the, I want to say, probably the Webster's definition of compliance; the act of obeying an order, rule or request. So, compliance is either maybe a state of being in accordance with an established guideline or specification. We'll talk about those as we go on. Or actually being in the process of becoming so.

So, software, for example, maybe developed in compliance with specifications created by some sort of standards body or accreditation organization, and then deployed by those organizations in compliance with maybe a vendor's licensing agreement or some sort of regulation they need to adhere to. The definition of compliance can also encompass efforts to ensure that organizations are abiding by both industry regulations as well as government legislation. So we'll see policies, regulations, rules, law, all those lovely words there. The point being, compliance is definitely a broad spectrum, and being so, being compliant does require an absolute holistic view and plan to be able to achieve compliance.

And it really doesn't matter what regulation you're in, we're going to see a lot of different laws, policies, regulations, standards, frameworks, that'll address compliance, and we're going to see a lot of overlap, can be very, very confusing, which ones to actually choose, which ones to adhere to. But we'll walk through those and give you guys the ability to see which area that you need to adhere to.

It being a holistic view, and it's encompassing a lot of things within your IT systems and policies, procedures, plans, things like that, brings me to the next slide here. This is going to be my quick disclaimer to this. This webinar is for informational purposes only and absolutely not used as a means to derive compliance in any desired area of business. Probably more importantly, it is definitely not being suggested that by simply purchasing software, such as GoAnywhere, that will automatically make you compliant in your respective industry. Now, what this webinar is going to do is go over some of the areas of compliance regulations, the laws, standards, frameworks that are out there, and what their general purposes are. And then we can briefly go over some of the features of GoAnywhere specifically that can aid you in your quest to become compliant, or at the very least, provide your due diligence in processing your data in a secure manner.

Now, to complete this disclaimer, I was actually going to start off the webinar with a joke to lighten the mood. I do that every once in a while, but upon further research, it does turn out that there are no compliance jokes, because compliance ain't no joke. Okay. Either that or the people that work in compliance like myself, we really don't have a whole good personality or very little, if any, sense of humor.

Anywho, moving on here. So what does it mean to be non-compliant? Here's a couple memes or I guess one meme in one picture. I think we can all relate to these, especially the one on the left. At some point, maybe you've personally experienced this situation or you've at least seen this on the highway, not being compliant. In this case, we are breaking the law of a speed limit, it looks like in this case, that's probably most likely what's going on there. So the cost of that, well, maybe emotional stress, that can be a cost, definitely a financial cost, most likely, getting a ticket. Maybe your insurance goes up. The point being is, we being out of compliance we're going to see some sort of consequences. And then of course, the one on the right. We all know what happened to Luke. I think he lost an arm. Obvious emotional stress, but there's definitely some costs when we're not being compliant, whether it's the law, speeding or not recognizing your father as who he is to be. So definitely cost for non-compliance here.

Okay. Let's look at some of the costs. And we'll talk about the penalties and fines here. Specific to each individual regulation standard or law that we'll go through, we see some different fines depending upon which area you are in. We'll talk more about these in a little bit more detail coming up. But just looking at the high level, PCI DSS which is going to be your payment card industry. So basically anything dealing with credit card information, we are found out of compliance and we are in that area of business, then we can be fined up to $500,000 per incident. So that's a healthy chunk. As well as $50,000 per day. As you can see, that could probably get very, very expensive if you are not mitigating your problems or non-compliances in a timely manner.

GDPR, again, we'll talk more about these and what they are. But the fines on those up to 20 million Euro, which I believe currently is approximately somewhere around US $22 million, or 4% of your worldwide annual revenue. That last bullet point, whichever is higher is that. It's either one of the two and the highest value. So those can be very, very costly. GDPR, as we'll see is fairly new, came out in May of 2016. So we haven't really seen a whole lot of that going on and the fines coming out, there's been a few. But yeah, we'll see how that one plays out as time goes on here.

HIPAA, this is one going to be dealing with our PHI or our Protected Health Information. These can be up to $50,000 per incident, up to 1.5 million per year. And there also can be criminal charges up to 10 years in jail. Now, there are some caveats with these bullet points. These aren't matter of fact, there are different tiers of HIPAA violations. I'm not going to go into those. But it basically is saying if it was accidental breach of some PHI data, you'll have a certain fine. But if it is actual proven to be malicious use and you knew you're doing it maliciously, that's where you're going to see those huge fines and potentially time spent in jail.

And then FISMA, or Federal Information Security Management Act, or as it's currently called Modernization Act of 2014, if we go out of compliance here, these are federal laws, we can definitely lose contract work. If we were say a contractor working with some federal agency, federal agencies will see federal funding cut, and they can get censured by Congress. So nothing light here, so those penalties can be costly.

Now, these are going to be the penalties and fines that you receive from whatever organization is enforcing these, but we also have non-compliance costs and something we talked about in a previous webinar, the data breaches, this is something that could happen, not saying it's going to happen, but if you are out of compliance, you're most likely not up to security standards, and thus another collateral damage or collateral costs by being non-compliant is not by the people coming down and putting fines on you, but maybe you get a breach. And that's where the fines are... not fines, but that's where your loss of revenue is really going to hit you hard once there's those data breaches. Probably one of the, I think a big one to talk about is like Anthem when they lost the 80 or so million records, I think. Towards the end of it after four or five years of the litigation, they end up costing them about $16 billion. So, nothing to shake a stick out there. Quite a huge loss.

So let's look at some of those regulations and laws that are out there. We talked about HIPAA, the Health Insurance Portability Accountability Act. This was brought about in 1996 as we look at that there. PHI just an FYI, I hear a lot of people talk about PHI and they talk about it as patient health information. It's not, it's just, the PHI acronym is actually Protected Health Information. That's more of an FYI. But what is protected health information, it obviously does deal with patient type information. But this is going to be any individual's past present future physical or mental health condition, whether or not they did have any services because of any kind of health care conditions, and any record of payment for those provisions of the healthcare to an individual.

The main point is, if any of this information that we talk about here individually identify somebody, that is where you're going to run into problems if there's something that we are not protecting properly. Now, I always I hear a lot of people talk about PHI as well like, "Okay, what's the big deal about PHI rather than a lot of people think about when they get their information stolen, they think of their bank statements or credit cards and things like that" that kind of immediate potential financial hit. But PHI is actually on the black market more valuable than any kind of PII. These users can use it to file false insurance claims using your information, your health information.

They can definitely be using it for blackmail. Especially it'll probably a lot easier if you get a famous person's information. They've got some things that they don't want people to know about on their, either their physical or mental health conditions or things that they've done. They can definitely blackmail folks like that. Again, this is also going to be information that most likely you can't change. This is stuff that you've done, this is something part of information of who you are. Whereas banking information, your bank statements, your credit cards, those are things you can put on freeze. Those are things you can even cancel. Things like that. Those are things that can easily, questions that easily but a lot easierly dealt with then if you get some of your PHI taken, basically your identity as a person to be a lot harder too. Mitigate those types of things. once you do get this type of information stolen from you.

The Health and Human Services or Office of Civil Rights, they are the organization that's responsible for enforcement of the Security Rule, which is basically telling people, "Okay, hey, I need to make sure that the organizations are being held accountable to protect this patient data. The CIA is not the Central Intelligence Agency that is actually for the confidentiality, integrity and availability. That's going to be a common theme anytime you're talking about protecting any kind of data. We have to make sure confidentiality, integrity, as well as making that data available to the appropriate authorized people. So we'll definitely talk about CIA anytime we're talking about these regulations.

FISMA. Okay, so FISMA is going to be our Federal Information Security Modernization Act. In 2014 they decided to change it from management to Modernization Act. The original one was written, I believe in 2002 for the Information Security Management Act. This is definitely going to be things for Federal Information, as the name suggests. So federal agencies, anybody that's actually responsible for processing, handling, any kind of Federal Information can fall under the FISMA Federal Law. This is a federal law. FISMA has divvied out or I guess delegated to the NIST, or National Institute of Standards and Technology. They're the ones that are responsible for developing the information security guidelines, or those standards that they need to adhere to.

They're putting out the minimum requirements for those federal agencies. One of the things that they're always going to see or you're gonna see very, very common, if you ever deal with federal agencies, or if you're a contractor for federal agencies or have federal information and you do fall under FISMA, the special publications is something that's going to be very, very familiar to you, specifically the NIST-853r4. I think revision five is coming out soon if it hasn't already. But this is going to be that 800 of those special publications, those are going to be documents that NIST puts out outlining security guidelines. That's not just for FISMA, they have special publications for cryptographic algorithms that are acceptable. They talk about your FIPS, your Federal Information Processing Standards. They'll talk about TLS best practices, this case, the 853, that's where they're really going to outline the different tiers depending upon the type of data that you have.

That 853 is a great guide if you don't know how to secure your data is very intense. Don't get me wrong. But it gives out a nice blanket, a whole holistic view of how to secure your systems in general. They break it down into 18 different, what they call security families; from physical security, to organizational to change management, access control, audit and accountability. But they'll break it down into a lot of different families with the different controls very, very specific. So they're very, very specific of what you have to do. And we'll have it from a minimum, a a low impact, moderate and a high impact depending upon what kind of data you have. So a great document, very, very intense, though, if you've never seen it before it can definitely be intimidating first looking at that. But in any case, NIST is going to be your organization pushing out or pumping out these special publications.

I put FedRAMP in here, it is definitely not law. But I did put it out there because it's kind of neat. It was something that came out, I believe that was... came out from the Office of Management and Budget or the OMB introduced us in 2011. So this is going to be that, I guess, the acronym Federal Risk and Authorization Management Program. So this was just an attempt to put together a nice standardized approach to security for cloud deployments. So we don't have to, recreate the wheel constantly for these different organizations to go ahead and do everything they need to do for those cloud deployments and being secure like they need to be, this organization put things out there so they can have that complete standardized cookie cutter type approach to those making the cloud deployments secure. So FedRAMP, again, not law, but a great program if you're definitely going to be using cloud deployments.

Okay, GDPR. As the name suggests, General Data Protection Regulation. I'll put a disclaimer out there or be transparent, I am not a GDPR expert by any means. But I think the G in GDPR general gives a good explanation of this regulation. It is very broad sweeping. The amount of data that is being covered under this regulation is quite intensive, and can basically involve anybody on the planet. As you can see, it was in May of 2016. And any businesses conducting operations in EU countries dealing with EU citizens data, or any organization does process that's covering data for any citizens in the EU nations.

So, let's see, if you think of something like Facebook, obviously, they are definitely not to pay attention to this. I'm sure they have EU citizens data out in their data centers in Facebook. So things like that, it's going to be interesting to see this one play out as well. It is fairly new. There have been a few companies that have gotten fine. Pretty big, as you can see down here, lower in the slide here. But again, I think it's gonna be interesting to see some of the revisions or some of the modifications that come to the initial GDPR regulation that came out, because I do think it's pretty broad and very subjective in a lot of cases. But again, fairly new. So we'll see how that works.

They have a European Data Protection Board. This is what reinforces it. So that website, by the way, I think will make this should be downloadable, or at least the recording. So, this website, it's kind of neat. It's just like the, not the FBI 10 most wanted list, but it's just a nice little website to see who's actually been violated or not violated. Who actually violated some of the regulations of the GDPR and some of those other news specific to the GDPR. So it's cool to keep up to date.

I mentioned the DPA. Again, this is a Data Protection Authority. This is in actual job title, this is somebody who has a DPA role. It is required to have a DPA assigned to your organization if you do fall under GDPR. Again, my transparency not being an expert in GDPR, but from what I've been reading and seeing, the DPA authority is definitely very extensive, very powerful role and I think the biggest reason why is, they're the ones that are going to come in and do some mitigation or investigation on things that have been complaints or potential breaches. And it can be very subjective. So it's, again, I think it's going to be interesting to see how this role, specifically the DPA role, and the GDPR in general plays out.

Fines so far, there's been a couple that have been pretty large, 123 million for Marriott. And British Airways got hit for 201 million, violating the GDPR. The main purpose, again, this is pretty high level is like most things we're protecting individual personal data and giving users control of their own data. I think that was one thing that was a little bit unique. Users now have the ability to decide where it's stored, how that data is used and the power to delete. So if they want that information deleted, they are required to delete that information. There was a couple of the high points of GDPR.

So getting outside of the laws and regulations, look at some standards. So we've got ISO 27001 and 27002 are the two that I picked out. The acronym always throws me off because it's not what I usually think acronyms are. ISO is actually International Organization for Standardization. So it's just to me as goofy. But in any case, this is also a worldwide standard, kind of like PCI DSS, which we'll talk about is the standard of national standards bodies. And these standards are carried out by technical committees. So, I think a good example like that is, so we'll talk about obviously the 27001 and 27002, but things like these technical committees might do other standards. So the ISO standards like 9000 series, specifically the 9001, it was something that I've dealt with in the past. But basically that was taking various aspects of quality management by providing guidance, tools, what have you for companies that want to ensure that they're meeting their customer requirements.

Key point on this one is that quality is constantly improved. And that got ingrained in my head a couple jobs ago because I was responsible for writing work instructions. And if you've ever written work instructions, maybe you like it, I didn't. They drove me bonkers. But basically it's having a quality management system, keeping your customers happy and always doing continuous improvement. So there's different ISO standards out there. That was just one example that they do.

The ones we're specifically talking about here, the 27001 and 27002, this is going to be those requirements for information security management systems. So this is going to be standards, these are not requirements for compliance. Now, having said that, on the next bullet point there, there can be organizations that require a business partner vendor to have this certification. So this is something that you can get certified. You'll see down in the lower right hand corner, just that graphic down there from 2013 to 2017, you can see the growth of people that are actually pursuing or getting the ISO 27001 certification. So the numbers are increasing quite rapidly. It's becoming a nice to have or something that looks really good, I guess, if you have that ISO 27001 certification. And potentially could be a requirement to do business with a certain individual.

The 27002 are going to be the actual security controls. As the breakdown goes, there's 14 security control clauses, 35 main security categories, and 114 specific controls. Sounds like a lot. Going back to like the NIST 800-53, I haven't looked at that currently. But I think again, there was that low, moderate and high impact, I believe the high impact there's over 300 security controls, specific controls you have to adhere to. So that's crazy. So the 800-53 is a pretty comprehensive security model if you want to definitely cover your bases. That's a really good one to adhere to.

On the ISO, GoAnywhere, just as a side note, we are actively pursuing our ISO 27001 and I should say certification, not really compliance there. I think certification is the better word there. So we're doing that as we speak.

PCI DSS, this is our Payment Card Industry, Data Security Standards. So this is going to apply to all companies that accept, process, store and transmit credit card information. The PCI Security Standards Council was created back in 2006. Basically there's four merchant levels, depending upon the size, amount of transaction and whether or not they've had a breach. So again, your Mom and Pop shops are probably going to be level four, whereas the people doing over 20 million transactions in a year, they're going to be on the level one. Those different tiers are going to mean different things. We're not going to dive too deep into that. Just know that they're there, but it's not just the amount of transactions, if you've had breaches in the past, you might get set at a different level as well. Kind of like insurance companies. You have a claim or two, they're going to up your ante, just because you have claims.

They just released the PCI version 4.0. I just saw this the other day. So, that came out November 13. So just a few days ago. 2019. The last one that I was actually involved with was 3.11, I believe, if I remember right. So yeah, that was cool. I got to read up more on the PCI 4.0 and some of the changes that came out with that. This does give a detailed outline of security controls. We do have a security settings audit report within GoAnywhere. I bring that up because it'll go through and look at different security settings within GoAnywhere. And it'll tell you whether or not you, we'll say, passed or not. If you don't, then we'll give you the mitigation steps to do so, specifically to the GoAnywhere application. And then we will also map it out to the PCI DSS section.

Now I will tell you right now, it's from PCI the latest before 4.0 is definitely not from a 4.0 so that's something that we'll probably have to look into or get that updated. But again, that's fairly new, obviously, November 13th, 2019.

Our last bullet point there, you may or may not know this. I know we talk about this, if you've ever been on a demo, we definitely talk about it. Being a member of the PCI Security Council, it just gives us that opportunity to maintain the latest updates, keeping up to date with again, the actual new releases that get popped out, just having that information from being on that Standards Council, which is nice to have.

Okay, let's look at some of the organizational frameworks. I'll try and be a little bit more brief on these, the RMF or a Risk Management Framework. This was put out by the National Institute of Standards and Technology. So NIST, again. One of the main, and I don't want this to be misleading, but one of the main special publications that is adhering to the specific risk management framework is that 800-53r4. Now, there's more to that but we won't go into terrible detail. But to give a little background on the RMF and what it is, it was originally adopted by the Department of Defense, I believe it came out to all federal agencies in 2011. But it's a set of criteria that dictate how the US government IT systems are to be architected, secured and constantly monitored. And I can't reiterate enough, constantly monitored.

Because there's basically six steps, and they go by categorizing the system. So you need to decide when I say the system, I need to say, "Okay, well, what parts of my system are going to be encompassed in this particular framework?" So, the GoAnywhere application would just be one piece of it. You probably have an email system that might be part of it, file systems, things like that. You're going to have to know the entire competencies system, so we need to definitely categorize the system and then decide what area we need to adhere to. You're going to select the controls that are applicable, there's obviously going to be things that are not applicable to you. You're going to implement those controls, you're going to assess those controls, then you're going to authorize your system.

And in turn that comes out as ATO or Authority To Operate. And this is granted by the agency you're working with. They're going to say, "Yep, okay, we're going to give you an ATO, you can now do contract work for CMS, or HHS, or whoever you're working with. And then finally, monitor controls, which I know is just fairly simple, but the monitor controls is very, very important. They've got, in a lot of these risk management frameworks, they always have a document. It's a breathing, living document. If you ever work in this, you'll know what it means. The POANM, the plan of action and mitigation document. So you're going to tell what's not working. You're going to give a timeline of when you're going to get it done and how you're going to do it. So it's constant live and breathing like most, every regulation we have out there. Risk Management Framework no different.

The CIS, the Center for Internet Security, this is one of my, when I first got in the security field, this was one of my favorites. Every year, they come out with a top 20 critical security controls. So they break it down to where, if maybe you don't know what you want to look at the 80053 is intimidating, you're not working the Federal Information anyway, "I don't want to deal with that one." The Center for Internet Security came up with really good baseline of things that you should do. And then again, they put in their top 20 critical security controls, which I think is great. It's neat to see what they come out with every year.

They've recently broke it down into basic foundational and organizational. But for the most part, I can tell you the top two, I think it's been that way for the last seven or eight years is going to be asset management. Whether it's your physical asset management of your network as well as your software management. Because if you don't know what you have, you're not going to know how to protect it. Those are almost I think invariable always your number one to encrypting at rest, things like that. Those are going to be those top controls. I'm thinking of another red word there. But yeah, the CIA is I think it's a great site to go to take a peek at it. It's nothing terribly intimidating. Just gives you a good idea of what these guys in this particular case, find as what the priority should be.

The COVID-2019, the governance and management objectives. Well, COVID is a framework for the governance and management of information and technology aimed at the entire enterprise. So enterprise information technology means basically all the technology and information processing that the enterprise puts in place to achieve its goals regardless of where this happens in the enterprise. In other words, enterprise IT is not limited to the IT department of any organization, but certainly does included. So, COVID 2019 can be very broad stroking as well. That one here developed by ai sokka.org. You can definitely do some more research on that ISACA.org. You can definitely do some more research on that ISACA.org website.

Finally the IRS Publication 1075. Sole mission, to protect confidentiality of Federal of Taxpayer Information. Basically protecting all FTI. So a lot of times we'll hear PII, PHI and FTI. Those are going to be the kind of your three main categories of sensitive information. This is what the FTI means, it's Federal Tax Information. So this intent, like most of the other ones is address any public request for sensitive information and prevent any disclosure that data, that would put FTI at risk. So very similar to all the ones we've talked about. This publication also provides guidance to ensure that policies, practices, control safeguards, are employed by recipient agencies, agents or contractors. So, again, another regulation just in a different area to make sure that we are protecting that sensitive information.

The last framework we're going to talk about Common Criteria. This one here, we've got a couple of things like the National Information Assurance Program, the Common Criteria Evaluation and Validation Scheme, these are the ones that are developing those protection profiles, methodologies and policies. For the most part, they're taking commercial off the shelf software, and they're trying to make it conforming to industry standards, or international security standards. There's going to be a few things, if you look at that middle part, they're going to or are actively pursuing three categories for certification. I'm not going to go into detail because they got a bunch of different protection profiles, they get extended packages for protection profiles, functional packages, and it's kind of all over the board. We don't have time for that. But the three areas that we are currently pursuing to go through this is one the protection profile for application software.

So this is going to be able to define functional and assurance requirements for that software. So, basically in recent years, a lot of the targeting for attacks have been moving away from operating systems and now targeting applications. So this is that response to, "Okay, you know what? We really need to harden the applications. So now, it's definitely very, very important that the security of application be improved to reduce that risk of compromise. The functional package for TLS, this is going to be those cryptographic protocols that we need to use to provide communication security over those IP networks. Things like the protocols and widespread use of software provides functionality such as web browsing, email, instant messaging, Voice over IP.

The primary goal of the TLS protocol is provide confidentiality and integrity of data transmitted between two communicating endpoints. So whether it's the server or client side. So, we need to definitely evaluate the implementation of both endpoints, both server and client is typically necessary to provide that assurance for the operating environment. So these are going to be things also that we're looking at, because we as you may or may not know, GoAnywhere can act as the server and client side in a lot of situations.

And then the last one, that extended package for Secure Shell, this is just going to address any applications that act as an SSH client server or both. Same thing. We can be an SFTP or an SSH server side. And we can also connect out to SFTP or SSH servers. So we definitely have to be on both sides. So what does this actually mean? Well, it just means that we're taking you know, security seriously by going through these rigorous testing and going to achieve that accreditation. After they're in this long it usually takes about three to six months for accreditation. So, we're hoping that timeline is going to be in place so that we can claim Common Criteria accreditation, which is going to be really, really nice.

Okay, lots of stuff we talked about, all over the board, there's a lot of overlapping between the laws, the regulations, the standards, the frameworks, a lot of different things to even think about. So what do you need to do or what things you can do, I guess is know your industry, what industry you're in, it could be a no brainer. You're processing credit card information, PCI DSS is probably where you're at. You're working for a federal agency, FISMA might be the one you're grabbing. Maybe you don't fit in per se to any regulations or rules, but you still want to do your due diligence for security. Maybe just evaluate some of those grab one. I like to CIS, the top 20 just to see some of those top things that security professionals are saying are high priority in a top 20 list. But in any case, knowing your industry so that you know specifically if you are going to fall under a regulation or rule or law. That's definitely something you want to know.

And then obviously, the type of data you're dealing with will help you there. Once you do that, getting that C level buy in, absolutely imperative. You guys probably know this not from a security standpoint, from any standpoint. You got to get the C level folks involved and you got to get them to understand why it's important to do what it is you're trying to do. And then pick your poison. Probably the worst, not the best there is phrase there. But pick those safeguards that you need to address, ones that maybe you can't, because you don't have the budget at the current time. So you need to do some prioritization of what you need to address. And then pick that framework to use. Whatever framework you want to use.

Then getting some tools to do automation. One of the things we didn't point out is human error, I believe still is the number one reason for data leakage or breach. Whether it's malicious use or more common, just flat out mistakes done by human intervention. So as much as we can automate, that's great. Tools to ensure appropriate protection. So we got to make sure that we have the tools available to us. The cipher suites that are strong enough, the key exchange algorithms, things like that. We need to make sure that we have those appropriate things in place so that we can do those things. We have the tools to actually do them. And then you're going to see that last bullet point in any regulation that you're a part of. You're constantly monitoring and evaluating. That's the whole I mean, that's probably one of the biggest things about security. You constantly have to be monitoring and evaluating anything and all activity that's going on to make sure that we are compliant in any industry.

Okay. So with that, let's bounce out of here and let's take a peek at a few things that we can help as far as GoAnywhere is concerned on some of those areas that we talked about. I'm logged into the console here, they go into our admin console. So we'll just run through a few things to see how we can address some of the security concerns that we just talked about. One, access control is always an issue. I don't think it matters what regulation you're a part of, access control, and auditing and accountability are always going to be a big one. So from an access control perspective, we'll just touch on a couple things quick.

The admin users, again, those are going to be the folks that are logging into GoAnywhere to administer the system. So obviously, they can be pretty powerful, they can do a lot of different things within the application, they could potentially on accident or on purpose misconfigure things using maybe a Blowfish type cipher suite or a SHA-1 flavor that's not technically your FIPS standards or NIST standards as the correct algorithm to be using for assigning a certificate or whatever it is that you're doing. So we want to make sure that the admins that we are creating have the appropriate access, or we want to instill that idea of least privilege.

So within our admin user roles, we do have, I believe, 18 different canned administrative roles. So those are back roles. But there might be some times where I want a bunch of Help Desk members and I want them to be able to reset passwords, maybe approve web user accounts, and then maybe do a couple things with web user groups. Well, we don't really have a role that does that, very specifically, we've got a web user manager role, but they're going to be able to do anything with web users and web user groups. But we don't want them to be able to create them. We don't want them to be able to delete them, stuff like that. So we do have an add role. And this is going to be able to add a role that you customarily create, we'll just call this Help Desk user, or I should say admin.

So now we can get as granular, we can get as creative as we want. Because now we've got statements which are basically saying, allow or deny. But more importantly, we've got subjects. And subjects in this case that we're talking about, we're going to talk about web user subject, because I want them to be able to, let's say, reset password. Maybe I want them to be able to, they can approve accounts. And they can view them. And maybe I don't know, whatever. They can export them. That's all I want to do. They can't delete, edit, create any of those types of things. But not only do I want them do that, I want to add a subject because I also want them to do some things with the web user groups.

So we can go to our web user groups, and now I can say, yeah, I definitely want them to be able to view the groups. And maybe, I don't know, promote and export them, if you wanted to. Point being is, I can add as many subjects as I want and then pick out the specific actions that that person can do within that specific subject. So you can see, you really can get as granular and as creative as you are, for any kind of custom admin user role. So that's nice. Maintain at least privilege.

As far as access to the system, one thing that you're commonly seeing over the last couple of years is going to be that two-FA or multi-factor authentication whatever is used, we can do that both from an administrative user. So if I go into my admin user down here. I can see that I've got a two-factor authentication option. I can leverage a RADIUS server should I have one. Whether it's RSA, whether Google Authenticator as one, Duo has a RADIUS server. Whatever uses RADIUS, we can configure that, use that. We can leverage a couple to TOTP options. One is going to be the traditional TOTP from that you're probably familiar with. Where the first time you log in, you get a little QR code, you take a picture with your phone and then it goes to your to TOTP app. Whether it's Google auth, Microsoft auth, auth the Duo, whatever. Whatever that is, it'll shoot you a six digit code and you get 30 seconds intervals in between the code changing.

And this other one that go anywhere one-time password. This was something for maybe people don't want to teach their users how to take a picture, or a QR code. Maybe they don't want them to download apps on their mobile devices, whatever. They go into a one-time password, leverage SMS or SMTP, whatever you have configured in GoAnywhere, to send them an email or send them a text message with that one-time password as well. So different options you can do for MFA.

On the other users, the web users, very quickly. Those are the users you're going to create to login or leverage whatever service you're offering as GoAnywhere. Whether it's HTTPS web client, SFTP server, FTPS, whatever the case may be. But within here on the web users, I can go down to an authentication types and I can see any protocol that I have here. I have some method of doing a two-factor authentication. Specifically with the HTTPS, you're going to see they have the same options. Looks like mine is a time-based one-time password, and maybe my SFTP looks like it's doing username passwords as well as an SSH public key. So there's a couple of different ways that you can do that.

So let's look at my web client, so that dfreeman has it on there. So let's do dfreeman. And we're going to log in with the username password first. And maybe I have to do it twice. And so we'll get this code because I did have the TOTP. So what you're not seeing is me... I'm actually going to use the Google Authenticator, that's the one I chose. But actually, I'm going to put something in that doesn't match it. Hit submit. Okay, I got access denied. That makes total sense. Let's go back in. Let's do this again. With that same code, and we'll do that right this time, 447. So again, that was on my Google auth on my mobile phone. So I put the code in, and I got logged in.

Let's flip back to the admin side. So we can see a little bit of logging that just happened. So let's go to our reporting and audit logs. And let's take a peek at the HTTPS specific log, because we were logging into the web console. And so here we can see that dfreeman, the first time he logged in looks like user dfreeman passed the first factor, that was my username password, but then MFA was initiated and the login, it actually failed. Because my verification code must be a number with time, whatever. So okay, I typed in letters, but if I typed in numbers the wrong thing, you're going to get that message. Basically it was the wrong password or passcode for your TOTP authentication.

The one I did successfully as you probably guessed, I passed the first factor and then I actually got logged in. The logging is going to be, it's something that's very important as well. We talked about auditing and accountability. It's going to log any actions that's coming into GoAnywhere. In this case, we were just logging login attempts from a certain user. So pretty straightforward there.

Okay, so let's go through some of the things that are also going to be high on the list. Encryption. Specifically encryption in motion and transit, we always hear about that, as well as encryption at rest. So one thing, within GoAnywhere to mention first, and I'll tell you why in a second. There is a master encryption key. This key is going to be in the background upon initial install. But this master encryption key option here is here so that if you do want to rotate these keys say once a year, you can do that. You can create a new master key. And then that new master key from that point going forward will be what's being used to do AES 256 bit encryption and decryption on the flyer, on certain modules within GoAnywhere. Only reason why I point that out is there's going to be different modules that by default are going to have that master encryption key, encrypt the data at rest.

A lot of them being here out on the web client, some switch back out to the web client side. The GoDrive module. And again, super high level since this is something where your users are going to create out folder structures, they can share out different folders or files via public link, maybe just via email. They can manage access, whether they have contributed editor, whatever. It's basically a collaboration tool. Everything that goes on in this directory, everything that goes back to a GoDrive directory on your network of your designation, and that directory, everything and its contents are going to be a AES 256 bit encrypted rest. So not only are they going over a secure channel, an HTTPS secure channel to get there, where they land, that's going to be that encryption as well. So, true end-to-end encryption.

Same thing with Secure Mail. Secure Mail is going to send out secure mail, put all of its contents in a packages directory which is on your internal network at your choice. That directory as well as AES 256 bit encrypted. And then Secure Forms, basically, a web-based way for you to gather information from somebody or people, whatever the case may be, the information that's stored when we're actually maybe kicking files back out to users as a result of whatever it is they put in. That directory also at rest is going to be a AES 256 bit encrypted.

So lots of different features that are automatically doing that. But we can also do something like leverage encrypted folders. Where you are physically going to point to a network share on Linux mount, some sort of resource, the second SMB resource. And you're going to point to that directory and say, "Hey, by the way I want this to be AES 256 bit encrypted. So now this could be maybe an inbox to somebody's SFTP directory. So not only are they sending it over SFTP, provided SSH encryption, but now it's also going to be encrypted at rest in its final destination. Same thing. I'm using that master encryption key to encrypt this data.

Final thing I want to check out, well, I guess a couple of things. These keys, where are they coming from? How do we manage them? We've got a key management system. And this is where you can manage your SSL certificates, your SSH keys, as well as your PGP keys. Those certificates, you can slap those on like an HTTPS listener, for example. SSH keys you can put that on your SFTP server, or maybe you're going to use those SSH keys to be the authentication method for you to connect out to somebody, or vice versa. And you're getting public keys from people, you're going to associate it to their web user account and you're going to require them to have an SSH key for authentication. All those things can be managed here. Cradle-to-grave, or if you're importing existing ones, great, you can leverage them here.

PGP Keys, the same thing. If you guys are requiring people to send things to you securely via PGP, great. You can import their public or, yeah, their... No, sorry. You're going to export your public key to them, they're going to encrypt with your public key sent to you, and vice versa. If you're requiring people to, or they're requiring you to encrypt files to send to them, then you're going to encrypt it with their public key, and then send it on its way. All these things can be done in an automated fashion.

From the listener standpoint, very quickly. Just to quickly look at the HTTPS standard. So we'll talk about encryption in transit. This is where from the listener secure, we can definitely slap on an HTTPS, or secure TLS certificate. The enabled SSL protocols, you'll see that we, actually in this demo box we're allowing TLS version 1, 1.1, or 1.2. This is totally up to you. Maybe you want to just do this. If you're under the PCI DSS, this is going to be a requirement. You can only allow TLS version 1.2. That's just going to force the client that connects up to you to negotiate TLS version 1.2. And then you're going to see a whole gamut of cipher suites that you can choose from. I'm sure your security folks will know what these mean, but this is probably somewhere where you just want to grab the ones that are going to be nest certified or something probably not a SHA-1 flavor. If have something SHA-2 and at least AES bit encrypted. So, these are going to be again just a, we're giving you the tools to make this compliant no matter what regulation you're a part of.

We can also do things like just very, very quickly, you can do some filtering as well. Some file level filtering. Make sure that you're not getting malicious type files at least from a file extension or name perspective. Same thing goes for the SFTP listener. You can definitely filter on options, you can do your different cipher suites algorithm key exchange, Diffie-Hellman key exchanges during the handshake. You can change the key sizes and everything like that to make it as secure as you want them to be.

Very quickly, just in the interest of time, I want to make sure you get these last couple things covered. We can talk very briefly about automation. Remember, human error has been the bane of data breaches. Let's be honest. Whether it's malicious use or it's accidental. So the more that we can automate the better. So within here, we can create projects, think of them as like scripting, just in a graphical, I think, very easy format to make these business functions, put down within here, these projects to do things like a traditional script. Let's just say we're doing a PGP encrypt. An SFTP out to whoever I'm doing this to.

So we can create that project. And without going through everything in this project designer window, I'm going to choose a PGP encrypt task. And then I'm also going to choose a SFTP port because that's how I'm going to send it to him. So my first task, let's just say we're monitoring a directory. And once we get the files we want because it's in partner A folder, we're going to grab those files, build a file list, and we're going to call this project. What this project is going to do is say, okay, cool. I'm going to PGP encrypt, well, what am I going to encrypt? I'm going to encrypt the file list that was passed into this project via that monitor, which I understand we didn't go over monitors but that's all it's doing is basically going a follow list. What am I going to encrypt it with? Well, I'm going to encrypt it with the public key of whoever I'm sending this to. This drop down list is being populated by that KMS stuff that we talked about earlier, specifically the PGP keys in this case.

So it's like that PGP key versus the HelpSystems, and I'm going to say you know what all these files that I'm encrypting, I'm going to encrypt them with that key, they're going to be PGP files. I'm going to put that in a placeholder called PGP files as an output variable. So now then I want to go to my SFTP, and whoever I'm sending this to, this list is being populated by the resources we defined earlier. So whichever server it is, my put is going to be the PGP files I just created. And the destination directory is going to be, wherever you want it to go. It's totally up to you.

So, point being is, we can have a directory out there that just says partner A, you just have to tell your users, "Hey, when you need to send things sensitive to your partner A, dump them in this folder." That's all they need to know. We're going to have a monitor pick it up, call this project PGP encrypted with the appropriate key and then SFTP put it to the appropriate SFTP server. I know that was a quick run through, but that's a very small sample of how we can automate things.

Another thing I wanted to show you, because I know compliance, a lot of times breaches are going to happen when data accidentally leaks. So a quick example to show you is something to where we're going to send an email out, we can do some checking on that email for any kind of content. The specific example I'm going to show you is going to have maybe some credit card information in a file. And it's specifically going to be in a PDF or an actual JPEG. Well, one of the two. So it can do some OCR technology, which is really cool. Now having said that before I jump there, that's going to be adding a resource that we have. One of the resources we can connect up to are ICAP Servers. So that's going to be our content filtering device. So just an FYI, that's what's happening in the background.

So what I'm going to do here is, first I'm going to look at a trigger to show you that before I actually send the secure mail I'm going to call this trigger because I'm going to send it via my dfreeman account, and that's what I'm looking for. If the event user name equals dfreeman, then I want to call a project, specifically this Secure Mail block and notify project. Don't worry, we'll look at that and what that's happening. Let's just send the email first and look at the behavior. So if we go here and just send this out to my gmail account. Testing. Testing. Let's attach a file, and we're going to grab that. Okay, it looks like it's a PDF, so it's still going to use OCR technology. And let's open this PDF, just so you know I'm not pulling your chain here.

So we've got a mock credit card number. And let's go ahead and send that Secure Mail. And while that's sending, let's go back to the administrative console. Let's go to the auditing, and we can audit a specific trigger. So if we look to see if that trigger even got kicked off let's go to our audit logs and triggers. And we can see at 10?55 which is now, we have the trigger kickoff, let's take a peek. And we can see it called the project. Looks like it was completed successfully. And the package was denied sensitive information as the rule under this 5749 job. So let's go look at that job next. 5749. And very quickly it's taking some variables that we defined. Let's go in the project. We're going through the ICAP tasks. So it's passing, in our case it's a clear swift device.

We're going to be scanning it. So it looks like here, the ICAP Server returned a status code of 200. I don't know if you know much about ICAP but usually a 204 means, "Hey, everything's good." Anything 200 from an ICAP status code is not good. I understand this is a little conflicting to an HTTP status code because that usually means okay. But the ICAP status code in this case, that means it's infected. So we're going to go through our conditions. The ICAP status 204 was not met. The 200 was met, so that's what I'm actually going to send an email notification to me saying, hey by the way your message was denied because it had sensitive information, and that email never goes out.

So we can also check, just to make sure this happened. Yeah. So 10:55 we got that email from me saying your email message is blocked as it contains sensitive information. So other things that you can do by leveraging those resources or our connections out to other servers and services to do that automated process, to do in this case content filtering. They can also do virus scanning, things like that.

One of the last things to show just for more of the actual regulations that we looked at. We looked at PCI DSS, and one of the actual canned reports that we do have is a security settings audit report. And you can run these ad hoc like I'm doing right now, or you could put them on a project to run them once a week or however often you'd want to do that. And it's going to come back with a PDF. It'll come over here. A PDF document of okay, hey, these are the things you passed, these are things you didn't. If you didn't pass, it'll give you recommendations steps. And then it's also going to show you the actual PCI DSS section that this is particularly mapping to. So kind of a cool snapshot, hey this is what's going on. And, again, specific to the GoAnywhere application.

So with that being said, again, I just want to reiterate, compliance is huge. We had one hour, we didn't scratch the surface, we test all kinds of different ones literally at the very top of the surface. I believe the whole idea is, no matter what you do from a compliance standpoint, you have to identify where you're at, what kind of data you have, all the systems encompassed within that's going to be in scope. That's why I mentioned, there's no magic pill. GoAnywhere is no exception. You can't just buy our product and be compliant.

I don't think there's any product out there that you can do that. We give you the tools though as we try to show today, that you can configure these things, we'd give you those appropriate tools that if you configure it properly then you can be at least from the GoAnywhere application standpoint, we can be compliant, or at least doing your due diligence for good security best practices if you're not falling underneath a law regulation.

With that being said, I'm going to shoot this back up here. Maybe get it back up here. And I guess we'll... I didn't leave a whole lot of time, if there's any questions out there.

Angela: And I think that Brian actually did take care of the questions that came through in the chat.

Dan: Oh, cool.

Angela: Yep. So if there's any other questions that folks have since we are so close to the end of the time, as I mentioned we will have that survey that will pop up here at the end. And feel free to submit any questions that you have through that survey. Otherwise, I believe that we do have some contact information here that we can toss up. So you know how to get in touch with us and thank you very much for joining the webinar today. And as I said, any questions feel free to send those to the information there on the screen, or through that survey. And then with that, thank you all for joining us and we hope you have a great rest of your day. And thanks again and thanks, Dan.

Dan: Yeah.

Angela: This was very well done. Thank you.

Dan: Thanks guys.