Subscribe
Share
Share
Embed
What is ransomware? Can it impact FileMaker applications? Trusted FileMaker community members Wim Decorte, Heidi Porter, and Chris Moyer, join Jeremy Brown to discuss Ransomware in the context of FileMaker applications.
This podcast is about workplace innovation through technology, with a special focus on Claris FileMaker and the Claris Community.
This is the context podcast sponsored by proof Geist. I'm Jeremy Brown. Ransomware is a scary topic. It's heavy. That brings all sorts of worry and doom and gloom to hard, very souls, but there is hope to combat the attacks. If we give our attention to what it is and how to put safeguards in place.
Today's guests, Heidi Porter, Chris Moyer, and whim to court share this message of doom, but also they share one of hope. They've talked about this in many user groups, office hours, and now through this podcast, they've had firsthand experience in deep knowledge of ransomware and a FileMaker server itself to give us ideas on what we can do for our client's files.
So although we talk about upsetting ideas today, when it comes to customer data, Chris, Heidi, and whim guidance with a steady and calm hand to help us understand what's involved and what we can do. So let's turn our attention and hear what they have to say.
Welcome to the context podcast. Wow. We have a full house today. Um, I'm very pleased to have with me for, I think the third time whim is with me. Hi whim. Hey, and we have Heidi Porter. Hi Heidi. Hi. Hey Ann, Chris Moyer. How are you today, Chris? I am good. Thanks. So you are here today to talk to us about something that you find very scary.
And that's ransomware. Tell me about this. Is this really upsetting to you? Yeah, scary. And that's why we want to pass along the fear. So pass along the fear that that's interesting. Is it passing on fear? Is it, this is really important to know, to talk about ransomware for FileMaker developers rights. Yeah.
So it may be unpleasant, but it, it seems like it it's it's necessary. Was this I'm curious for you all, because you've all been developing for a while. Uh, has this been around for a long time? Were you thinking about this way back in FileMaker three, four days? Certainly not that far back. I mean, we first, I mean, we'd been hearing about it for years, but we had our first client encounter with it back in 2016.
So it's been that long where it seemed like a realistic threat to our client home. William, how about you, were you thinking about this long time ago? I know you've been thinking about security for quite a while is ransomware on your radar? Probably not ransomware as such, but certainly security and everything that comes with best practices and hardening servers and security in general has always been on my radar.
So this is, um, I guess this is the most relevant security issue that's out there these days, right. That doesn't negate all the other ones, but it's very real. Um, and to what we were just talking about, we're not fear-mongering for the sake of, uh, of, of, of making sure that people are scared, right. It's, there's gotta be a healthy dose of awareness.
And unfortunately that comes with fear, right. Because if you feel unprepared, you'll, you'll be feeling fearful. Um, how do you mention that? Uh, Chris mentioned that you first encountered this problem in 2016. Uh, had you had any, like, experience with this before? I don't recall any, just to leave the answer on this, you know, we had a, we had a backup, so the client did not play, pay the ransomware, which is a good thing not to have to do.
Yeah. I mean, yeah, we're not scaring, just a scaring we're scaring. Uh, because a lot of times people don't, um, make a plan for what happens if you're hit. And there are a lot of people getting hit. And so, you know, identifying, protecting, defending. You know, making a plan it, and it also doesn't just apply to ransomware.
It applies to any, you know, we had a client get a server blown away by a tornado. So, you know, applies to other things as well. How much did you have to pay the tornado?
And they just got a new machine. And so it sounds like you're here today to talk with us. And I'm glad about this because you had this experience, it kind of prompted you as I understand Chris and Heidi, especially to study the ransomware, um, environment that whole, you know, dark web area. You, you, you studied it.
You brought whim on, I think too, you can speak to this in a minute. You brought whim on specifically because he's the server guy in, in FileMaker. Um, But it sounds like you're, you're here too, and you you're sharing this all over the community so that other people don't have to deal with this and be caught unawares.
Like maybe you were back in 2016, is that correct? Yeah. I mean, I think if you're asking, what's the goal of this as to, it's just spread awareness of ways to protect yourself and also to encourage people because it is something that's, you know, disaster recovery is often not thought of until you have a disaster, but even before recovery, just what your response is going to be when some disaster happens and then ransomware there's specific responses, you need to enroll in responsibilities, you need to have in place.
Okay. Any other thoughts on that? You know, in the web world, they have this notion of being a full stack. And while that doesn't necessarily apply to FileMaker, you know, as filmmakers, you know, when FileMaker server first came into existence, it wasn't as sophisticated as it is now. But you know, we very quickly came to the conclusion that if you want to feel like you are, you know, in air quotes, full stack developer in the filmmaker world, you need to know IAS and you need to know some of these web technologies and, uh, have at least a basic understanding of how to administer a windows server and a Mac server.
And so we thought those were important skills to have for you to be able to advise a client, you know, they would often handed off to us and say, we would like you to set up the filmmaker server. And so you can't go in there only knowing how to use an admin console. You have to have an understanding of the underlying technology.
And so when ransomware came along, we felt like it was our responsibility to be good advisors to our clients, to also have an understanding of this. So that we can say, look, this is a, you know, sort of existential threat out there and here's how you should protect yourself. You know, that was the, it's not a coincidence that we started going to the cybersecurity conference named Def con Def con uh, in Las Vegas.
It's the largest. I think, uh, we started going to that in 2017, the year after, you know, we had the ransomware situation, you know, realizing we need to really broaden our awareness and expertise. Um, um, the wider security, uh, world. Why don't we start by describing ransomware, um, Chris, in your presentations, especially you've used a particular word that we'll see what you say here, but can you just tell me what is ransomware generally?
What is it? What is its purpose? So ransomware is a piece of software and it's a software implementation of a crime. And I think the word you're looking for is extortion. So, you know, ransomware is a crime of extortion to get a company or, you know, perhaps even a government agency to pay a ransom and they do that a bunch of different ways.
So they can bring down your infrastructure and deny you the use of that infrastructure. And so you would pay them to get the use of your infrastructure back. Um, they can exfiltrate data and steal your client data. And, you know, especially if you're a regulated industry, like, you know, say a hospital and you have patient data out there and they choose to publish that you would be in violation of your, you know, HIPAA regulations.
So there are a bunch of ways they try and apply leverage to the organization to make them pay up. What is. Bring down their infrastructure when as to exfiltrate data with the threaded publication, the Sony hack did that. Sony had some very embarrassing emails, leaked. I think they had some movies, uh, digital copies of movies leaked.
And so there are ways to really make you uncomfortable. And it's sort of, you know, it's like the old, uh, public shaming kind of thing. If you're supposed to be a company that is a company to be trusted, you know, Uh, law firm or something like that, where you're supposed to have good security. If you're a bank and you get hacked, it's not a good look, you know, and it doesn't engender the reputation of security.
And so there's that. And then sort of a later twist on this idea of extortion is to say, Hey, we can see all your customers here. Why don't we go talk to your customers and say that you've been hacked and that you're not willing to play ball and we're going to start leaking their information. So they're going to try and put the screws to you in any number of ways they can to get you to pay up.
And so, uh, the ransomware is, you know, and it's gotten more sophisticated over time. Originally, it was just to sort of bring you down, but now it has a whole bag of tricks. And I think Wim has been the one who's been playing with the framework. Most of all. And he can sort of, you know, expand detail on the bag of tricks.
Is it easy whim to bright and use ransomware? Uh, unfortunately a derided, probably not right, because these things can be sophisticated, unfortunately. Um, as Chris has shown in his slides there, uh, there's actually a marketplace for these things, right? So, uh, so if you know where to find them, you can become a ransomware guy or girl and start seeing what you can explore it.
So that's the very, very unfortunate fact of that is that they they've become toolkits that you can pay for and download and start using. Right. So it sort of brings us back to the script kiddies, uh, where, where some of the malware attacks were bundled together by, by just downloading and finding on the dark web, various bits and pieces that you can put together and, and, and, and use to Mount a ransomware attack.
It's interesting to me, You three are here with me in the F as FileMaker developers and the Clarence FileMaker space talking about ransomware. And yet to me and FileMaker themselves talks about how it is a low code platform. I just, I've never understood. I never even connected a low code platform with having to deal with ransomware.
Am I, am I not thinking about it? Like, you know, other databases, air, table, all those other things, do they have the same struggles that we do? Is it, are we unique right now in, in our current situation, we are somewhat unique in the sense that, uh, many FileMaker platform based solutions are deployed on prem, right?
So you can compare and contrast that, do anything that's cloud-based that is behind a bigger moat in essence, why do unified modes? Um, whereas the pharmaco solutions are deployed individually by and large individually somewhere. And. The, the modes and the size of the castle and the size of the Drawbridge varies a lot.
Right? So, uh, so it means that there's a lot more variability and the, and the defenses, um, and, and people could, uh, could get caught out that way. And, and I think a typical family developer, it comes from a different place than say some of the full stack developers that Chris was mentioning, right? Because full-stack developers typically have more formal education, I guess, on everything that comes from coding and deploying where your typical Pharmac developer is somebody.
And it's a, I'm generalizing a little bit, but comes from a business side of things where they, they knew a problem really well, and they found a tool to help them solve that problem. And unfortunately, sometimes that's where they think their responsibilities end with the, with the development side of things.
Right. And I've talked about this at many, many deaf cons in, in audit areas like performance profiling and, and making sure that, that the servers keep up with. W we're all good developers, but are we good? Deployers right. Um, I don't think we can just throw our hands up and say, I don't know how to deploy a server.
I don't know. IIS. I don't know when those, I don't know Linux. I think that's fair to say that you don't know. I just tend to think that our responsibility is for the full thing, because at the end of the day, our clients only get value out of a solution when they can actually use it. Right. Um, and as Chris said, a ransomware is a crime of extortion.
Uh, you can think of it as a denial of service attack, right? They don't need to steal your stuff necessarily as long as they can prevent you from using it when you encountered this problem, was it, it was, was it an on-prem server? Like a whim had mentioned it kind of. Unique for us. Was that the case? It was at that time.
The other thing I want to add though, on what whim said was that I read something recently from no before that said that some ransomware are just going back to DDoSs attacks to extort money, because that is also a very simple way to just take down an organization. So there's many different ways they can do it.
They wouldn't, they wouldn't have the data then. Right. They would just be stopping business activities. We mentioned that this is pretty unique for us things like air table and whatever else is in our space. All these low codes, those are all web based platforms. There's no access to the server. We have no control over where the data is stored.
Does that make ransomware issues for them? Non-existent. Certainly not something right. Um, the, it gives them a better chance of defending, right? Because there's, uh, they, they own the infrastructure. They, they know the infrastructure and they control everything about it. Of course, if they were to be attacked, it would be a huge, like what was said before the reputational risk for them is great because in if one Pharmaca customer gets attacked on premise, that's just that that's an isolated incident.
Right. But if somebody say, if I'm in the cloud or air table or somebody else gets attacked, it will take down potentially millions of customers and, and, uh, and, uh, and that's, that would make it a major event. Okay. All right. I was wondering if we low code, the low code platform seems so easy to work with.
Um, but there is this ransomware as part of even a low code platform. It's not just for the web, the websites or the, the, the banks or whatever, it's it's for everyone. Um, how do you, you have talked specifically about how this is already happening and it's, it's just going on everywhere. Can you share some of those statistics or some of those?
Um, the, the examples with us. Yeah. So we had found some statistics, like, you know, since 2016, there's 4,000 ransomware attacks per day. The average ransom is around 170,000. And by the way, there's a whole industry around ransomware negotiation, you know, because sometimes they attack somewhere in the place, really can't afford to pay the ransom.
And so, um, or doesn't want to pay that much. And if you pay it, you know, you're more likely to get attacked again, by the way. But even just when we started, um, talking about, you know, Hey, we need, maybe we'll do over in session. Uh, four paws, almost every single time we just kind of started, you know, mentioning it on meetups or in groups and people had the story, right.
We kept hearing story and story and story. And every time we do this presentation, we get, you know, half the people raising their hands. So, um, we did have someone asks, well, has a Pharmac or server ever been ransomwared, uh, at one of our presentations and the answer's yes. Oh, you know, this has happened.
That's one of the things about kind of the main targets of ransomware are small, medium businesses, hospitals, maybe rural governments. I'm seeing they're reported. I believe. Uh, you know, I can't prove that, but it probably is under reported. Um, there's not the ability to enforce action for all of these attacks.
Right. Um, even if they are reported. So, um, I think they're happening more than we know. Even with the statistics of how much they're increasing and the insider threat is also getting bigger as well. Um, based on an article that, um, someone posted today, you know, someone inside your company, Can basically hire someone or pass along some ransomware agent that can attack your system and then walk out the door.
Okay. Let's, let's start at the beginning. How ransomware we know is, is, as you said, Chris, I like how you said it. It's a software implementation of a crime of extortion. That's, that's a pretty awesome way to describe it. Can you, um, how, how does this work in general? Can you walk us through, like, how does, how does ransomware start?
How does it get to the point where it locks up my entire system or encrypts my files. It's a whole chain of events that leads up to the denial of, of your infrastructure, right? Have taken away your infrastructure or parts of your infrastructure, the, the act of getting your files encrypted. The actual ransomware attack is actually just a tail end of the, of the whole attack.
Right? The attack started. Somebody trying to infer, infiltrate your, your infrastructure. And very often these days that starts with, um, with fishing, right? They, they try to get to know your users, your, your staff, um, so that they can explore, uh, their machines and the rest of infrastructure. So it's a, it's a slow infiltration into your infrastructure.
And once they're in, they will try to borrow and expand, right. Move sideways, go from one machine to the next machine and basically discover everything that there is to know about, about your infrastructure, where you keep things, what kind of software you have, what kind of defenses you have, uh, what are your backups are kept?
Um, so they'll do a full reconnaissance of everything that you have, everything that you are so that they can, uh, and at some point they'll say we have a full picture. Let's pull a trigger and let's attack and they'll attack typically by taking away your back. So the attack can be spread out over months and weeks to the point that when they actually attack the most visible parts of your systems and you say, oh, I've got to shut it down and go to my backups often, you'll, you'll discover that you have no backups or that your backups are unavailable to you.
So, um, so all of that good stuff there, um, and the presentation, uh, and we can send some of the links with, um, with this podcast. I'm sure. Um, there's some really good websites that detail, um, summaries of all the vulnerabilities and attack services that are being used in, in this, in these kinds of attacks.
And it's massive, right? It's not as simple as here's a piece of malware, I'll plant it on your machine and I'm done, right. It, it's actually a combination of many, many of these things, uh, that are somewhat specialized and they will go to great lengths to figure out how your defensive. And then actively disabled them so that they can do their work without being, I, I was listening to your presentations that I'm interested in hearing every single thing that we can do to pre, to minimize, um, ransomware attack probabilities.
Uh, but two questions, Chris, for you. Um, is it inevitable that someone, is that someone in our space or I will get attacked in this way? Do you feel like there's inevitable? Yeah. Maybe it's a little bit of hyperbole to say everybody's day of doom is coming and it's just a matter of when, but I mean, I think it's fair to say probably half of the people we talk to have a story, um, I mean triple eight got hit in June and that sort of highlights.
Th the difficulty we have in sort of talking about mitigation measures for this. And I haven't verified this, but my understanding is what got compromised at AAA was their domain controller. And, you know, we're not purporting to have expertise on hardening a domain controller against attack, but if someone gets in there, then they can get to your FileMaker server.
So we're trying to sort of stick to our knitting and talk about what we know, you know, about FileMaker servers. And we can talk about how best to defend that, but this sort of, sort of broader, you know, defensive effort about, you know, making sure your end points are set and things like that. We have some sort of general recommendations, like Institute anti-phishing awareness campaigns and things like that.
That's just smart, just because it's a common point of entry, but it, as far as protecting different pieces of infrastructure, we're trying to have a tighter focus. Just so this isn't a four hour conversation. You mentioned Chris, that. The, the biggest thing we could do as FileMaker developers is to enable encryption at rest.
So, yeah, I mean, getting back to this whole notion of extortion, if someone exfiltrate your data with the intention of publishing an embarrassing, you know, you or the organization, one thing you can do to mitigate that is to turn on encryption at rest for the database. So they might exfiltrate your database.
They might try and use some, uh, password breaking tools to get into it. But if it's encrypted, that's not going to work. So maybe they've grabbed your database and all they have is this big file that they can't break into. So you protect yourself against that sort of prong of the extortion. So, so that's one sort of piece of the defense.
Um, as far as denying you access to your infrastructure, you know, they want to encrypt your backups and things like that. And so, uh, we're a big fan of using immutable backups that can't be encrypted to protect yourself from, you know, being denied access to a usable backup. And so, and especially with, uh, automation tools that exist out there these days, like auto, you know, it seems like a great idea to have encryption at rest turned on, having a mutable backup set up and then create an automated process.
To verify that that stuff is actually working in, you know, stand up, you know, automate a deployment, uh, operation where you say, I want to stand up a new cloud server. I want to grab one of my immutable backups and open it and launch it with the ear password and make sure that sucker's working. And so to do something like that, you have some peace of mind to say, yes, I am confident that if I had to, you know, at gunpoint, uh, spin up a new server and run off my backups that I would be able to do so.
And, you know, in general, people might do that process manually, but that's a hassle that gets old. It's not very exciting work. And so to the extent that you can automate that, I think you have a higher likelihood of making sure that that check actually happens. Yeah. The beginning, you all mentioned the, the, the, the fact that, um, you know, it's kind of a reputation killer, is that, is that true nowadays, given that.
You know, your, your, your thought is that a lot of us will eventually be ransomwared attacked in some way, whether or not we can, we can get, we can, you know, restore and, and, or stop the ransomware attack in the middle of it happening. Like I've, I've heard stories of, but is it, is it, is it, is it just part of our lives now that we just, you know, is it really gonna kill the reputation of a company if, if their server gets, uh, ransomwared yeah, I, I wouldn't call the reputation killer arms.
There, there will be, will be people who may not understand how easy it is to ransomware a company. And, you know, you can be well-protected and this can still happen because of the sophistication of, um, the ransomware groups. There's such a high payoff. They're highly motivated to, um, you know, to ransomware.
They, they make a ton of money at it. And so I think we brought up the reputation in that it can hurt your reputation a little bit, but it really shouldn't unless you were just totally lax on security. Right. It really it's one of those, it depends answers like why. Right. Um, I mean, he used to hear about, you know, the Amazon S3 mis-configuration issues and a lot of those were user mis-configuration issues and that sloppy, right.
That wasn't actually Amazon. That was the people who were configuring it, you know, as part of shared responsibility, you know, I think it really depends whether the reputation should be lessened. And I think you can't control whether it lessens your reputation, if you're ransomware. Right. I mean, we could be ransomware.
Yeah, I think a lot of it depends on the brand. So if you're putting company and you get compromised, like, well, they're putting company, what do you expect? But, you know, th there was a Casia, uh, software company that was ransomwared this summer, I think 1500 customers got, uh, attacked as a result. So they're a company that services managed service providers.
And so they are sort of a point of entree to a ton of businesses for them to get compromised was a huge deal. But if you're putting company probably not a huge deal. And so I think it really matters what space you're operating. Again, it seems to me too, that your reputation is, is also won or lost or, or bullied or, or constrained, whatever the words are by how you respond to it as well and how you recover from it.
Right. And I know we're going to talk about it in a bit, but you three had mentioned doing, I like what you had talked about when it comes to. Preparing you, you you've talked about a lot about how to prep for this and how to, how to practice. And I like that. So maybe that's part of, you know, the work with your reputation to kind of, to, to mitigate the loss.
Any, uh, points or any rating points. Yeah. So to Chris's point about, you know, having the IR password on, you know, you get ransomware, you have someone whose responsibility is maybe you need to let your customers or vendors know, you know, our systems down, we've been ransomwared, but all your data's encrypted and you, you know, so this is not, it will not be an issue that your data is compromised.
And so that immediately gives them a measure of security and helps your reputation, right. That their data's not going to be extorted. And if you don't deal with it for three or four days, like I had heard some, some big firms not dealing with the ransomware for awhile, it that could really hurt that could really hurt what you're doing.
Um, okay. So you've, you've described what it does. You've described whim, how it's, uh, it's a series of attacks that, uh, a series of little steps that people take to try to get into your system and then slowly. Add, um, commands to things slowly get in worm their way in. It's my understanding and help me understand this, but this is.
It starts by attacking the overall S your, your windows server, wherever it's located. It starts by getting into the kernels, into the actual operating system. There is that that's true. Does it go into FileMaker server itself is FileMaker server and attack vector, our files and attack vector as well.
Describe, describe along the. And the things that we work with, describe what is happening and in a series of it. Sure. Um, if I go back to the beginning of the, of how these things get to be, there's two huge attack vectors, right? One, we already mentioned that's fishing. That's basically tricking people into divulging their, their credentials and who they are and whatnot, right?
So that people can build the beginnings of a, of an image and, and, and get into, into your organization. I'm not going to say infrastructure because it begins at getting into your org organization and, and the, the other second one is sort of related to that is, is critical. Right. Um, almost to a fault, most of these attacks come from credentials that are not protected by the second or third factor.
Right. Because that's the easiest way. If I get a set of credentials, I can go turn around and try them out. But if, if those credentials are tied to the second factor where you're going to have your phone or something else or a key, then, then that wards a lot of these, these attacks, right? So that's in general, how a lot of these attacks begin.
Now, if we take it back to Pharmaca server, Fomica server can be, can be used as a tool, uh, to, to attack, right. Uh, but let's keep in mind that Pharmaca server does not need to be attacked for it to be ransomware. Right? Because as we said in the beginning, ransomware really is, is a denial of service type of attack, um, that can then lead to extortion.
But all they need to do is to prevent you from using your fine. Right. And, and if they can do that, they're successful. So they don't need to know if I make a server, they don't need to get into your files. They, as long as they can prevent you from using them, there they are. They are already winning.
Having said that, just like any software, there are things in Pharmaca that can be used. Right. I, if I can use a container fields to, to drop a piece of malware onto your machine, then, then that that's a vector or that's a possibility right. Is being actively used. Probably not, but it could be used that way.
If, if. Um, if we talk about it, we had an interesting conversation about, there was a recently, a couple of days ago, there was a vulnerability published and fixed in 1904. And we discussed that a little bit internally at saliva. And then one of the, one of the remarks I got from one of my guys was yes, but doesn't that doesn't the user has to be logged into Pharmica to begin with for it to be used.
And I said, yes, but on all of our users logged in. Right. Um, so it's not like somebody needs to be able to force their way into it. All of our users are already logged in and who doesn't have one of those clients that who have users who keep, who basically don't log out at night, they log in for, for days and weeks on it.
Right. So if I can get on onto that machine for some, in some way, now I have access to a live pharmaco session. I can do a bunch of stuff. So there there's, there's a million different factors and possibilities of getting in there. The operating system has vulnerabilities. Every single piece of software has something similar.
And the dark web is full of dictionaries. If you will, of, of these things, right. People can just pick and choose on how they attack and that's exactly what they do. They go scanning and they look for vulnerabilities, unpatched things. And Chris talked about this and, uh, in, in our presentations, like keep up with the patching, right?
That's, that's one of the easy ways to, to, uh, to put a speed bump on the road. The three main infiltration sources are, to me, it's really one, but it's fishing, patching, you know, unpatched issues and then, um, RDP and weak passwords. But to me, that's really one Becker. It's the people it's people. You know, getting fished, not patching and having weak passwords.
So, so if we remove people from this equation, your files are fine. Right? Sometimes, sometimes we joke at that. What is the most secure database? It's one that nobody has access to it. It has no records, right. Everything. Okay. So it starts, it starts at dos Heidi. You mentioned the three that fishing patching and the RDP access, right?
The weak, weak passwords. Those are three ways to get into the actual S and then I think I, I heard one of you mentioned that what a, uh, an attack process could do is get, find your backups wherever they're located, find your actual life file wherever it's located and start to, this is what I'm, I'm a little bit, maybe I'm just not clear on a ransomware person could say, I'm going to just lock up the whole system.
Or they could actually encrypt the files. Is that, is that, are those two routes or is it, is it just, they're just going to lock up the whole system and move on. Are they going to actually try to get to my FileMaker files and try to get the data out of there or, or lock those up so that they can't be used?
I guess the, the old style of attacks was really all about encrypting the files so that you couldn't do anything with that. Right. They can try to lock the machine and they do, but as, as Chris and Heidi mentioned, ransomware has evolved so that they, that there definitely is a, an extraction part to it.
Right. They, they will try to get the data out because why the hell not if they can. Right. So, um, because now they have it, they can, they have it on their premise. They can take all their sweet time that they want to, to see if they can get into it. And what Senate, there's different flavors of obviously the, these ransomware attacks.
Um, but the sophisticated ones will lock you out. Encrypt your files and, and try to siphon off your, your data and anything else that's useful. I heard somewhere else that it's, that FileMaker files cannot be encrypted while they're open. Is that, is that true? Is that a unique part of FileMaker? Uh it's it's um, they, they can, um, but it takes a somewhat, I was going to say a level of sophistication.
It's not even that hard. Um, what we're talking about here is that when Pharmaca server hosts a file, it has a lock on that file. Right? So, and that's a signal to the operating system and to the file system that nothing else should be able to touch it because Pharmaca server owns it for that, for that.
Right. So if you have a dumb ransomware agents, uh, it'll try to use the file system and it'll try to say, Hey, let's encrypt this file. And the operating system will tell it, no, you can. Somebody has a lock on that. Right? And if the ransomware is dumb, it'll move on. Unfortunately, ransomware, isn't always dumb.
There's ways to, to release that lock that FileMaker server has, or if they're sophisticated enough, they can shut down the Pharmaca server service. Right? As, as you may recall, there is no password required for telling the Pharmaca server service to stop there's password required to close the file, but there's no password required to stop the service.
So if I'm sophisticated enough, I'll just share down the service and then move on to equip the file. So the fact that FileMaker server has a lock on the phone. Can protect against some types of ransomware attacks, but don't count on it. I guess I would add one thing in that is that there's so much money flowing to these groups that they are in a perpetual state of building a better mouse trap.
And so something that stops them today, they're going to probably figure out a way around and have it not stop him next week. Just because, you know, we have certain things going for us in the present doesn't mean they're going to continue to be protective. And so I think we should assume the worst case scenario and behave accordingly.
You mentioned that one of the ways of getting in is the fishing method where I, a FileMaker user has they're sitting there. They're, they're logged into the file and they go overnight and someone has the ransomware, attacker has gotten control of their system and can then use that tunnel because the file is open.
Is that right? When that's, what you mentioned is, uh, is a way to get in, is that get in through email, into the network, through email? Yeah, that's right. That's what fishing is. So, so, so the fact that there, it sounds like to me that you're, you're, you're suggesting that having a file open a file maker file open is a way into that server machine.
So that I could start messing around with it potentially. Right. It's it's a bit of an unlikely one, but it is one it's one of the main reasons for instance, that the sample file that comes with FileMaker server, uh, is now by default, we don't only, uh, because it was such an obvious adapt factor, not to ransomware necessarily, but if I want it to take down your server and you had a default installation, old-style not these days anymore.
Uh, and you still had to do the, uh, the FileMaker server sample file. I could just go in, uh, create a script that would loop and create a records and put the king James Bible and every single records, a hundred million times, right. It would take your server down. I wouldn't break into your file. I wouldn't steal your stuff, but you wouldn't be able to use it, right.
The essence of what the ransomware twice. You also, you've mentioned, how do you, the, the, the email is a, is a part of this, does it, do you mean that, um, me sitting on the server machine opening an email that looks fishy, or are you doing that? Shouldn't be opening the email on a, on a server machine, but you actually had in your mind, on my client, on my machine while the file maker file was open, clicking on that email.
And that could cause, um, the beginnings of an attack onto my server, but you don't even have to have the file maker file open. Right. I mean, it would just, you know, if you're connected to the network, uh, and how do you, how do you mention to RDP as one of the big ones? Right? How many of us don't have an RDP session to a farm microserver at least once a day.
Right? And for, for convenience sake, how many of those. Don't use like a map drive, like we're mapping a, one of our local drives into, into the RDP sessions. Right. So, so now if I'm getting fished and malware on my laptop, I may be infecting that remote server. Right. Because my laptop has a jump points into, into something else that that's how these things spread.
Right. Um, um, and, and maybe even my drive, uh, has a map drive to the FileMaker. Backups because I'm, you know, I'm one of the developers and I have access to those backups. Right. Exactly. And I get fished now. I'm not ashamed of it, but I do, but I won't. So you mentioned, okay. All right. Let me, I'm still trying to make sure I fully understand this.
Um, and my question just escaped my head. When you mentioned a while back that that a container field could be an issue. I have two questions for any of you. Um, actually, I don't know who mentioned that. Sorry. And, and, and, um, Chris, you had talked about encryption at rest encryption at rest is one of the security features of, of FileMaker of the Claris FileMaker platform are, do all of the other, uh, features, the security features that we use.
Do they continue to inhibit, um, this, this, uh, this, uh, from happening to us, like changing passwords every 30 days, or, um, you know, Full access or disabling the guest account, or are those things that Claris has closed down over the years that can prevent these from happening. There are commercially available password cracking tools, and they're not just for filming or they're for a variety of things.
You can break into Oracle databases or Excel spreadsheets, or what have you, you know, pick your file. There's a cracking tool out there for it. And so you could be changing your admin password every 30 days. And if someone exfiltrate your file in gains physical custody of the file, they can run it through a cracking tool and basically wipe the admin password and just get in with Edmond blank.
And over the years, um, the cars platform has, has migrated more and more towards the sort. So like the, the least privileged, uh, default setting, right? Call it zero trust if you want. And that's a good thing, right? Because it means that as developer, we have to explicitly turn things on instead of having to remember to turn them on.
Uh, if we, if we don't want them, but so much depends on how the developer then, then uses the features and, and enables things and not enables things. Right? So the default settings on, on Clara's these days are actually pretty good. Do they prevent against these things? And to some extent, it's like, what were some of the things we've talked about in the beginning?
The shared responsibility is a real thing, right? Cause Claris cannot anticipate everything that any developer will do with the platform. And some of the things will be insecure. Right. We see so many solutions for instance, that use auto login to then try and capture the user and kick them back out in.
That, that is one of the most insecure things, because you could potentially lead let the world into your solution only to try and catch them and kick them back out. Right. So plenty of opportunity to poke around and figure out what's a, what could be wrong. So clearly the way that we develop the clay, the way that we deploy, we have to continuously practice good hygiene on these things.
Right? And it's, um, as, as Heidi and Chris have said, these things evolve over time or our understanding of these things changes. And, and so by definition, the way that we, we, we respond to them. A lot of people ask me about, uh, web viewers and JavaScript. Is there any. Potential problem in that, in that avenue.
Do any of, you know, of any ways that a JavaScript injected into a web viewer could cause havoc in, in this, are you familiar with, uh, sneak.io? S N Y K. So that is a utility, I guess I'd call it basically keeps track of, uh, library dependencies. And if any sort of a security issue has been reported in any of them, you can basically point a, your URL at this thing and it'll scan it and say, oh, you're using this library.
There's a problem with that. You should be upgrading that library. And so to the extent that you're, you know, if you're just writing your own stuff, it's probably not terribly useful for you, but if you are leaning on existing libraries and have dependencies. Um, that's one tool that you can use to check and make sure that you have good code hygiene.
Is it likely that you're going to have your FileMaker database broken into by that vector? I don't think so. Even the latest security vulnerability that David Hillman wrote up, is it theoretically possible? Yeah. Is this like a genuine risk? If you're not, you know, doing XML import or, you know, using some of the XML features, the chance is pretty remote.
You know, there's always some distance between what's theoretically possible and what actual pragmatic. So in other words, JavaScript for violent liquor is perfect and we don't have to worry about it at all. Right. I mean, that's what you said. I see, I see Wim nodding. So he agrees. So there, there that said.
Right. All right. So we've talked a lot about the, about the ways that it could get in, and I'm, I'm seeing a clear picture of it. It's, it's really about getting into the operating system and, and mucking it up in, in whatever way for encrypting the whole thing, get or using tools to further get into the files, wipe out your backups.
I suppose, the, the, the, the Clara. Backup progression system is really well known. It's been talked about. So some hacker could study that and then find ways to, again, wipe out all the backups that are in the default folder or, um, get to the actual place where the live folder files are and, and mess, mess them up, or women, as you said, take down FileMaker server itself, the service.
So there's a lot of stuff here. You, you three, both, all of you talked about ways to just keep your eye on this and keep your, your head thinking about this. I want to shift to that and I want to talk about that. And I think, uh, Heidi, you, you had this great phrase, know your normal. Um, I would love for you to speak to that.
What does know your normal mean and what do you do with knowing your normal? All right. So no you're normal. That effort is I'm actually came from whim to court, I believe. Um, and then I wanted to clarify, uh, the. You know, yes, I can get into the OMS, but it can also get below though. S and so in the kernel.
So, um, and that's another thing we looked at, you know, again, there's these different levels of sophistication of ransomware developers and companies of what they can do. Um, and the goal is to put some speed bumps in the way of the lower ones. You know, if that's who attacks you and, uh, just keep putting speed bumps.
So what was your question again? The other, no, you're normal. Yeah. So no, no, your normal, uh, means no. What the normal state of your infrastructure is like, you know, how. Just space you using in general, you know, and process or, you know, so if you think you can see what's abnormal, you know, or, or what's getting, uh, logged in your event, you know, so you can see what is your normal situation.
So if something and you're monitoring and you're logging, you know, if something abnormal comes in, maybe you can alert to it or you can notice it. And so that's, that's, it's your aphorism, whim. Anything else to add to that? It's knowing what your normal situation is. And so you can detect abnormalities and I would add one other thing is.
You know, a lot of the automated machine learning security mechanisms, I think, um, uh, I can't remember what the windows one is called. I don't think it's defender, but you know, that's what they're doing is they're training on data so they can see what's the normal, and if there's an abnormality, they can alert on it.
And so they're literally training on what's the normal, and then they detect something that's not normal and it might be a false positive, but, you know, it's, it's, it's that same rubric just to emphasize what you're saying. Um, cause you're making all the very good points. Um, and using ML and AI for these things is, is a natural progression.
Right. And I have it on my, on my to-do list for my copious spare time to, to, uh, to do some of that with, uh, with the Pharmaca sort event logs and the stats login stuff. Cause it's such a natural fit, right. Um, because every deployment is slightly. Um, and it takes years of experience for most people to be able to read something like an event log and make sense of it.
Right. We can all read it. That's not a problem, but making sense of it is, is what, what the trouble is. Right. So if we can have machines look forward for the, um, for the patterns, cause this is all about pattern matching, right? It's it's about finding patterns. And then, and then finding the anti-pattern and say, look, this is weird.
We should have a look at that and get the alerts. And it really all starts with making sure that you collect all the right information. I found my. Gives us the ability to log a bunch of stuff. So does the operating system, so do many of your devices, so make sure that they do right and store them off somewhere, Heidi, in our slides that we typically present with this talks about this extensively, make sure that, that, that, that you not only logged them, but that you, you, uh, write them off to somewhere, right?
Because, and how do you, you can tell the story about, uh, about the, the, the stuff that you learned that at Def con about we saw this session. I just haven't seen this. It was windows event log in. I thought, well, maybe we'll find out. Small useful it from this session. And we basically were taking screenshots of it the whole time, which is good because, um, he doesn't have a video out there of, oh, we should like this.
We should like that. His number one advice was, make sure you increase the default log size on windows. You know, no incident responder says, I wonder what I'm going to do with all these logs, because, you know, if you don't log something, you don't have that information. If you don't log something, you can't get alerted.
If somebody is escalating privileges or trying to access some hidden file, you know? And so a lot of it was about, you know, logging these different changes of privileges or accessing shared files or doing things. That are abnormal, possibly an alerting. So you can double check them. And then of course sending them off to a log aggregator.
So they don't get compromised if someone gets in there. Um, but yeah, the guy's name was malware Jake. We liked that if this is your first prompt to do you consider logging it and doing that, uh, the, the good news is that you'll get so many other benefits from that, right? Because if you, if you have the logs, it makes your troubleshooting easier.
It makes your performance profiling of your solutions, much easier. You'll, you'll fall in love with the logs, right? Because there's so much good stuff in there. And I know I'm weird, but, uh, that's my whole buddy who loves them. I read them, I read my logs with my morning coffee. Well, but that, I mean, that's, that's a good point.
You, you know, until AI can pick this up and handle it for you, you should be looking at that. How often do you look at your event locks every day, couple of times a day, do you glance at them before you go to a new, another meeting? What do you do? And in my case, I obviously have tools that monitor my logs, right?
And I have configured Zabbix is the classic one because it's, it's, it's available and there's plenty of good resources in our community. Once you learn what your normal is about your specific deployment, you can say, I seem to have trouble with my progressive backups, right? So I want to keep an eye on that.
So every event that has to do with progressive backups failing, I want to know about that. I want to get something in my slack channel, or I want to get an email or send me a text on my phone. Right? So, so these kinds of things, so you don't need to be reading the roll logs every single time. You will at some point just to get a sense for what's there.
Uh, because at some point you'll have to learn what's in there, uh, to, to get to that state of knowing your. But, but yeah, they're your best friends? I swear, right. There are also a point of vulnerability because sophisticated malware will know that its activities are being logged in, can actually go and modify the event logs to try and cover its tracks.
And so when you get into that level of threat, then it, it's almost a necessity that you get into log aggregation tools so that you're harvesting these logs off. And even if they get compromised that you still have the original record, Chris, you were just full of good news.
It's a layer defense, right? Because what Chris is saying is that if you have a log aggregator, then, then you can put monitoring on that one. Uh, right. Because then it can alert you to say, I haven't seen any log events come in in the last 15 minutes, or I detect that that events have been deleted. Right?
My, the size of that log file is now smaller. So it's, it's very much a layer defense. Just like the attack is a multi-layered attack. The defenders equally has to be, has to contain those multiple layers and different, uh, different, uh, disciplines. And so build a team around them. Chris, you, you, you just mentioned that the log files themselves could be altered by a sophisticated attack.
Is there a it, but I missed it, but is there a, is there a point when a log is written that you could immediately extract it out using a tool, um, or is there, is there, is there like a split second or do you have some time to be able to get that out before it potentially gets altered? So there are log aggregation tools and I'm not crystal clear on the timing of it, but I think that you can basically echo your log events to the aggregate.
Rather than say, you know, every hour, I'm going to grab that sucker. But, uh, so the class of tool is called a SIEM or SIM. I've heard it pronounced both w both ways. It's a security incident and event manager. And so some of this stuff doesn't look suspicious if you're just looking at a single server, but if you see that, Hey, the domain controller jumped onto this local server and created a new account, and then it escalated the privileges on that account.
And now it's accessing a hidden share, you know, from some other server, you know, these things are spending two or three machines. And if you're only seeing part of the transactions, they may not rise to the level of that looks concerning. But when you look at him, you know, with his bird's eye view and seeing this actual movement traversing across your network resource, Then it becomes a problem in the great thing about SIEM tools is that they can have templates to say, Hey, if you see this pattern of actions, you know, be there on one machine or across multiple machines, send up a flare and let people know something's going on.
And so that is a great way to a capture all your stuff and find anything that looks suspicious and then actually do alerting on it. And so it's not that different from Zabbix because Zabbix will do alerting, you know, if it sees, say a server go down or something like that, it'll give you a heads up. It has the ability to look for patterns and alert on that, as opposed to just is this event too or false.
And so it's a bit more sophisticated than a straight up monitoring tool. And then that can work in conjunction with a soar, which is a security orchestration and response tool. And so it can say, Hey, if this happens, maybe we want to shut down some ports on our, you know, edge rudder or something like that.
And so you can have a pre-programmed response. You know, th the ransomware gangs typically tend to attack an off hours, you know, after six o'clock on a Friday or on a long holiday weekend or something like that. And so they like to make a move when there are fewer reef resources, you know, watching the, the hen house as it were.
And so if you can sort of say, okay, if this happens and this happens sort of pregame your responses and have those be automated, to an extent, you know, you're that much farther ahead when they hit you enough hours. Jeremy, that was a good question about the timing though, of the logs. If something tries to compromise the logs right.
As it could alert you, we, we should look into that. Uh, Chris a little bit. Yeah. You know, I think, I think a lot about this. You mentioned Chris, you mentioned auto and, um, there are other tools like that, but auto is built on this idea that you have a development server and a production server. Is there anything.
Issues with servers being connected that could escalate this ransomware attack problem. Even more. If they attack my production server, at least I have the development server. I don't have the data, which is unfortunate. And so maybe my whole point is moot, but are there connections that are there connections between servers?
Is that a, is that a problem that could ex exasperate this? The, the short answer is any connection between any two piece of infrastructure is a suspect or can be used for this purpose. Right. Um, the more nuanced answer is that it kind of depends on the type and nature of that connection, right? If it's an API connection, for instance, it's much more limited in its scope, but it's can only do so much.
Right. And, and it needs different kinds of authentication to be able to do that. If it's a file share, that's what, like the worst case, right? Cause these, these, these are easy because if I can get onto a machine. As a somewhat privileged user, I get access to all the shares across the whole network that that user has access to.
Um, and because their file shares, they, they use the file system. It's kind of easy to move files around and, and, and distribute my pieces of malware. Right? So obviously from a, from my point of view of stitching systems and piece of infrastructure together, you want to think that that should be the reflex.
Why do you want to think about the number of connection points that you, that you create and that you sustain? Uh, the best kinds of the ones that you only instantiate the moment you need them, and then you turn them back down, right? They shouldn't persist. That's the golden rule. That's what auto does.
And other tools, there are only. The connection only happens at the point of migration, right. It's not a persistent connection. I believe so. That's good too. That's good. I will say though, and I, I don't think you saw this one, one, but I showed up our Def con Rica cafe, an example of, uh, a phishing attack with, um, on the, I think it was on the Azure ID infrastructure and they did, you know, use the API to go in and escalate, privileges and move laterally and increase their scope and all this kind of stuff.
So it can happen. Right. It's just like, it's, it absolutely can happen. Right. Because it's one of the things that internally at Alliant, we pay a lot of attention to, and we started adopting last past due to store credentials. And instead of putting them on a Wiki right. Or worst case, putting on a text file because.
Who, who doesn't have a text file somewhere that has some AWS credentials in there. Right. Because you need them in a hurry. Right? So, so these are the things that the attackers, when they burrow and look at your network, that's what they're looking for. Right. Because if they can find the API credentials, that way they can now say, okay, like you said, Heidi, if they can now make calls to do that, do that API may be elevate their, their, their rights that way.
Right. Or, or take yours down for this one was a phishing email with the Microsoft domain, where it said, you know, you get a free terabyte of storage, you know, and you go in and you put in your, uh, I think you put in your MFS or whatever code they send. And, uh, you know, then they were in, go ahead, finish your thought.
Sorry. They were in. That was the end they were in. Okay. So I just wanted to add one point onto the last topic we were just on, which is that if you were to just Google SMB, You will find that the, uh, you know, Samba itself is, uh, uh, attack surface and a vulnerability point. And so the more shares you have sitting on your network that the worse off you are in terms of, you know, forwarding lateral movement.
So yes, doom and gloom doom and gloom and doom and gloom, all this stuff. Let's we did, we have talked about some, some strategies that prevent this from happening, what I'd like to, to, to shift and just talk about is sort of the, the, the business side of this. Um, you, I think you've mentioned, you've mentioned the practice.
I want to want to talk about that, but I also would love to talk about how do you prep your clients for this. If I'm hosting. A hundred, um, clients' files. They just using me as the host. They're my clients. How do I prep them for this for, for, for this? What re what recommendations do you have for the hosting provider to talk to their clients about this real world issue?
Or if they ask the question, right. Well, that's actually a good point. Like, should you, should you wait till they ask, or should you just bring this up as part of your standard sales pitch? I'll actually take one step back and I'll get into the hosting answer to that. But as, as Pharmaca developers and consultants, I think we can, we can, we can begin by having that conversation with our clients, right.
We don't need to wait until they come to us. And I think it's part of what we do. To help them prepare and think about these things. Just like we just like, we talk to them about backup strategies and disaster recovery strategies and business continuity. And that's what Heidi mentioned with the hurricane, with the, uh, with the tornado.
Right. It's uh, I think because we know of these things, we can be really helpful to our clients to initiate that conversation and see what kind of appetite to have around that. And have they thought about this? Do they want to talk about this? What are the small things we can do to, uh, to help them along along the, along the way?
Right. So even if we don't know all the ins and outs of setting up a perfect disaster recovery plan or, or, or response plan for ransomware, w we don't need to, I guess, as part of my, my message, right? We don't clearly expect all the Pharmaca developers to become experts at at security and hardening servers.
And that's not the point, right? The point is that once we're aware of. We can, we can look for people who know these things right there, there are services out there there's people that that's can help them think through this problem and come up with, with a solid plan. If you happen to host files for your clients, like, like the, the hosting providers do clearly you must have a plan, right?
Because obviously w when, when you get attacked, then your clients go down. We talked about this a little bit. When, when we say like service providers, like air table, they, the impact of, of them being, being compromised is much bigger because they take down all their clients for any hosting provider on the pharmacy side.
It's the same, the scale is smaller, but it's the same deal. Right? And I would love for every single hosting provider to have something on their website to say, do we acknowledge the fact that some, something like that is out there, right? I don't expect them to fully lay out their plans because their plans need to be flexible and they have to have the leeway to.
Do to change them at will, but just to acknowledge the fact that, that they, that there's something like that and that they have a plan. Right. Um, and obviously whenever you're a service provider communication, what we talked about, the communication plan is critical, right? Um, you, you have to let your customers know ASAP that something is up so that they can do their own thing and potentially to help them, right.
Like, uh, uh, find a way to automate giving them access to a backup or anything, anything small like that. I agree with all that. And I think that, you know, as I think many of us are trusted advisors for the clients we work for. And I think a way to get the ball rolling on this conversation and to get them to take it seriously and really look at it, uh, is to ask them a series of questions.
Uh, if you get attacked, what is your cybersecurity insurance provider want to have happened? Will you pay the ransom? Will you not pay the ransom? A lot of people aren't going to know the answer to that off the top of their head and be like, oh, I should probably know that, um, get their, uh, legal counsel in there.
Do you have any service level agreements that require notification or, you know, any sort of mitigation steps to happen? You know, as soon as you get legal involved, whose job it is to protect against risk, all of a sudden they're going to go off, you know, setting alarms, um, do you know the number for the nearest FBI field office to loop them in?
And as soon as you start getting into here's all these parties, you have to engage your managed service provider probably needs to be in this conversation. They're going to realize they do not have a handle on this situation, and that should make them uncover. And hopefully they take steps to, uh, get those question answers and formulate a response plan.
And so I think just by asking a handful of questions like that, um, it would serve to get the ball rolling in a lot of organizations and get the people at the appropriate level engaged on the problem maybe. Yeah. Because they're also hopefully yes. You know, they often think, and that, and that is one of the reasons that we do try to, you know, scare a little bit of, this is something that overlaps with the sweet spot of farm acres, demographics of, you know, small, medium businesses is that, you know, people are busy, business owners are busy and sometimes it's, yeah.
I need to deal with that. You know, it doesn't happen as soon as it probably should. So, um, you can try. Yeah. It seems to me like, because of this, we, we need to also really insist on the best practices of security, no auto log-ins, no people sharing the same account. What other, what other things do we need to insist on to lower the logging out every night?
I mean, is, are those things that you feel like you need to insist upon phishing training? Oh, phishing training. Okay. Whether it's, you know, done by someone. You know, your consultant or, you know, you hire a no before. Yeah. We talked about fishing. We talked about the, um, the credentials, right? Cause that's what the fishing's are.
After it's building a profile of the user, knowing what the user has access to and then try to trick the user and divulging their, their credentials. Things like multifactor authentication clearly is a, is a big protection against that. And as far as like developers being aware that you can use multifactor authentication natively against Tamika files can help have that conversation.
Why would we say Pharmaca fits in, right? Filmmakers is not the odd duck that will prevent you from going there. Um, you can use multifactor authentication, uh, and lock people in, into your solutions like that. Pharma can even allow us to completely passwordless authentication into pharmaco. How many developers have experimented with that?
Very few, I would imagine. But these are the kinds of things that we hope to. Get people interested in, so like, oh, I gotta set up and pay attention to that. That's interesting because it can help in the overall strategy, the things that we just joked about, right. Don't use the server as a desktop, right.
It's a, it's a it's we know that many do, uh, and there's good reasons to do it sometimes, but try to limit it. Right. And if you do it, it's like with anything that is best practice, right. It's one understanding what the best practices. And two, if you deviate from that, do it deliberately, right. Do it as part of a process that you think about and document it, you evaluate the risk and say, I understand the risk.
I'm going to do it or not do it. And if you do it, then at least it's, it's a, it's a deliberate effort instead of just a reflex out of convenience. Um, you know, where he's talking about least privilege, you know, uh, setting things up with least privileged. But I also think least a mapping. Like if you don't need to have.
Your, you know, any server or client, if you don't need to have something mapped, don't have it mapped because you know, if you do get infected, that's just another jump point. Agreed. And it's inconvenient, right? Because it means that if I do an RDP session and I need to move a file there, I don't have my map drives.
Probably I'll have to log a log off map to drive, log back in and do it. That's the kind of struggle that, that we're up against. Right. We've got like, oh, next time. I'll just leave that Darden map drive on already. Right. That that's how they get, you all mentioned the, the idea of prepping your team for this kind of stuff.
Let's, let's walk through what a development shop or I guess a one person team or whatever can do to, to kind of like a fire drill at school, you know? What, what roles are in play? I think you've mentioned some already, but let's list them in this, in this section specifically, uh, what roles are there and, you know, do you practice, do you need to practice this often?
This is for our response. If you are in fact, sorry for a response. Yes. I mean, to me, the first thing you want to do is, uh, I think before you even start calling people is disconnect everything because it's, it's, you who's hurt the most. And the faster that you can disconnect and unmapped and stop the spread, the, you know, the less damage something can do.
I've actually, um, someone here at, at proof Geist, um, Reported that he was able to stop an attack in progress, some security alert he got on his phone. I don't think it was recent. It was a while back, but it was, it was something that he was able to, to, to stop. Like you said, shutdown, kick that, kick the, the service, the, the ransomware attack out thing, whatever that is, kick it out and make sure he got the latest backups before.
Have you heard of that happening? Is that, is that like a likely scenario that, that, that, that would have. I wouldn't call it likely. Uh, but it's, it's an ideal scenario, right? So it ties into everything that we talked about. If you know your normal, and if you're set up to monitor your normal and something abnormal happens and you get an alert, that's perfect.
Right? That's exactly the kind of thing that, that you would strive to do to work towards. Now, of course, like I said, the, the, the actual encryption part of it, and that's probably where the alert comes from. That's unusual activity for sure. This activity, it's this process of activity going on. That's over and beyond what you'd expect.
If you can stop that, it's not as simple as restoring to a backup, right? Because you have to walk that whole thing back. You got to figure out how does this thing got on my machine to begin with Heidi? You mentioned the stats in the beginning, right? If you're, if you have been malware attacks, there's an 80% chance that it'll happen again.
If you pay, if you pay, right. Yeah. Yeah, because why not? Right? Like it's, they've already proven that they can do it. And if you haven't shut it down and it's shutting down, it's not restoring a backup. Right. It's like figuring out forensically, how does this happen? And because it's such a multi-layer attack that that may be spans months and maybe came in from one of your smart doorbells into your file server, into like, you don't know, right.
It's like, you got to walk it back and if you don't know how to walk it back, can you even trust what you have? Right. Uh, that's part of that response plan as well. You probably need a somewhat isolated environment to continue a business that has no connections whatsoever with anything else you have at that moment in time, I suppose to you could immediately, you could stop that.
And in our virtual environment, just trash that virtual machine and start up a new one. Um, after you've gotten the latest backups, would, would that solve a lot of the problems too? I mean, if you're wiping out the virtual machine, you don't have anything to worry about. Um, all that machine knows, and it certainly helps from the business continuity, continuity point of view, right?
Like if you can isolate a new environment, you can continue with your business. That's always that problem, right? It lessens the penalty that you have. I think Heidi has a great stat on that, on that. What was it? How long does a, a typical outage last? It was 15 days, 15 days, 15 days of downtime. And so I think, you know, like most of the answers, it depends, right?
If you are a service provider of some sort, maybe you are providing e-commerce systems to your clients, you have to prioritize getting those people back up and running because they're going to be screaming, bloody murder. And so if the trade-off is you get them up and running on something as soon as possible, But by doing so you lose maybe the morning's data or something like that.
You know, you have to weigh these priorities. Like what's more important getting these people to stop screaming or making sure we have everything, you know, with full integrity. And we've made sure that we've cleansed our systems, but we were down for three days, you know, you have these trade-offs, you have to work through and figure out, okay, what's most important here.
I think average is always a misleading, right? Because you know, most companies cannot be down that long. Right. So they're either pain or they're, you know? And so, um, I think that's a, that's a little bit skewed. I think it's probably the median is a lot lower. It goes through to Chris's point about starting the conversation with the clients.
Right. Because it's the same with disaster recovery. Right? It's the questions that, that I would want to lead on with the clients is like how much data are you willing to lose? And how long can you last without your systems? The answers to those questions will determine how much effort. Due to bump into not, not making it so, or making it so, right, so that you have alternatives in place.
Uh, if the, if the client says, I don't care if I don't have my system for a month, because I can do everything on, on pen and paper tomorrow. Well, that's fine. Right? It means it's probably less of a priority for them to spend a lot of money and, and, uh, and, and building a good alternative to, uh, to make sure that they can be up tomorrow.
Yeah. I think if you're a hospital and all of a sudden you don't have access to your patient records, that's a huge problem. All right. So let's talk about the practice. Do you, do you have a team of people that are ready to respond to this? Do they know, do they know their roles? Do they, do you practice this once in a while, right, right.
When you guys practice everyday. Yeah. I mean, that's part of it is figuring out, okay, what are the tests that need to be done? You know, who talks to the cyber insurance person who's going to call the FBI? Do we need to have somebody sitting with our clients? You know, you have to figure out all these tasks that need to have.
And, you know, someone has to actually fix the technical issue. So there's going to be someone, you know, you know, rolling up their sleeves and getting their hands dirty. So what are all the jobs that need to be done? Who's going to do them in what order of priority should they be done. And then you can sort of from that back into a staffing plan in what happens if someone's on vacation or are there any people who, you know, have silos of knowledge that if they're out is going to be a huge wrench in the works?
Absolutely. And, and definitely we're talking about a team, right? This is not a single person kind of tasks because somebody will need to communicate like a, like we said, somebody will need to realize Heidi said, go and unplug all the stuff and make sure everything's powered down. At the same time, somebody has to set up whatever new server there is to set up.
Um, and every single task has to have its own procedure. Right? If I'm the one tasked with setting up a use. Do I know where the backups are. Do I know where the installers are? Do I know where my license key is? Right. Do I have the credentials to, to, to get all of that stuff? So all of that needs to be written down so that I, that ideally all that needs to happen is that the open, my drawer gets out, get out my procedure and start working my procedure.
Right. And that's exactly the kind of thing that you need to practice because invariably. Say six months from now, if you, if I write a procedure now in six months from now, I go through my procedure and say, whatever is still valid. My license key has changed. Right. Uh, or, or, or my file server is not with different machine, uh, something like that.
So, so these are the kinds of things that when you practice, you need to validate that everything is still valid and that it's still usable. And yeah, I think the crucial thing there is to develop a checklist because when this all goes sideways and you have to move very quickly, you don't want to be winging it.
You want to make sure that every step has been thought through that. You don't miss a step. Like we said, these, these checklists are valuable. You know, if you take out the FBI and it's not a ransomware attack and et cetera, the checklist, um, can be used for other situations as well. So there's a lot of value in having these.
You know, response and recovery, uh, for, you know, subsets of things you need to do for any server issue. Is this unique to each client, to each, um, hosting provider? Or is it a pretty generalized list? I think it's a generalized list with specific details, right. For each hosting provider, right? Like what their, yeah.
Do we either do it, any of you have that list available on your sites?
We have procedures that we have written over the past what we don't make them available on our websites. Um, uh, like Heidi said that they are, they are generally. Big parts of it are general. Like for instance, the, the fact that, you know, what, what are your installers are your licensed keys? Right? Um, the same thing is like, uh, I don't know, you can make it as detailed as here's how you install, file make a server, right.
And you got to drop these plugins in that location, uh, and enable these schedules and whatnot. And here's the backup of the schedules. So these are the things that are specific. Um, but they are in that step-by-step right. So sorry. The Pharmica server installation, part of that checklist in general, and as Heidi said, it can be reused for backup and restore, uh, the functionality.
This is, um, you know, this is serious business. It seems like, you know, I know wham, he and I have talked a lot in all over the, the farm worker community. Wim has used the word, uh, the phrase premature optimization sounds like this is not anywhere near that. It is like a vital part of what we do as.
Supporting the Clara's FileMaker platform for our customers. It really needs to be thought through you agree that I assume, yes, no denial there, but I mean, you're hearing it, the sheer variety of companies and organizations that use FileMaker would dictate a pretty significant, you know, if I'm a manufacturer whose production lines are down and it's going to cost me $10,000 an hour to have my machines idle, I will have different priorities than a hospital, or then, you know, garbage processing plant or something like that.
And so, uh, his whim said, you know, the essentials of restoring your FileMaker server are going to be pretty similar, but everything outside that is going to be very different, depending on what your responsibilities are to your clientele and, you know, any legal, uh, regulations that come into play and so forth because this whole thing make you feel, is it, is it an energizing thing?
Like you're gonna, you're gonna. Do the best you can. And you're going to overcome this. Does it scare you a little bit? I know, you know, Chris, you I've accused you of bringing the doom and gloom, but, um, what, how does this make you feel? Is it, is it just another ch challenge to beat? Um, or does it scare you for me personally, it's terrifying the level of professionalization we see in the ransomware community.
If you like fire up a Tor browser and go poking around the dark web, I mean, these people are very brazenly advertising, how great their ransomware is and how much faster it is than one of their competitor pieces of ransomware. There are dozens and dozens of organizations out there who say, Hey, if you want to, you know, drop a dime on your employer, you know, we'll give you a piece of the action.
They're actively recruiting people to breach their own employer. You know, it's terrifying in that regard and that this seems like a problem that's going to get worse before it gets better. There have been some recent enforcement actions internationally where they're starting to go after some of these people, but, you know, it remains to be seen if that's going to make any sort of significant dent in these activities, they seem to be picking up speed, not lessening speed.
Uh, Steven Blackwell's efforts. It's, uh, the forces of evil are welfare, but okay. But it's, but I'm glad that you're coming on this podcast and you have shared with other, in other venues and you have plans to do more because it's important to get this out there. I don't think it doesn't feel like this is something that should be talked about once and it's over with it.
It kind of needs to be in the forums and in the presentations quite a bit until we all get our head around this and we're able to, to actually, you know, prepare for, for. Possibly an inevitable attack. So it's kind of like Maslow's hierarchy of needs. Right. You know, if there's like the one most important thing you should do to my mind is turn on encryption at rest.
You know, if exfiltration in publication of data is one of the pressure points. They applied to force compliance with the ransom, then that, you know, where the FileMaker people were, the experts on that domain of ours. And so doing that one thing sort of takes that lever away from them. And then there's all, you know, all this other stuff we want to do to ensure.
You know, a graceful recovery from having everything encrypted and stuff like that. And so we want to have immutable backups, we have good, uh, recovery processes and things like that, but sort of working down from turn-on ear before you do anything else, you know, w we, we can get broader and broader and broader and, you know, help advise these people on our response plan and tell them, you know, here's how, you know, I would do this.
And maybe we will even automate the creation of a new cloud-based server and setting it up and, you know, putting as much in place as we can to make that. It's possible, but you know, to me, the most important thing is encrypt your darn database. I think this is useful to add in there that we had a discussion today, you know, so you can encrypt the database, but that encryption password is very, very important to secure, right?
Because it is the key to your asset, to your software system. And, you know, I think that every business who does encrypt their database, um, should have some, you know, not just the password, but a backup to their password. And even, you know, depending on how vital it is to your business, you know, in a safety deposit box somewhere.
You know, maybe not a piece of paper, maybe even on something that can burn up, just, you know, it's that important. And you know, the other part of the conversation was about situations where, you know, people were holding that, that your password from people, because it is so important, it is the key to that castle, that your software asset.
And so it's just really important to, um, secure that ear as well, that your password, okay. I'll reinforcing what Heidi and Chris are saying. And I like, uh, the, the, the hierarchy there, uh, encrypting. Absolutely. Right. It's, it's a, it's a, almost a zero efforts, great protection. And the rest comes down to, to the best practices.
Um, the same best practices that we've been talking about for a long time, uh, dedicate your Pharmacal server to only found microserver minimize the number of things you do with it. Basically all of these things that if you do enough of these. You're making it harder to be attacked that way. Or at least if, if other pieces of your infrastructure can attack, then there's a bigger chance that that piece will survive.
So it comes down to that. And we've been talking about these, these best practice for a long time. I think ransomware has really made them a little more relevant and a little more urgent to pay attention to, and, and we have a great community. So, um, so let's continue to talk about it and, and, and put our collective brainpower together to come up with good ways to think about these things and have conversations with our customers.
That's great. I I'm really glad that throughout the years, throughout the time that I've been part of FileMaker, that you and Steven Blackwell and, and Chris and Heidi have been speaking about security best practices at, at first, I think you were just talking about don't let anybody in your files, who shouldn't get in there to get the data out, but it has naturally expanded into let's prevent.
Your whole system from going down because it was attacked. It was, it was, you know, ransomware was placed on it. So it says, it seems like the security practices are global. They apply they're universal. They apply to all of the problems that we could have as, um, working with FileMaker files and working with clients.
So there's really no, it, you know, I know throughout the forums throughout again, throughout my time, I've seen people like say, well, but I can do this auto log and thing, and it's just fine. It works just fine. My clients want it. It's easy, blah, blah, blah. And you and other people are just going against that every time saying.
That's not the right way to go. And this is another reason that that is the case. Very good. Well, uh, you, uh, three are, are circling the user groups and, uh, currently and in the past, and, uh, I'll link to the ones that you've done so far. And, um, when I see of other ones, we'll, we'll add it to the show notes, but it's, it's important for you to be heard about this and look at your slides in the, and the video version of this at the user group.
So, uh, Heidi, Chris, and whim. Thank you for joining me today. Uh, appreciate it. This was a good, I think it was a good discussion,
so, but it just broke in, I think. Yeah. Ransomware, I think. Um, anyway, thank you for joining me today and, uh, we'll have a, um, we'll try to lift our spirits now after, after this conversation. So thank you for.
And that brings us to the end of another episode of the context podcast. Thanks to guests, Heidi Porter, Chris Moyer, and William D'accord for their willingness to stand in the face of this monster and share with us how to overcome it. Check below in the show notes for more information and links to the presentations that they have done around our communities and do what you can to learn about ransomware and how we can combat it